再来讨论前后端分离的实践。

[thonatos]

看过了“淘宝前后端分离实践”后，考虑在公司内部进行试验，更多的还是借鉴。

前后端分离的实现在SPA（Single-Page App）中应用较为广泛，如AngularJS，React 使用Ajax技术与后端通过RESTFul方式进行数据的请求与发送，

如我们的数据统计就是通过ng（AngularJS）的SPA项目，但它并不适用于我们主要项目（如SEO体验较差）。

考虑到之前曾讨论的未来可能会换到JAVA的后端服务的可能性，重新看了一遍淘宝UED的”淘宝前后端分离的思考与实践“的文章，下面两张图是我对他们结构的理解。

一）结构

1.经典的结构


2.前后端分离的结构


二）优势

1.后端实现业务逻辑和数据的查询计算，独立部署后端服务。（例如后端服务部署在8080端口）

2.前端路由，MVC，实现相对于后端的独立，自主控制视图层。（同样实现独立部署如部署在80端口）
# 这里的Model如上图所示，是与8080端口的后端进行交互

3.通过Server（Nginx模块）判断客户端请求类型，自助引导至不同的模块，仅需要一次判断，后续无需重复判断。

4.前端通过步骤3的预处理，可以在页面渲染前对例如css/images/js资源进行压缩处理，如置换渲染所需资源到所需的CDN（如icon/icon-mobile/icon@1x/icon@2x）

5.传统的SPA通常由于资源的处理时间问题（网络环境影响），在完成前可能出现”空白页“（等待阶段），这里可以参考BigPipe方式，持续输出。
# 虽然可以通过一些手段实现渲染完成前的一些预处理，但采用这里说到的方法，实现上更加优雅。

6.相对于传统，这样的分离更加明确各自的职责，后端职责更加明确，前端自由度更高，耦合度却有所降低。

三)疑问

看到知乎上关于这个问题的讨论，大体上阿里系的后端意见都挺大的样子，于此同时，很多人也在说增加了前后端的压力，尤其是要发展出一批nodejs工程师神马的；不过中肯的看法是要根据具体的情况来定，个人感觉在小型系统上，这样的模式是有优势的，实践起来也不是很困难，尤其是对内部的系统而言，问题不大，但是想到未来可能会放到对外的项目上，就产生很多疑问了，各位怎么看？


——————————（我是牛逼的分割线。）
参考：淘宝UED
地址： http://2014.jsconf.cn/slides/herman-taobaoweb/index.html#/

[tomwan]

没那么大规模的话，这样搞是在折腾

[ZackYang]

折腾...让我想起我个人网站都是前后端分离...

主站zackyang.com在github page
服务端api.zackyang.com在AWS EC2 nginx反向代理的node上
正准备把照片使用的img.zackyang.com放到七牛去

[thonatos]

@tomwan

折腾的目的不就是为了将来的应用么？
所以才要先在内部试验，考虑可行性嘛~

[thonatos]

@ZackYang

放在github上的主战显然是静态站喽，然后呢，
你的这种是较为类似ng的方式（也就是ajax方式）直接请求服务端数据的，
这样的分离，很大程度上是受限于自身网络情况了。

采用顶楼的图二的方式，数据请求是放在内网或者同一服务器，数据请求的速度显然是要更高一点的吧？

那么，问题来了：
直接展示的内容显然是通过node来render了，ajax的内容....又是受限于网络了...（eggTeng！）

..只是讨论，畅所欲言喽~

[liangdi]

我们现在也是在尝试
前端完全的静态资源,通过ajax（ng） 请求数据
后端只提供api接口（包括后台管理模块也是 独立的静态前端）

[juicy]

@liangdi 我们公司采用这种形式快三年了，这几年最大的感受就是，前端工作量巨大，很多时候后端的一些工作都转嫁给前端。我想说这是一项造福后端的伟大创想，恩！

[liangdi]

@juicy 哈哈。你说的对。前端工作量变大了。但是相比以前。需要和后端或者自己处理 和后端有些打交道的view。这种方式变得更灵活了。目前我们正在往这方面重构。如遇到问题。到时候可以向你请教了

[caixiexin]

手头项目已经这么干了1年，项目用java做后端，提供rest接口，Html5+css+js前端，也有php单纯做前端。说说体会：
好处就是前后端分工明确，专注自己的模块，干活效率高。单元测试，优化什么的都能分开做 ps：我已经1年没写过view了。。
缺点也很明显：当人手不足时，忽然把后端人员调到前端，完全没办法动手（当初看到backbone和bootstrap结合的前端时，差点跪了）。。反之亦然。

[caixiexin]

@juicy 我也觉得前端工作多了。。不过后来想想，其实是我们做后端的只考虑功能实现，偷懒不去优化接口，做详细的单元测试才这样（我经常接口写完没怎么测就丢给前端用，用出了问题再改，这样其实很不好= =）。后端要做的事其实也很多，不过用户很多反馈都是从前端得出的，所以当后端功能做完后，很少会碰到需求变更或优化。

[thonatos]

@liangdi
@juicy

前端完全静态是什么概念呢？
换言之你们网站那边是直接放生成好静态内容还是说在浏览器访问的时候渲染成静态内容呢？
如果是直接放，那么就要剥离一部分涉及动态生成内容吧，

我有想过将一些内容封装成模块，然后网站局部动态刷新的方式，效果如何呢？

[Arrowing]

我也用这种方式做了一年
我是做前端的
前端的工作量要 X 2

不过分工确实挺明确的，后端开发API就好了。

[juicy]

@liangdi 我们后端是人肉测试。。。这个方面也很让人头疼

[liangdi]

@juicy API接口自动化测试还是比较方便的。建议使用

[liangdi]

@thonatos 使用angular等mvvm的框架，很容易实现你想要的东西。上手后 前端开发还是比较爽的。依赖，以及模块化都可以搞

[juicy]

@thonatos 就是前端是纯粹的静态文件，而不是每次请求后动态生成的。一切业务逻辑都在前端js里，后端只管api

[thonatos]

@caixiexin

不知道你们对于ng的看法，但是我非常喜欢ng的实现方式，但是ng对SEO不够友好。

现在要用这样的方式的话，
将ng的controller重新拉回到nodejs，
将ng的数据绑定回归到nodejs的模板引擎，当然，不是完全的替代；

有些地方，还是会采用mvvm模式或者数据双向绑定的方法来实现，毕竟可以降低劳动量。


我们过去的模式职责不够明确，前端对后端的依赖过大（我是指非类SPA项目），现在这样，重新定义前后端的职责和权限，前端的自由度是增加了的，可控制性也更大了；后端，也能更多的关心业务逻辑，这样更好一些吧。

[juicy]

@thonatos 是很好，前端要是能涨工资那就更好了。。

[liangdi]

@thonatos 你用ng。那么前端完全可以直接使用ng的模板啊。也可以局部更新

[liangdi]

@thonatos SEO也有解决方案的

[thonatos]

@juicy

明白了，那样的话，感觉有点过去国内CMS系统的做法（生成静态站）有木有~

@liangdi

类mvvm的试用了一些，之前没有打算重新更换架构的时候，我就是用ng来写的，功能上没有问题，但是总觉得，体验上不是优雅（有点小洁癖，sorry）~