(一)也谈基于NodeJS的全栈式开发.pdfVIP

（⼀）也谈基于NodeJS的全栈式开发 原⽂：http://ued .taobao .org/blog/20 14/04/full-stack-development-with- nodej s/ 作者：常胤 前⾔ 为了解决传统Web开发模式带来的各种问题，我们进⾏了许多 试，但由于前/后端的 物理鸿沟， 试的⽅案都⼤同⼩异。痛定思痛，今天我们重新思考了 前后端”的定 义，引⼊前端同学都熟悉的NodeJS ，试图探索⼀条全新的前后端分离模式。 随着不同终端(Pad/Mobile/PC)的兴起，对开发⼈员的要求越来越⾼，纯浏览器端的响 应式已经不能满⾜⽤户体验的⾼要求，我们往往需要针对不同的终端开发定制的版 本。为了提升开发效率，前后端分离的需求越来越被重视，后端负责业务/数据接⼜， 前端负责展现/交互逻辑，同⼀份数据接⼜，我们可以定制开发多个版本。 这个话题最近被讨论得⽐较多，阿⾥有些BU也在进⾏⼀些 试。讨论了很久之后， 我们团队决定探索⼀套基于NodeJS的前后端分离⽅案，过程中有⼀些不断变化的认识 以及思考，记录在这⾥，也希望看到的同学参与讨论，帮我们完善。 ⼀、什么是前后端分离？ 最开始组内讨论的过程中我发现，每个⼈对前后端分离的理解不⼀样，为了保证能在 同⼀个频道讨论，先就什么是”前后端分离”达成⼀致。 ⼤家⼀致认同的前后端分离的例⼦就是SPA(Singleapplication) ，所有⽤到的展现 数据都是后端通过异步接⼜(AJAX/JSONP)的⽅式提供的，前端只管展现。 从某种意义上来说，SPA确实做到了前后端分离，但这种⽅式存在两个问题： WEB服务中，SPA类占的⽐例很少。很多场景下还有同步/ 同步+异步混合的模 式，SPA不能作为⼀种通⽤的解决⽅案。 现阶段的SPA开发模式，接⼜通常是按照展现逻辑来提供的，有时候为了提⾼ 效率，后端会帮我们处理⼀些展现逻辑，这就意味着后端还是涉⾜了View层的 ⼯作，不是真正的前后端分离。 SPA式的前后端分离，是从物理层做区分 （认为只要是客户端的就是前端，服务器端 的就是后端），这种分法已经⽆法满⾜我们前后端分离的需求，我们认为从职责上划 分才能满⾜⽬前我们的使⽤场景： 前端：负责View和Controller层。 后端：只负责Model层，业务处理/数据等。 为什么去做这种职责的划分，后⾯会继续探讨。 ⼆、为什么要前后端分离？ 关于这个问题，⽟伯的⽂章Web研发模式演变中解释得⾮常全⾯，我们再⼤概理⼀ 下： 2.1 现有开发模式的适 场景 ⽟伯提到的⼏种开发模式，各有各的适⽤场景，没有哪⼀种完全取代另外⼀种。 ⽐如后端为主的MVC ，做⼀些同步展现的业务效率很⾼，但是遇到同步异步结 合的页⾯，与后端开发沟通起来就会⽐较⿇烦。 Aj ax为主SPA型开发模式，⽐较适合开发APP类型的场景，但是只适合做APP ， 因为SEO等问题不好解决，对于很多类型的系统，这种开发⽅式也过重。 2.2 前后端职责不清 在业务逻辑复杂的系统⾥，我们最怕维护前后端混杂在⼀起的代码，因为没有约束， M-V-C每⼀层都可能出现别的层的代码，⽇积⽉累，完全没有维护性可⾔。 虽然前后端分离没办法完全解决这种问题，但是可以⼤⼤缓解。因为从物理层次上保 证了你不可能这么做。 2.3 开发效率问题 淘宝的Web基本上都是基于MVC框架webx ，架构决定了前端只能依赖后端。 所以我们的开发模式依然是，前端写好静态demo ，后端翻译成VM模版，这种模式的 问题就不说了，被吐槽了很久。 直接基于后端环境开发也很痛苦，配置安装使⽤都很⿇烦。为了解决这个问题，我们 发明了各种⼯具，⽐如VMarket ，但是前端还是要写VM ，⽽且依赖后端数据，效率依 然不⾼。 另外，后端也没法摆脱对展现的强关注，从⽽专⼼于业务逻辑层的开发。 2.4 对前端发挥的局限 性能优化如果只在前端做空间⾮常有限，于是我们经常需要后端合作才能碰撞出⽕ 花，但由于后端框架限制，我们很难使⽤Comet 、Bigpipe等技术⽅案来优化性能。 为了解决以上提到的⼀些问题，我们进⾏了很多 试，开发了各种⼯具，但始终没有 太多起⾊，主要是因为我们只能在后端给我们划分的那⼀⼩块空间去发挥。只有真正 做到前后端分离，我们才能彻底解决以上问题。 三、怎么做前后端分离？ 怎么做前后端分离，其实第⼀节中已经有了答案：