讨论一下AngularJS和Node.js等Web技术

DDD888

我感觉light client/heavy server可以处理web browser, android, ios, mac os非常方便

heavy client/light server许多代码必须在web browser, android, ios, mac os上重新写一遍

simpledream

superopengl 发表于 5-7-2014 05:08

                               
登录/注册后可看大图

最近在公司里做了一个小项目的prototype，MongoDB + Node.js/Express as REST APIs + AngularJS。

优点 ...

如果觉得第一次load各种库费时间的话，可以试试AMD，比如RequireJS

superopengl

DDD888 发表于 6-7-2014 18:37

                               
登录/注册后可看大图

我感觉light client/heavy server可以处理web browser, android, ios, mac os非常方便

heavy client/lig ...

这也正是JavaScript的无人能替代的作用——Logic code既可以在Client端运行也可以在Server端运行。现在只有JavaScript能够做到这一点。

出于安全考虑，logic code可以在Client端跑一遍，发到Server端的时候还可以再跑一遍。

superopengl

DDD888 发表于 6-7-2014 18:34

                               
登录/注册后可看大图

你如何处理security?business logic 在 client side很危险,你不怕被hack?

1. 任何新概念都是先处理理想case，然后再考虑安全性的。所以有安全漏洞不应该是拒绝一种新东西的理由。

2. Server端要保证数据逻辑的安全性即可。因为新architecture中，server端只负责数据逻辑的validation。其实所有的biz logic最终都要转化成data logic然后存储。只要保证data logic security就可以了。biz logic实际上是根据user input计算出data，然后发送data到server端做存储。只要data logic security保证好了，即使biz logic被hack可，hacked data也会被server端拒绝。当然这都是理性状况下。

superopengl

simpledream 发表于 6-7-2014 20:53

                               
登录/注册后可看大图

如果觉得第一次load各种库费时间的话，可以试试AMD，比如RequireJS

无论如何，Browser end首次load大量JavaScript代码是避免不了的。可以通过一些技术手段回避第二次以后的load。第一次访问相当于下载整个程序的code到browser end。

也许这并不是一个大问题，可以通过UX设计（进度条等）解决掉。

DDD888

superopengl 发表于 7-7-2014 02:31

                               
登录/注册后可看大图

1. 任何新概念都是先处理理想case，然后再考虑安全性的。所以有安全漏洞不应该是拒绝一种新东西的理由。
...

假设使用100mb数据生成1 byte数据，根据你的设计，100mb数据需要被带到browser端， 如果在fat server中处理，只需要1 byte数据被带到browser端

superopengl

DDD888 发表于 7-7-2014 05:37

                               
登录/注册后可看大图

假设使用100mb数据生成1 byte数据，根据你的设计，100mb数据需要被带到browser端， 如果在fat server中处 ...

是的。但好处就是server端CPU和Memory不再负担那100mb代码所需的计算量。server端做更少的事情，从而实现更多并发并降低成本。毕竟server宝贵的资源不是免费的，而network传输是免费的。

Web Application UX的瓶颈已经不是带宽，而是response等待和JavaScript执行速度。

而且100mb的code，理想状态下只下载一次，之后就不再下载了。我觉得brwoser作为cloud上的一个计算节点，有个发展趋势就是永久存储server端下载的JavaScript，而不是现在作为temp file存储。比如在public CDN上的jQuery.js、AngularJS.js其实就是一种供Browser使用的dll的概念。

DDD888

superopengl 发表于 7-7-2014 08:13

                               
登录/注册后可看大图

是的。但好处就是server端CPU和Memory不再负担那100mb代码所需的计算量。server端做更少的事情，从而实现 ...

传送100mb的数据到client browser 要花多少时间？

server端资源向来被认为是免费的

实现并发，并不是通过你所说的将计算移到client browser来实现的

JavaScript执行速度所花时间相比传送100mb的数据到client browser应该ignore啦

woodheadz

Javascript loading处理好了不会是太大的问题。
我现在的项目javascript压缩后接近2mb，采取的做法就是先按逻辑模块和大小分为几个包压缩，然后将每个包的文件名改为这个包的md5。http header缓存策略设置为缓存1年。这样连上服务器检查时间都不用，也不会出现不同的javascript文件版本错误搭配之类的问题，效果很不错。

现在浏览器端能力已经非常强大了，完全离线都能做到。所以这方面的应用也越做越复杂，前端框架作用也越来越大。
我自己做得框架Knot.js已经基本经过我们项目的检验，最近有空就做点包装啥的，做好了开源。一个人做开源很累啊，会犯严重的拖延症。 有没有同学有兴趣一起来？

