关注者
2,142
被浏览
107,313

50 个回答

我比较认可rank的观点,MidWay 尽管目前带来的实际价值不高,但是在引领方向,在为真正前后端分离的落地做铺垫。而且在这个项目的影响下,支付宝和天猫已经开始NodeJS前后端分离的技术规划,这本身就让人兴奋。

基于Node的前后端分离有两个价值

一,异步

淘宝首页就是被几十个HTML片段(每个片段一个文件)拼装成,之前PHP同步include这几十个片段,一定是串行的,Node可以异步,读文件可以并行,一旦这些片段中也包含业务逻辑,异步的优势就很明显了,真正做到哪个文件先渲染完就先输出显示。前端机的文件系统越复杂,页面的组成片段越多,这种异步的提速效果就越明显。

二,前后端模板统一

无线领域很有用,PC页面和WIFI下页面适合前端渲染(数据Ajax到前端),2G、3G弱网环境适合后端渲染(数据随页面吐给前端),所以同样的模板,在不同的条件下走不同的渲染渠道,模板只需一次开发。

NodeJS 的很多潜力可能还没有发掘出来,我们也在摸索,而且淘宝现在已经开始考虑将Node部到CDN上了,这将为前端工程师带来更多的想象空间。

还有人提到前端工程师能力是不是跟得上,我觉得一定会跟得上,跟不上的伪前端正好被淘汰掉。
我这几天在项目中用了这个方案,感觉前后端之间高的吓人的协作成本的确是下降到了舒适程度。我觉得主要是建立在这几点:

1. 服务器前端语言和浏览器语言一致,基本消灭了这个层面的阻抗失谐问题(并非完全,比如字符串模板语言和浏览器 DOM 之间的仍然存在较大的阻抗失谐问题,但这并不是这个前后端分离方案该 Cover 的,这个方案 Cover 到前后端模板共用已经非常赞了)。
2. 后端接口定义的约束,在接口层面做了详尽的基础约束。并且给出了一些可以让两端开发者自我约束的解决方案,这个就算在很多公司的纯后端系统之间也没有做到这么好。
3. 前后端的关系被约束到了一个 JSON 封包的接口中,因为结构的简洁性,进而让两端的边界定义更加明晰。
4. 前端的空间大了,可以做很多之前只能想,但是不能玩的事情了。但局限性依然有,比如WebSocket ,这个必须在 Nginx 、 HaProxy 等等的各层支持 WebSocket 的转发(我只是举个例子,因为这要打通很多的运维关卡,往往一个前端很难做到)。但以前只能写 AJAX 想想 BigPipe ,但现在可以用着 BigPipe 想着 WebSocket 。这都是一步一步前端扎实向前的表现,很赞。
5. 更像是个程序员了,原来竟然还有套页面这个词。。。你想想,这个提升还是很赞的。

一开始我对于这个能否在这个公司做起来很好奇,但是现在觉得还是比较靠谱的,尤其是在看过 淘宝技术十年 那本闲散册子之后。这个方案中很多需要后端同学去做的事情(比如接口服务化、系统的拆分、基础系统提供细粒度接口给上层业务系统),已经在几年前就做过很多次类似的了,并且有些都取得了商业的成功(比如:淘宝开放平台);对后端同学的好处,想必在前面的过程中也已经接触到了一些(不是完全一样,但是总比没有过往经验好太多)。

我觉得最大的问题还是在现有前端的能力上,不过我觉得我都可以基本搞定,问题应该不大。毕竟加的这层需要学习的知识也不多,无非还要多和运维打打交道。