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

[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#/

[liangdi]

前后端分离的另外一个好处是当你要增加app客户端的时候就很轻松了

[thonatos]

@liangdi

SEO的解决方案看了，国外那边的解决方案或者通过判断User-Agent来给爬虫做特殊处理，
有过这方面的考虑，不过讨论后被否决了~

[thonatos]

@Arrowing

对啊，工作量x2，涨工资也×2吧！

[juicy]

作为一个reactjs拥护者，SEO毫无压力！

[yakczh]

如果是post提交有事务的操作呢,比如支付什么的

[learnshare]

把之前的 CS 模式延续到 BS 上，都是重前轻后的方式，客户端/前端多一些工作量，但后端简单不少

[blue7wings]

想过这个问题，想把ThinkPHP替换为Laravel。有没有这方面的书，或例子？跪求ＬＺ推荐下，想深入的学习瞎。。。

[yun77op]

我们这边有个工具可以把freemarker模板结合伪数据生产html，并不需要跑整个工程（特别是前期后端都没准备好的情况下），这里就要求前端要熟悉后端的view。

[fundon]

http://www.discourse.org 经典案例

[dong3580]

正如我正在做的项目：
前端 ajax 前端完全的Html5+css+js
后端 MVC 生成json的api
前后端完全分离，分别部署，安卓/水果端 也用这个api，公用一套Api，如果以后改语言，也行，前端无需变动，手机端也不需要变动，只需要重新做后端。
如果以后数据量大了卡了，只需要优化后端即可。

[thonatos]

@yakczh
关于post什么的，其实并不影响业务系统，模块的分类并没将业务分离出去，所以，还是原来的操作。

@learnshare
嗯，平衡，更合理的职责划分，不过对前端的要求略有增加，但问题应该不大，只是VC两部分嘛

@yun77op
嗯嗯，我考虑下我们这里要不要这样做哦~

@fundon
谢谢~

[thonatos]

@dong3580

是的，我们这么想这样做的根本目的也是为了以后不会相互影响，当业务量增大的时候，完全可以用负载均衡服务器将请求转发过去，当然，还是要做一些优化处理；最想用的地方在于，后端的服务器如果是集群了，那么语言就不限制了，甚至于说，未来根据需要，后端集群根据业务使用完全不同的语言也是可行的。

[thonatos]

@blue7wings

其实换什么不用紧，要这么做就是为了解决后端语言的问题，使得各种语言的使用不影响前端的统一，换言之，前端只需要做一次，后端随便你怎么换，我只要知道接口就行了，其他的，前端不用再去关心了~

[chx007]

我们之前的前后端分离，模板渲染全部在前端完成，后端提供RESTful接口让前端用XHR来加载。这会导致`空白首屏`等待问题。

为解决这个问题，我们现在尝试在前后端之间加一个以node开发的中间层，用来渲染首屏输出，而后续的界面上数据刷新，还是由前端XHR后端数据后在浏览中进行模板渲染输出。这里面有个问题是首屏输出与后续界面上数据刷新，在代码逻辑上其实是一致的。所以就设想尽可能让每个功能组件在Node和浏览器端都能运行。找来找去还是觉得React更适合做这样的事情，而跟后端RESTful打交道，可以用superagent，因为它将XHR和node上的http.ClientRequest封装成统一的接口。

[learnshare]

@chx007 首页白屏的问题，加一个 loading 动画就好了...

或者首屏的资源尽量压缩减少，最好首屏的资源 HTML/JS/CSS 各有一个，HTML 资源附加一些内容进去。当然，大规模的应用资源加载量不容易控制。

昨天看到朵唯新机的页面，200 多张图，18M 多资源，加载了三分半。

[lygmqkl]

其实前后端分离设计的关键在于架构，并不在代码层面上， 国内的伪RESTful 架构太多，如果有一个牛B的架构师，团队最少可以减肥30%，想想少了30%的人员和沟通，开发效率要多高？ 成本要节约多少？

但是很不幸国内架构师好像不是那么热。

PS: 最近在给一个知名xx做一套架构，用的就是RESTful 的api，我都是采用非常简单的逻辑，但是目前来看，代码实现的难度 和 大家开发的效率都得到了有效的保证，当然运行效率也是很高的，毕竟RESTful 天生的statelessness 就已经足够优秀了。

[tojoevan]

不错哦，支持哦

[thonatos]

@lygmqkl

那么后端通信方面效率怎么保证呢？求教一下。

[thonatos]

@learnshare

首页白屏单纯用loading属于体验上的改善，并非结构和架构的改善，作为前端狗，我对体验非常在意，不过总归不是最佳对吧

[boom11235]

我聊聊我的想法：（仅作为一个小小前端工程师）
1）不应该因为技术而技术，采用某种技术方案一定是在它可以帮助你解决一些需求的前提下，看清楚前后端分离给现有团队带来的好处和麻烦是很重要的。
2）作为前端工程师来说，node层的加入，提高了自由度，可以更多方面地handle交互相关的东西，但是需要知识层次需要比原有的前端知识更深入到http，网络等。
3）实践的方式，会因实际业务和团队而千差万别，SPA如果适合业务和团队的话个人感觉是较好的实践，前端承载的相对会少也会舒服一些。其次，选择中间node的一层，那么前端需要承载起后端开发的一些东西，或者需要node工程师（如果是web，实际上我不支持node工程师，而是更加优秀的前端，除非是专业性的一些东西，如游戏后端引擎等，因为node工程师即加多了一层，沟通成本，人员成本都大了），现有的node已经可以较好支撑起这一块了。再其次，工具，我认为前后端分离更多着重在职责分离，以及降低沟通成本，提高独立开发可行性，虚拟后端mock以及服务的工具，可以让前后端都独立开发，沟通好交叉部分的数据结构即可，同时也方便做相关测试。