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

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

1.关于通信效率
用node做前端的一部分，MODEL（这里应该是伪Model了，毕竟他只是通过http之类的方式）与后端（如java的逻辑、运算服务器）的通讯效率问题。

@lygmqkl 讲了他们的实践，基本是相同的，也略有增加，但是同等的收益是在后面的，所以这个效率问题，放在整个项目的生命周期里的话，是缩短的，所以这部分，我认为效率增加了。

2.关于前后端定义
有人对于这里存在不同的理解，其实之前就说过了，这里是对也许进行了分离，将MVC中的VC部分纳入前段，M部分交过后端，也许你不认可，但是这种的分离，给了前端更大的自由度，也让后端能够更专注于业务本身，而非交互逻辑。

我们内部一致认为，所谓前端，是指一切与用户/客户端的交互相关的部分。

3.关于职责明确
前后端分离的源动力在于系统的分离，使得团队人员的职责明确，过去后端参与太多交互相关的内容，对他们来说，其实是在浪费他们的时间和精力，例如tp中（$this->display('index')）这样的东西，每次你一改动就让他们改，不觉得eggTeng？（别说什么模板之类的，同样的功能，我们有N种实现方法，我们只是在找一种更好的，更合理的对吧~）

4.关于使用与否
生命在于折腾，不是为了技术而技术，技术是在改善。

这样的讨论的目的是根据具体应用场景来定的，比如我需要一个庞大的数据运算模块，这里我也许可以用C来实现，如果为了语言统一，大可以将C写成node的组件，可当我们面对的时十台百台服务器，但并非每一台都要做运算，有必要每一台都要一个这样的node组件么？

成员职责的划分，项目模块的划分，是源动力吧~

