node.js - 协同工具Worktile 全站都是用的JS实现,具体是什么样的架构?
怪我咯
怪我咯 2017-04-17 11:16:00
0
5
272

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

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

怪我咯
怪我咯

走同样的路,发现不同的人生

全員に返信 (5)
巴扎黑

昨晚看到这个问题,准备今天早上来回答一下,没想到都有这么多回答了,其实大家说的关于技术上的优缺点都是正确的。作为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及以下版本支持都不是很友好,甚至惨不忍睹,由于时间和精力有限,没法做很多兼容,但是我们相信,为了使用更好的产品,用户愿意为我们升级浏览器,呵呵。

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

いいねを押す+0
    巴扎黑

    优点

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

    缺点

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

    PS

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

    いいねを押す+0
      巴扎黑

      不太认同其他两位的观点

      优点:

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

      缺点:

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

        不是太了解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的相互交流不用管数据到底在背后是怎么存取的,只用管好自己的逻辑就行。
        いいねを押す+0
          伊谢尔伦

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

          いいねを押す+0
            最新のダウンロード
            詳細>
            ウェブエフェクト
            公式サイト
            サイト素材
            フロントエンドテンプレート
            私たちについて 免責事項 Sitemap
            PHP中国語ウェブサイト:福祉オンライン PHP トレーニング,PHP 学習者の迅速な成長を支援します!