black_zerg

Features I like in angular: route, validation,repeat (filter), utility tools (battery included, so you don't need other libs), elegant mvvm, good docs. And it has DI, and it is easy to write new directives .

overall it's nearly flawless. It's hard to compete with Google.

woodheadz

black_zerg 发表于 7-7-2014 11:19

                               
登录/注册后可看大图

Features I like in angular: route, validation,repeat (filter), utility tools (battery included, so y ...

所谓的软件设计，本质上就是一门取舍的艺术。
既然有取有舍，就不可能面面俱到，就不可能在所有情况下做到最适。
所以尽管有angularjs的存在，还是有不少人在用knockoutjs。不一定要竞争，补充也是可以得嘛。

DDD888

我感觉现在应该做thin client, fat server. 如果thin client 只需要用十行代码的话，那就最好了，对于client browser i.e. ie, firefox, chrome, 或android,iphone, ipad应用程序如果只要能重新写十行代码，那工作量就大幅度减低，真这样的话，服务器写五万行C#代码也是值得的

DDD888

反正现在大多数专家级别的人都会同时写C#,javascript, java，多种语言开发网站应该不是啥问题啦

woodheadz

DDD888 发表于 7-7-2014 12:17

                               
登录/注册后可看大图

我感觉现在应该做thin client, fat server. 如果thin client 只需要用十行代码的话，那就最好了，对于clien ...

这年头都讲究用户体验，你说的这种情况越来越不现实了。

DDD888

woodheadz 发表于 7-7-2014 13:19

                               
登录/注册后可看大图

这年头都讲究用户体验，你说的这种情况越来越不现实了。

我就用thin client/fat server设计,运行在client browser ie 8+, chrome, firefx和android native application上,客户非常满意

woodheadz

DDD888 发表于 7-7-2014 13:26

                               
登录/注册后可看大图

我就用thin client/fat server设计,运行在client browser ie 8+, chrome, firefx和android native applic ...

呃，你们的应用客户端交互应该不会特别复杂吧，我估计。然后也没有离线需求是吧？

DDD888

woodheadz 发表于 7-7-2014 13:40

                               
登录/注册后可看大图

呃，你们的应用客户端交互应该不会特别复杂吧，我估计。然后也没有离线需求是吧？

我感觉挺复杂的，不是CRUD简单应用，背后是ERP(SAP)

我实现了离线功能速度飞快，数据加密，比在线快许多

woodheadz

DDD888 发表于 7-7-2014 13:43

                               
登录/注册后可看大图

我感觉挺复杂的，不是CRUD简单应用

我实现了离线功能

十几行客户端代码实现离线功能和复杂交互？  挺牛的啊... 详细分享下？

DDD888

woodheadz 发表于 7-7-2014 13:46

                               
登录/注册后可看大图

十几行客户端代码实现离线功能和复杂交互？  挺牛的啊... 详细分享下？

可能是我没有表达好，误会啦

我举例啦，我没有说我写的应用是用十几行客户端代码，我说的是thin client/fat server理想情况啦

相对后台，我的JAVASCRIPT代码量是后台的20%,应该是thin client/fat server啦

woodheadz

DDD888 发表于 7-7-2014 13:49

                               
登录/注册后可看大图

我举例啦，我没有说我写的应用是用十几行客户端代码，我说的是thin client/fat server理想情况啦:lovelin ...

哦，一般的系统20%的js代码量那也很正常啦。
当年用ASP.net做企业行业软件开发几乎可以不写js代码。我的意思是现在越来越讲究客户端体验，这种几乎可以不理会客户端的“理想状况”是越来越少了。

black_zerg

Bootstrap plus angular, invincible. Good looking, fast development, excellent user experience, maintainable code. Server side doesn't matter, rest service in Java or
Net, python. Can't go too wrong

karl.lee.2004

DDD888 发表于 7-7-2014 12:17

                               
登录/注册后可看大图

我感觉现在应该做thin client, fat server. 如果thin client 只需要用十行代码的话，那就最好了，对于clien ...

我倒是觉得，随着网络速度的提升以及Browser功能（主要指js engine）的日益强大，客户端应该从以前的thin向fat发展。

网络速度的提升，意味着clinet端更新带来的客户等待时间可以极大减少，用户体验不会受到影响。而browser的js engine强大，意味着很多原本必须在server端跑的功能，现在可以放到client端跑了，节约了server的资源（或者更积极的说法，是充分利用了client富余的计算能力）。

另外，之前不同的browser对js的解释不尽相同，所以client端的代码要同时维护多个版本，对开发团队是很大的消耗。但随着一些framework和lib的日益发展，跨browser实现技术已经相当成熟了。因此client端的开发，应该在web开发中占越来越大的比重。

所以我打算在当前的项目中，多使用点js技术，当练手吧。

ubuntuhk

superopengl 发表于 5-7-2014 05:08

                               
登录/注册后可看大图

最近在公司里做了一个小项目的prototype，MongoDB + Node.js/Express as REST APIs + AngularJS。

优点 ...

谢谢superopengl分享实战经验，javascript的代码在我看来，确实比较抽象难懂（相对于C++、Java、Python等语言来说），如果项目比较大的时候，前后端都用javascript，如何保证代码可读性、可维护性，是个问题。

还有确保客户端的代码和数据的安全性，也会是一个需要认真考虑的问题，相信业界一定也考虑过类似问题，不知道有没有现成的解决方案。

ubuntuhk

superopengl 发表于 5-7-2014 05:08

                               
登录/注册后可看大图

最近在公司里做了一个小项目的prototype，MongoDB + Node.js/Express as REST APIs + AngularJS。

优点 ...

谢谢superopengl分享实战经验，javascript的代码在我看来，确实比较抽象难懂（相对于C++、Java、Python等语言来说），如果项目比较大的时候，前后端都用javascript，如何保证代码可读性、可维护性，是个问题。

还有确保客户端的代码和数据的安全性，也会是一个需要认真考虑的问题，相信业界一定也考虑过类似问题，不知道有没有现成的解决方案。

ubuntuhk

superopengl 发表于 7-7-2014 02:27

                               
登录/注册后可看大图

这也正是JavaScript的无人能替代的作用——Logic code既可以在Client端运行也可以在Server端运行。现在只 ...

有点疑问，如果在client端和server端各跑一遍，为什么不索性放到server端跑？

ubuntuhk

superopengl 发表于 7-7-2014 02:31

                               
登录/注册后可看大图

1. 任何新概念都是先处理理想case，然后再考虑安全性的。所以有安全漏洞不应该是拒绝一种新东西的理由。
...

“即使biz logic被hack可，hacked data也会被server端拒绝”

这样就要求server端要非常谨慎地处理每次传入的数据，感觉server端开发人员的（安全）压力也颇大。

caoglish

现在的一个流行趋势就是WEB API的设计方式，这个好处有

1. 用一种语言编写，然后几乎所有语言都可以调用。
2. 面向WEB API编程，如果觉得原来WEB API的语言出现了瓶颈，可以换个语言，然后只要WEB API没变，所有依赖程序就可以继续使用

坏处：
1.必须有服务器端，一旦断开，所有依赖的程序全部不能用了。
2.公开的WEB API基本上无法改动，不然大批服务会受到影响。
3.web通信耗时耗资源

针对坏处2，一般的解决方案，是web api的版本控制，在设计的时候，url上预留一个版本字段表示版本，如果API有变化，就使用新版本，同时老版API本不变。

还有个关键就是API的设计一定要好。

这个有个很好的例子就是selenium Server，用java编写，但是所有语言基本上都有相应的框架去控制selenium服务器

ubuntuhk

woodheadz 发表于 7-7-2014 10:11

                               
登录/注册后可看大图

Javascript loading处理好了不会是太大的问题。
我现在的项目javascript压缩后接近2mb，采取的做法就是先按 ...

我看到github上也有一个knot.js，应该不是你写得吧？
https://github.com/keyle/knot.js/

你单独开个帖子介绍一下你的knot.js吧，我现在还是javascript菜鸟，要不然也挺有兴趣参与一下你的项目。

ubuntuhk

DDD888 发表于 7-7-2014 12:17

                               
登录/注册后可看大图

我感觉现在应该做thin client, fat server. 如果thin client 只需要用十行代码的话，那就最好了，对于clien ...

你这个例子有点太极端了，其实现在很多框架能做到跨浏览器兼容，即节省服务器代码也节省客户端代码，岂不是更好？

superopengl

ubuntuhk 发表于 7-7-2014 23:04

                               
登录/注册后可看大图

“即使biz logic被hack可，hacked data也会被server端拒绝”

这样就要求server端要非常谨慎地处理每 ...

我的经验是这样的：现在大部分server端的code把biz logic和data logic混在一起，也就是做了很多

• data binding/unbinding
• data serilization/deserilization
• data type conversion
• controller
• routing
• message string rendering, like "User {0} got an error as {1}"
• dynamic page rendering, e.g. aspx -> html
  

现在这些都可以放到browser端做。

至于增加server端代码质量的要求，这个其实剥离了biz logic，只处理data logic（或者说biz data logic），反而会使设计更清晰，代码安全。