[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）~

[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以及服务的工具，可以让前后端都独立开发，沟通好交叉部分的数据结构即可，同时也方便做相关测试。

[ZackYang]

@thonatos 服务端客户端在不在一个网络完全没影响, 最佳实践应该是把客户端放CDN.

[ZackYang]

@thonatos 进入白屏的问题, 完全可以使用AMD解决, 按module加载, 不需要一开始加载所有的js.

[thonatos]

@boom11235

非常赞同你的看法，职责的分离以及前端自由度的提升是试验的动力之一（二），同时我也不认为让前端熟悉一部分后端的内容是压力，相反，更该是能力的提升，所谓全栈的说法不是很认同，做前端，又同时能对其他内容有所涉猎的能更好的发挥自己的价值，仅仅做demo，很好，但不是最好。

[thonatos]

@ZackYang

进入白屏这个问题，是我太偏激（见谅），这个，准确来说，应该是无解的……（试着将网速限制到足够低，必然还是会出现），即使采用Bigpipe的方式，也依然是不能解决的，这个话题略过吧，sorry

[lygmqkl]

@thonatos 不知道你说的通讯效率是什么？ 我用的是php脚本来搭建后台，一次请求包含所有的信息，对应服务器返回需要的json 数据，不觉得效率上会有什么问题啊

PS: 服务器组成是 6台 web + 2 db

[thonatos]

@lygmqkl

我是指通过中间间（如nodejs）与后端逻辑服务器交互，对比直接传统的架构，总体的效率如何，指:耗时，稳定性（是否丢包等）。

[lygmqkl]

@thonatos 耗时 如果条件相同的情况下，应该是不相上下，甚至可能会多损耗5%在传输上，因为对比传统的session结构，request header里要包含的东西显然多了很多，但是这个损耗还回来的是，你可以同时有10台web服务器响应，100个用户的请求，每台服务器处理10个，而且随机选择服务器就可以，因为每一台服务器对相同的request header 返回是一样的。

稳定性应该是提升了的，当然是在请求量巨大的场景下。

请特别注意，在RESTful架构下，缓存更多的是做在客户端，即js代码里，一旦缓存了，请求都不会发送，只要设计的足够好，还是很强悍的。

[otakustay]

1. 阿里的前后端分离有它特殊的时代背景，比如前端想要的接口和后端想提供的对不上之类的
2. 你的第2张图里的后端是啥语言，如果不是NodeJS的话，左边那个NodeJS也没必要吧，和后端语言保持一致不是挺好的吗？这个NodeJS放在这的意义是啥
3. NodeJS不能算在前端里吧，这里的分界线很不明确？

[hitsmaxft]

前后端分离的最大驱动力是团队拆分.. 这不是笑话. 业务团队和ued团队不在一个队伍里, 带来的协作问题不是一点两点能讲完的..

前后端分离倒不是最核心的目的, 而是要分清楚 模型, 业务, 和模板的开发归属. 真正原因, 是在现有的协作分工模式下, 最大限度地解放生产力...

[crossmaya]

我不知道你这个php和java在这里做什么用，分离不就是统一业务系统吗，后端nginx已经把事情做完了，你这php和java在这里的意思是提供动态内容输出？还是只作为一个入口。。

[thonatos]

@lygmqkl

嗯嗯，知道了，谢谢，回头我实际试验一下，看看效果。

[thonatos]

@otakustay

1.应用分具体场景而定，阿里的模式也不全是因为“对不上”吧
2.这里主张的前后端分离，换言之是重新定义了前后端的范畴，和传统的前端定义有区别，显然也就需要其他来做后端了，语言一致只是相对而言，并非全部一致，比如多台服务器的时候，你也许能理解这样的好处。
3.仔细看图2，你应该大体能理解这里——前后端的概念。

@crossmaya
你不知道的原因在于你对这里所说的前后端理解上的偏差，前端不只是页面（css/html/js），前端应该是与用户交互的部分，换言之，ios/android的客户端（app），也可以理解为前端；后端是指逻辑和业务系统，比如说进行数据运算，比如说是持续的数据处理什么的。

仔细看图，应该能明白我这里的java和php只是泛指，也可以是c，也可以是go，或者python等等，他是指的整个项目的一个部分，显然动态内容的输出了，内容的输出交给nodejs来做的，可以是静态，也可以是动态，甚至说，可以是cdn。

[thonatos]

@hitsmaxft

嗯，团队合作的时候，分离的确很便利，比如说我当前的开发往往需要后端支持：

我们后端使用了redis，而我本地是不具有redis的，另外一些具体的配置，也不可能完全复制到本地，每次测试，往往需要我push，后端pull，测试反馈bug，重复上述步骤，很麻烦。

如果分离了，那么我负责页面（包含controller，view），model那边利用接口，可以轻松的实现现有的模式，只要后端保证model层的稳定即可，当然了，有人可能会说我们可以修改现在的模式，让我本地可以访问redis之类的，但那终归不是最好的解决方法，对吧？

扩展下，我的本地环境，其实就是充当了负载均衡控制的web服务器之一（web服务器是多台，例如5），同时业务服务器有2台，那么，web是独立的，他可以自主部署自主测试，业务那么不需要重复做”无用功“了。

这样才是真正的解放生产力么(⊙_⊙)？，前端学点简单的VC算什么难度~~~~对吧~

[maxiujun]

我在一家专门提供外汇交易平台解决方案的公司，最近一年都在用ember.js做类似的工作，效果不错，我觉得对于页面上复杂逻辑的实现，ember,angular 帮助非常大。同时后台用spring mvc 的rest借口也同样有我一个人完成，这样就可以平衡前和后端了。

[thonatos]

@maxiujun

嗯嗯，一个人做的话...确实是完全自主发挥了，我的主管大人直接发话了：
“统计哪里，就当你的试验田，随便你怎么搞~”

这样的分离也没有要完全放弃ember，angular的说法了，主要是如我附言那边写到的原因喽~

[maxiujun]

其实关键的问题就是前端和后端的界限在哪里，我们这的界限就在java的接口上，所以我们这么做也就好理解了。
另外，做了这么多实践，感觉，只要把前端的工具链（Grunt,bower 等）弄熟练，主题里面提到的“分离”就水到渠成了。

[thonatos]

@maxiujun

讨论再多，也只是为了提高生产力嘛~
最后做的东西即使一样多，但是中间环节的减少，在团队协作中，确实是巨大的提升。

（对于个人开发者来说...基本可以认为是一样的，至少过去我做东西，从来都不会考虑这个.）

前端和后端的界限，我认为是职能，或者说职责，减少无用功，这样定下的界限，更好一些。

[exodia]

好无聊，过来练习下写作和表达能力。

首先，我觉得不要扯性能方面的问题，性能对于绝大多数非首页场景都不会是瓶颈。真要追求极致性能，就像淘宝首页一样，写成静态 html好了。


解决前后端分离的问题，目前大概有以下几种方案：

1. 前端写后端模板

1）前端和后端的模板是不一致的，比如前端可能用 Hanldebars，后端 java 经常用velocity，php 用 smarty，都由前端一起维护。比较恶心的问题在于，公司大了，部门多了，业务线多起来了，可能技术选型都不一样，比如有的业务线用 php，有的用 java，还有的用 python，他们的模板引擎可能都不一致，一是碎片语言实在太多了，更严重的是阻碍组件的复用，比如淘宝的通用吊顶和吊尾以及登录框是可以全站复用的，但之前用 java 写的，如果有的业务线用 php 咋办？于是他们对这些组件进行前端组件的静态化处理，即这些组件变成了 html+css+js的片段给其他业务线去用，数据请求通过 ajax 去做；但这些组件的一个特点是，依赖后端的动态数据较少，比如吊顶只是简单的一个登录信息请求即可，不适合需要大规模的后端查询页面。

因为1）的问题，于是有了下面的 2）

2.1） 前后端统一模板，模板语言嘛，用不同的语言都写个引擎就好了嘛，比如后端 nodejs 用 jade，咱前端也用 jade，嫌慢，咱先编译好。这个我还没找到比较大型的案例，我自己做着玩玩的时候用过。

2.2）有人觉得每个语言都要为一个模板语法写一个引擎，维护成本也大，模板语法一更新，所有引擎都要更新，真是去你大爷的- -！ 于是呢，linkedin的做法是前后端统一模板为dust（你猜对了，js的模板引擎）, 后端在渲染模板的阶段，起个线程跑v8引擎，去做模板渲染。于是成功解决了web组件（前后端都有）复用的问题。


1方案的普及需要有好用的工具提供给前端做开发调试mock等，比如淘宝曾经出了个 vmarket，据说难用所以没然后了。然后，fis 也有针对这个专门做了工具，具体去 fis 主页看好了，最近我在试用他的 java 解决方案，感觉还是比较容易上手的。

2. 前端 mvc（webapp）

感觉不用太多介绍吧，这几年比较火的架构，模板在浏览器渲染（尼玛，你说后端返回渲染好的 html 字符串，艹，这还能叫前后端分离- -！！！！）。

很多人这个方案问题在于seo 和性能。就 seo 来说不是太大问题，比如我从组里同学那获知的用个 phantomjs 渲染出页面丢给 robot 就好了，以及 google 是有针对 ajax 页面做索引的。

再说说性能，linkein 不用前端 mvc 的一个很重要原因就是性能，不过人家是因为页面要兼容到 ie7，ie7没有原生的 JSON 提供，解析起来确实是巨慢无比，所以放弃了。我觉得吧，如果你的项目仅需要支持ie9+等现代浏览器，基本可以考虑采用这个方案试试，当然 seo 这块我也没涉及到，不好扯淡，有朋友去试了可以教教我~


2方案对前端的要求会比1更高些，大规模项目的路由设置，模块切分，mvc 的职责，代码规范，目录结构的组织，都需要有一定功底，否则会玩脱。

这个玩法比较多，框架也很多，angularjs，ext，然后是我们这的一系列组合： https://github.com/ecomfe/er
https://github.com/ecomfe/esui
https://github.com/ecomfe/oo
https://github.com/ecomfe/uioc

打广告就是爽，呵呵呵呵。


3. 加一层中间层

比较火的，淘宝中途岛，比较低调的， fis 的 yogurt。 线上案例，百度音乐移动版，淘宝的对外项目不是太清楚，麻烦知道的同学告知下，内部项目主要是之前的数据平台部门的一些产品:在云端等。

我曾经是这个方案的拥护者，在经历了北京velocity大会的 fis 和淘宝的前后端分离实践分享，前不久d2的支付宝前后端分离实践分享，以及最近自己在搞一个业务线前后端分离的实践后，我现在成为这个方案的反对者。至少我觉得这个方案不适合大多数场景。

我们看看这个方案想要解决的问题：

1) 前端依赖服务端开发环境
2）在服务端View层高度耦合
3）沟通成本高
4）职责不清晰

对于1），可以通过开发优秀的工具去解决，至少 fis 的 jello 还不错。
对于2），不明白这耦合在哪里？
对于3），阿里的场景是前端写html Demo，再丢给后端套，敢问有几个公司这样做？
对于4），我觉得和2）一样，说的太虚了。你要说职责清晰，学学腾讯把 html css 也分出去得了
- -。。


关于 ppt 中说前端 mvc的问题，限于篇幅和精力，我懒得吐槽- -！，@otakustay 可以来试试- -！

再看看这个方案会遇到的问题：

1）学习成本实质是最高的。

天真的以为仅仅是语言没有学习成本？ 后端的各种技术，安全，日志，监控，并发，事务，分布式 session，数据库读写分离，确定一般的前端能搞定？阿里经历了多少年，java 发展了多少年才成就了现有这么成熟的体系。 bat 或许能用 nodejs 去玩玩，因为技术的服务化和平台化比较成熟，都会提供服务化的api来用， 比如分布式的 session 访问，你只需要去调接口，不用自己去用 nodejs 实现一套了，再说用户信息，订单信息也是提供接口给你，至于他们怎么做性能调优，安全处理，数据库设计你都不用管。 但是一般的公司能做到这么高度的服务化么？

2）现阶段绝大多数前端水平还跟不上

即便很多前端号称自己会 node，也只是停留在写工具层面。

在 velocity 上，淘宝的分享者（p7）说，他们请了后端的同学帮他们实现 nodejs 的 session 读取框架，我就跪了好嘛，整个淘宝 ued 都找不出一个前端能写这个，你确定有几个前端有这个技术能力去 hold 这种技术？
在阿里也就那些数据平台部的人在这方面比较牛逼了，但是别人一直都是以后端为主，前端为顺手写，起点和一般前端完全不同，现在最多就是挂个前端的 title 在上面。

3）想要解决的问题都可以有更快捷简单的方式去解决

对大多数场景来说，我更推荐1的解决方案，简单快捷，没有太多成本。比较成熟的公司想要做组件化的复用可以参考 linkedin 的方案。 中间层可能只是一个舍近求远的方案。


最后，中间层这个方案给我感觉最多会成为一个，由 nodejs 渲染的模板引擎方案。

当然，我个人倒是蛮希望这个方案能够将前端的总体水平提高一个档次，能够将前端工程师变为工程师。

[HaEx]

@exodia 就事实而言，最后的描述的三个问题中，有一个里面没一句话是对的，当然我也不知道您是从哪里打听到的；至于其它的，就不吐槽了...

[exodia]

@HaEx 我比较喜欢直接吐槽，这样我可以认识到我的问题，至于你说最后的三个问题，有一个不对，那么我猜你说的是第二个，这个我没有打听，因为这个是我在 velocity 上直接问的清羽，是他说的，至于他说的是不是事实，我只是转发。 数据平台部门在 node 牛逼，这句话我确信没啥问题，当然，可能现在没这个部门了就是，呵呵

[thonatos]

@exodia

看到神仙打架了么这是....（玩笑）

这里开帖子就是为了探讨这个问题，打广告神马的自然是很欢迎了，有更好的解决方案自然无需造轮子了，EFE与淘宝UED的使用场景不同应该是无可非议的了。

webapp方式的解决方案，是我一开始就在用的，甚至于现在还在用（目前还没开始试验淘宝的方式），SEO方面的问题，个人认为不应该是问题，可这个显然依然是问题，至少DU厂的搜索引擎，对Ajax站的支持貌似没Google那么友好（如果有错，还望指导下DU场针对Ajax站的SEO方法）

既然有心情学前端，自然不能仅仅停留在页面仔的范畴，精通另说，最起码要有涉猎，这样的学习成本，是值得付出的，编程语言服务需求，说到底，选择什么还是为了项目本身，在这之外，能让自己能力有所提升，也是一件很开心的事情~

中间层的方案，V的职能不可否认，C的职能或者可以更进一步抽出？
或者，也许我们可以试试MVC三者的进一步分离？

[soulteary]

@exodia 这几个问题如果想知道答案，不如发简历来，如果ok，我们还能对半分入职的奖励，2333

如果不发简历的话，那就无责任吐槽加回复一些我所知道无伤大雅的东西吧。

有的业务和实现还是蛮复杂的（历史原因，发展原因，各种其他原因），即使接口化程度好一点，如果你也有做的话，应该明白这点，session这个我刚刚顺手看了一眼代码，似乎苏千大神12年就写了，不过14年又更新了一部分，或许我们说的不是一个事吧...

如果抛开公司业务，我觉得不管是用redis/mysql还是写文件方式来写一个node版本的session rest接口也不用多久，何况团队里好多技术碾压我的前辈...

弱弱吐个槽，朴神很强力吧，但是职级是P6，诶，是不是说明层级不能完全作为你的论点的数据参考了呢..（朴神，我不是故意黑你的...）

第二段同意部分语句，作为团队拖后腿的渣渣从来没敢说自己会node，或许是团队大神封装中间件略赞，或许是小伙伴强力，不管是安全过滤/路由定义/日志调试/数据代理(尤其)都是用的爽的不要不要的，自己专注业务逻辑就可以了，或许你会觉得业务模型简单，但是其实承载的内容真的不少，还有巨量的流量每天帮你跑各种分支（233）...

总之，很多事情不能用简单一概而论，自从用了中间件，大概出活更快了（即使需求和要做的事情更多了），和后面数据接口那边的童鞋只需要约定数据格式就行了（其实还可以更狠点，直接捞数据，不过这样就不是各司其职了），有的时候做事情，互相旺旺贴下接口定义，大家就心照了，多愉快。

对了，好像还有说性能来着，只能说双十一毫无压力，等着看双十二性能图表中~

比起三天两头开个会，各种约定，最后接口变了，前端模板逻辑甚至业务逻辑要重写代价小的多吧，即使数据源那边变了，我们的改动也不过是nodejs接口层修修改改，做做测试就完事了，不过这样也有个坏处，就是可能前端比后端完成事情的时间点早太多，去投入别的事情了，过段时间要返回来和后端联调（同时其他事情来了，会爽的不要不要的...）

以上，感觉自己title只是前端，连工程师都不是的渣渣吐槽完毕。

--EOF--

[thonatos]

@soulteary
@exodia
@HaEx

233...已然变成吐槽乃们的吐槽贴了啊~

虚心学习中，来场技术大比拼挺好，出点干货对群众们做下知识普及？

[exodia]

@thonatos seo这块，百度做的确实不够好，该黑的还是要黑，就事论事，解决方案文中提到过一个，针对 robot 使用 phantomjs 渲染页面丢过去，我没试过，但理论看着可行，所以我也希望有人尝试一下论证。 另外，也没啥打架不打架，我只是想明白中途岛方案和其他方案相比，到底优势在哪？仅仅是想探讨技术而已，请尽可能的，也尽情的在技术上扇我耳光。。。。所以如果有支持中途岛的同学，我仅仅是想和你们交流下技术方案而已，不要想太多了。

@soulteary 既然你们是中途岛的拥护者，不好好的推广，说说你们的方案对比其他方案的优势，掩着藏着是为何？ 既然你们提倡这种模式，又出来做分享，解决别人的困惑，说服别人用你们的东西应该是很乐意才对。

关于你说朴灵强不强，我先放着。。。。我也不是要从层级去论能力，但很多时候，层级确实是和能力挂钩。

你说的什么中间件用起来爽，完全没有去回答我提出的疑问，java 不能有中间件？相信阿里的 java 中间件用起来更爽。

再说你的约定数据格式的问题，前端写后端模板，后端一样可以做到只准备数据。难道其他前后端分离方案就不能愉快了？

说性能，你觉得双十一性能稳定是因为你们用了 node？。。。

最后你的接口变了的问题，其他方案的改动会比你的改动代价大？没记错的话，你们是 java 和 node 在同一台机器部署，如果 node 要重新部署了，java 会需要一起部署不？


你说到了苏千，我和你观点一致，他确实是大牛，但是，他确实是搞后端的啊，呵呵，当然现在转到支付宝做个挂个前端 title，做架构的事嘛。包括大部分好用的 node 中间件，你能给我说说这些作者有几个是前端出身？ 而阿里一开始就搞前端的，有几个写出了好用的中间件？


另外，我也是经历了写 html demo，到写前端 mvc，再到现在体验前端维护后端模板的方案，才会有了此次的回帖。我想要的方案很明显是ROI 最好的那个。。

[soulteary]

@exodia v2没有打呵欠的emoji很是忧伤。

1.不应该把每个人都看成方案的推销者，我只是愉快使用的用户而已，（这个们字哪来的，别是突然又给我扣个帽子，让我去代表其他人吧，我只能代表自己，以用户身份，233333...）

2.掩藏？哪里来的神理解，来吐个槽而已，本来就没计划说服谁，神马很乐意是你按照自己的情况推理出来的么...另外，业务数据邮件是三令五申提醒过的，如果你不懂的话，请参考自己公司的商业规范和保密协议，如果没有的话，那么这位老板请无视我的这条回复。

3.帖子里说能力层级相关的，和技术方案选型又没啥关系，各种因素混合在一起的结果，纠缠起来没啥营养滴...2333

4.中间件多了去了，不知道为啥前端来个解放生产力的工具就大惊小怪的...你觉得啥爽用啥就好，不用告诉我...

5.你动力和愿景这么大，把简历发来，咱俩对半分奖励不是挺好的么...（该解释的之前吐槽不是说了么，自己不看背景乱嚷嚷，有意思么，你觉得有意思，我也没辙..）

6.性能，好吧，我严谨点，我接触的业务毫无压力...童鞋你神经别蹦的这么紧，太困就睡觉吧...

7.你还真是替这个方案操心，你猜猜？

8.po主分享的ppt的作者不就是纯fe么，不过你纠结大家是做什么的有啥意义，这个争论点可以带来技术的提升还是帮助你快速完成需求？ps：自己cat node_modules/package.json看作者不行么...233

---

@thonatos 下次D2？

[thonatos]

@exodia

对于SEO我看了国内外的一些解决方案，但是感觉上，有点针对搜索引擎特殊处理的情节在里面，度场比较严格，估计按那种方式会被关小黑屋……

当然了，最好是度场尽快对类SPA做优化了。

[thonatos]

@soulteary

嗯嗯，有机会的话去见识学习下，南京到杭州挺近啦（见妹子是关键……距离ALI两公里，←_←），大四狗，还在实习期，不知道时间能否允许了，早点休息吧，安喽

[soulteary]

@thonatos SEO的话，这个要分情况讨论的，一个是蜘蛛是否支持异步渲染；google有相关规范，百度未知；针对google可以直接提供接口数据，以供抓取索引；针对百度类型的蜘蛛，可以考虑针对UA或者IP做特殊模板输出，或者服务端代理入口转向特殊url...

特殊模板这里又有一个分支，是神马格式展示，xml/html/micro data/...而这些模板由谁处理...是否要做前后端模板共用，复用...

总之，这个事情应该根据自己业务具体情况具体讨论了...v2上吐槽再多都是空的= =

[thonatos]

@soulteary

就是担心针对UA做处理，会被关小黑屋……然后就从一个技术问题转变成一个蛋疼的商讨接洽过程（实现上问题不大），不过说到底，我是倾向于中间件的做法，SPA的模式，终究还是有些小坑的，局部使用MVVM更合理一些（主要针对普通的对外项目，不专门做处理，也是解放劳动力吧，T.T）

……碎觉碎觉，迟到了要扣工资滴，可怜的实习生有木有-_-||，明天搞个demo测试一下，看看效果啦，安喽

[konakona]

我觉得这样的架构设计有点意思。
不过你们之前的项目是PHP开发，以ThinkPHP为框架。
现在要改为Nodejs，是不是未免变动太大？这样改动期间如何迭代原有项目的维护工作？如何合理重现原有功能结构等等？

[exodia]

@soulteary 能解决我的疑问才是真的，逃避技术点疑问，没有重点的回答也没啥必要继续了。我目前对淘宝ued一点兴趣都没，不用啥简历简历的，要解决问题，和要不要去ued 那一点关系都没；我从那出来1年多，在现在这个地方无比爽，就这样，，

[clino]

自从用avalonjs以后,已经自然而然这么做了,后端基本上只用提供api,其实这样感觉挺棒的,就是需要用对搜索引擎友好的时候还是用后端模板吧

[hitsmaxft]

@thonatos 当你想做点什么不用求着别人的时候,生产力就解放了.

[hitsmaxft]

在淘宝/百度下就不是谈技术问题了, 而是怎么推动百人/千人团队的技术更迭和方案更新了, 而且产品都是千万到亿级别的访问量.

这时候只有技术因素是不够的. 所以不知道上面的有啥好吵的.

[mengzhuo]

也有为了手机客户端和页面共用一套API而进行前后端分离的

[soulteary]

@hitsmaxft 估计是半夜写的焦躁了，上来居然吐槽显眼 = =...

也不完全是，有的时候使用者并不会太多，那么何来推动百人千人，而且类似方案不是也有好几套么...

[NearTan]

学校项目，也是前后端分离，然后前端跟不上，苦恼中

[thonatos]

@konakona

从长远来说，这样的改动是值得的，尤其是项目建设初期就这样做，更是容易实现。

1.改动期间如何迭代原有项目的维护工作
运行时期其实是多台服务器共存的，改动时期也是如此，那么是后端优先（如现在的php重构开始，完成基本功能，接口的开发），前端完成原有模板的升级（tp的模板，和现在的其实不冲突，可以直接拿来用.T.T,修改下模板输出的边界符即可无缝转换了）。

然后通过ip在入口（nginx）设置路由规则，局部更换到新的服务器，测试运行，测试完成后，全局切换过来就好了。

2.重现原有功能
这里想采用中间件的方案的时候，纳入了java和php两种，我们原有系统本身就是接口类型的，这里在未完全搞定之前，或者说之后，除了session这一块（主要是包含认证相关的部分），需要node完成，类似于业务逻辑，大可以还放在原有的tp上，待完成后再考虑迁移（tp移除认证，服务器集群做成内网，限制外网访问，明白什么意思吧？——好开放有木有。。。什么数据都可以随便拿。。。。T.T）

这是我得想法，有好的意见分享一下喽~

[yolio2003]

看完发现结论是：没人分离的聊前后端，哈哈哈

[thonatos]

@yolio2003

什么意思？

[yolio2003]

@thonatos 就是觉得都还在探索中，都做的不怎么样

[thonatos]

@yolio2003

╮(╯▽╰)╭，正在测试……明天公司例会上要演示-_-||

[JamesRuan]

说一下我们这边的想法。

首先，这是一个学校项目，而且目前还找不到足够有能力+有兴趣的小伙伴来完成，基本上就我和另一大牛YY中。

传统些，而且成熟些的分离方式是前端写后端模板，后端填数据，浏览器还是取页面。这种方式对一个比较成熟的团队来说更加问题，改造代价小；而优势也是显而易见的。

激进些，就是前端完成渲染，后端传数据，而模板和渲染代码都是静态的，由Web服务器搞定，大量的缓存可以推向前端。这样需要前后端之间定一个API。后端实现这个API，前端使用这个API。这样进一步带来了灵活性：后端可以是不同的平台，很容易扩展到多服务器；前端也可以是多平台。我们的应用有考虑到移动端的支持，默认还是开发一个适配移动端显示的HTML，但是由于API开放，相信以后会有其他的小伙伴有兴趣完成移动端的原生App。

然而这一激进的方案也有比较大的问题：目前API设计（我的主要工作）就是难点，由于业务逻辑有些复杂，单纯使用REST会使得有些业务需要多个API调用才能完成，从而产生原子性问题，需要引入状态，这又与REST的stateless设计冲突。另外，渲染代码和业务逻辑代码都由前端完成，使得前端的要求过高，学生中恐怕会难以找到hold的住的人（现在就是找不到人的状态啊！）

所以，有了第三套方案，即基于node或类似比较“轻”的技术来实现中间层，中间层负责业务逻辑，把多个RESTful的内部API调用转换成单一API的外部API调用，从而减轻传统前端的压力。这样，前中后端分别负责交互、业务、数据，缓存更加推向前端，缓存级别增加，同时系统解耦增加，代码逻辑更加清晰，维护性增加，扩展性大大增强。

但是，这第三套方案需要有两套API，精确定义两套API的转换方式（等于手写一遍业务逻辑），且可能设计过于复杂，具体实现时的编码、调试工作都会增加，我们本来就没几个人，怕是折腾不起这样一个系统。

另外，由于是学校内部项目，没有SEO和带宽方面的要求。

[thonatos]

@JamesRuan

时间也不早了，略困，-_-||
最近睡眠严重不足，老板看到了请自觉涨工资啊！
（╮(╯▽╰)╭，要真看到估计要扣……）

如果只是讨论分离，最简单省事的估计也就MVVM的方式了，不过，技术啊方案什么的，最终还是要服务于实际项目。

目前已经测试的是中间件的方式，大概一小时之前测试了一下从阿里云拿数据，效果还不错（打错字母那件事……先不讨论了，-_-||）。

时间上几乎没什么区别，毕竟还是类似的方法，不过是从浏览器转到nodejs。

类似职能分离这话就不吧啦吧啦废话了。

现实点的情况是这样，从前接口未变，后端没帮忙部署，我这里很轻松的完成了页面到测试数据到真实数据的全过程，各种参数随意打，想要什么要什么，不要太自由有木有？

-_-||，眼镜睁不开了，先睡了，目测要猝死，哎，享年22，大学未毕业，卒。

[HerrDu]

最近也在考虑前后端分离的问题，也看了淘宝的中途岛的思路。还是想问一下，把 python 代替 node 做中间层是不是也能达到同样的效果？
还有就是 调用 restful 接口的时候，是怎么解决跨域问题的？ 用的是 httpclient 吗？