协同工具Worktile 全站都是用的JS实现，具体是什么样的架构？

Question

看到协同工具Worktile 说用node和angularjs(差不多全站逻辑都是由JS来控制)实现.
这样的网站架构具体是什么样子的? 什么优缺点?

后补:
Worktile CTO TerryLee 的文章： 团队协作工具Worktile技术架构揭秘
讲的比较详细

Answer 1

昨晚看到这个问题，准备今天早上来回答一下，没想到都有这么多回答了，其实大家说的关于技术上的优缺点都是正确的。作为Worktile的技术人员，我大概介绍下为什么采用这些技术和一些优缺点吧！

Worktile之所以服务端选择用NodeJS，并不是一味的追求前后端统一，恰好是这些技术非常符合我们的产品，并且我们的团队能够很好的把握这些技术。全站JS，虽然都是用javascript语言，但是前端和后端需要考虑的东西和实现的业务是完全不一样的。当然也是可以把前端的JS用NodeJS的方式编写，然后通过 Browserify 去编译成前端的JS，这样就真正的达到了前后端代码完全统一了，我们并没有这么做，虽然我们的工程师基本上都是前后端通吃类型的，但是我们还是严格按照前后端分离进行组织开发的。负责后端的在一段时间内基本上也只做后端，负责前端的基本上不允许改服务端的代码（当然我们足够开放，团队成员可以申请职责调换），所以我们也就没有必要把前端的代码用NodeJS的方式编写了，不可否认这种方式的确很不错。

为了追求更好的用户体验，Worktile 整体架构基本上服务端只提供RESTfull的API，前端实现了SPA（单页程序）。具体的服务端使用的技术有: NodeJS、Express、Mongoose、Mongodb，前端主要是AngularJS + 一大堆前端JS库组成（其中也有很多我们自己封装的类库）。好玩的是在我们的产品上线之后，发现了还有一个叫MEAN（http://mean.io/）架构的东西。正好和我们采用的技术是相同的。

下面简单的说下采用这个架构的优缺点吧！其实间接的也就是谈谈NodeJS和AngularJS的优缺点了。

NodeJS 优点：
1. 我们选择 NodeJS，是因为它简单，高性能，正好我们的服务端只提供RESTfull API，Worktile 业务并不是特别复杂，而且我们都很喜欢NodeJS，所以也就使用它了，当然如果选择其他技术也可以做的很好；
2. 至于数据库，和NodeJS完美结合的当然是Mongodb，数据格式都是完全匹配，而且Mongodb的性能也是很不错的，楼上有人对于 Mongodb 数据量大了有些疑问，我们现在的数据量已经很大了，表示暂时还没有遇到过瓶颈，但是Mongodb也很好的提供了数据库集群，我们随时都在为今后做准备；

NodeJS 缺点：
1. 遭遇很多人吐槽甚至放弃使用的肯定是异步回调，到处callback让人受不了，其实可以使用一些同步的Module来弥补这个缺陷，如：async、 when，但是我们没有使用，是因为Worktile的业务不是特别复杂，如果有个别复杂的场景我们会拆分成很多方法，所以看不到很多callback的代码；
-----感谢 @shaunxu 提醒，更正于 2014-7-30：其实Worktile其他的一些service是使用了同步的module的，Worktile整个系统的架构如果细细讨论还有很多，我所回答的仅仅针对于 web 和 web API。
2. 事务的支持不是特别好，正好这个功能对于我们产品来说不是很重要。
更多的优缺点可以参考下：使用 Node.js 的优势和劣势都有哪些？

AngularJS的优点：
1. 我觉得是目前为止最好的前端MVC或者MVVM框架，基本上包含了所有我们需要的功能；
2. 更多细节我之前在知乎上回答过，我就不重复了，参考：AngularJS 有没有缺点？MVVM 框架中有比它更好的吗？

AngularJS的缺点：
1. 楼上有人说SEO，的确这是一个缺点，这是所有前端MVC框架的缺点，但是也有解决方案，如：prerender，Worktile没有使用，我们把外部需要SEO的页面都独立成一个站点了，这个独立的站点使用Express的服务端进行渲染的，而且这些页面也都是展示文字的，没有必要用到SPA；
2. 兼容性也是个缺点，我们目前对IE9及以下版本支持都不是很友好，甚至惨不忍睹，由于时间和精力有限，没法做很多兼容，但是我们相信，为了使用更好的产品，用户愿意为我们升级浏览器，呵呵。

至于其他的，我就不多说了，欢迎大家对某些具体技术和细节进行交流。

Answer 2

优点

1. 前后端语言一致，招人方便，交流顺畅。
2. 资源一次加载后，就不用每次都重新加载。
3. 前后端使用 api 接口，前后端分离，开发Android与iOS方便。
4. 从反应速度上来说，还是很不错的

缺点

1. 对SEO不友好。
2. 我自己开发一个Demo时，有时按F5，重新加载慢（有时直接显示json数据），用户体验当时就降到冰点。

PS

看回复才知道 SEO 和 刷新 都有了解决方案，表示孤陋寡闻了。

Answer 3

不太认同其他两位的观点

优点：

• 前端、后端、数据库(如果是 MongoDB 的话)，全是 JavaScript 和 JSON, 写起来爽
• 大部分操作不需要刷新页面，体验更好
• 前后端分离，可以方便地做 CDN, 做负载均衡，API 可以直接开放给移动设备用

缺点：

• AngularJS 和 Node.js ，包括 MongoDB 毕竟都还算是新技术，招人不像 PHP 和 jQuery 那么容易
• 低版本 IE 对 AngularJS 和单页应用所需要的一些 HTML5 特征支持比较差

Answer 4

不是太了解Angular，但是和它同名的Ember.js是这样的，它可以说是一个在前端的web框架，包含了router，model，controller，view／template这些。

• router监控url变化来取得相对应的model，把model喂给对应的controller，并且决定render哪个view
• view和controller交流，得到model，并呈现出来，view还负责监听事件，用户交互行为之后改变了当前页面的状态，这些页面的状态记录在controller之中
• controller除了记录页面的状态，还负责把改动过的数据重新存回model
• 这类的前端web框架，数据的存储虽然在model这个模块，但是application configure的时候，可以选择用什么样的数据存取的adapter。Ember有常见的RESTAdapter，配置好后端的api（这里就可以用node）来存取数据。这样，controller和model还是一样交流，但是数据都走json格式通过api来存取了。还有常见的LSAdapter，对应的是用浏览器的LocalStorage来存取数据。这样做的好处是controller，model，view的相互交流不用管数据到底在背后是怎么存取的，只用管好自己的逻辑就行。

Answer 5

我正好跟他们的人见过，还聊过，可以谈谈我的见解。
架构：
前端：angularjs，他们的前端是angularjs写的，更偏向于webApp的方式，单页面应用。
服务端：nodejs，express框架，既然是用express框架。根据框架来看，我估计不是完全的前后端分离，应该还是首页用node渲染出来的。
数据库： mongodb，其实这个你也可以认为是一个大的json文件，所以才说（差不多全站逻辑都是由JS来控制）。
优缺点
对于1楼说的优点都认同，缺点，现在看来SEO基本不成问题，F5感觉也优化了体验。
但是对于用了angularjs之后，ie的体验一直不是太好，特别是低版本。
还有一个对于mongodb 在数据量大了之后的一个疑问。