node在现在为止算是前端不可分割的一部分了，那么从当初的无人问津，到现在的前端mv*架构采用node和webpack之外，许多的中大型公司也采用后端+node中间层+前端的模式。有人会问了，node的职责转发api，nginx不就能做到吗？为什么要用node？

一、传统前后端分离。

很多时候我们会认为前后端分离概念中，SPA做到了集中的展现。从某种意义上来说，SPA确实做到了前后端分离，但是这种方式有存在问题。

1.web服务中，SPA类的占比很小，很多场景下SPA不能作为一种通用的解决方案。(服务端渲染、同步+异步+异步混合)

2.现阶段的SPA开发模式中，接口通常是按照逻辑来展现数据的，有时候为了提高效率，后端会根据前端需要的数据结构做数据封装，这就意味着后端还是做了view层的工作，违背了前后端分离的初衷。

前后端分离的模式不止是物理层的区分，客户端上运行的就是前端，服务端运行的就是后端。这种想法现在已经无法满足前后端分离的模式。前端负责View层和Controller层，后端只负责Model层处理业务/数据，才是想要的真正的前后端分离的模式。

二、现有开发阶段出现的问题。

1.前后端职责不清。在传统的不分离模式中，我们看到一大堆复杂逻辑的前后端混杂在一起的代码会异常头疼，有的时候完全没法维护。虽然前后端分离能缓解这种问题，因为从物理层方面决定了不可能把前后端代码携带一起，但是治标不治本。

2.开发效率问题。在第一个问题影响开发效率的基础上，再说几个影响前后端开发效率的事。淘宝的web基本上都是基于MVC框架webx，决定了前端的职责还是写好静态demo，由后端翻译。传统前后端分离的模式中，后端也需要根据前端需要的数据模型进行返回(比如排序、筛选等),后端也没法摆脱展现的问题，专注以逻辑层的开发。

3.seo优化问题。虽然现在百度已经跌下神坛，很多公司已经不太重视seo优化了，而且我们也不指望一头凉水能浇醒李彦宏，但是很多需要从百度等搜索引擎引流的公司来说，seo优化不可谓不重要。但是传统的前后端分离模式通过ajax取回数据再渲染页面的做法对seo并不友好。而且谷歌公司也明确不会做谷歌中国。

三、node中间层。

如果想解决以上所说的问题，就必然需要一种web服务帮我们实现以前后端所做的事情，node应用而生。

这张图看起来很简单很好理解，但是有的人可能已经提出了以下几个问题。

1.SPA模式中，后端已经提供了所需的数据接口，View层前端已经可以控制，为什么要多加node这一层？
2.多加一层，性能怎么样？

3.多加一层，前端工作量是否增加了？

4.多加一层是否多加了一层风险？

5.node什么都能做，为什么还需要后端?(23333333.......)

很多项目中后端应用往往不止一个服务，而是一群服务，比如nginx的存在就是因为服务器上运行着多个服务，而不同的网络请求由不同的服务处理，这个时候nginx就扮演着中间层的角色。

一、性能问题。

分层也就设计每层之间的通讯，一定是会有一定的消耗的，但是合理的分层能让组织架构更加清晰，会大大提高开发效率，性能带来的损失是在一定程度上可以弥补回来的。

二、工作量问题。

相对于只做demo页面，工作量肯定是会有所增加。但是之前的模式下有联调、沟通等环节，这个过程是非常花时间的，也很容易出bug，所以虽然工作量有所增加，但是开发效率会提升很多。

有的时候后端出于性能或者可读性等别的原因，返回回来的数据并不适合前端直接使用。此时后端不需要或者简单的逻辑就可以交给前端来做，比如排序、筛选等功能，前端也可以抹平对接口的调用方式，封装一些自己所需要的数据，也可以在一定程度上提升开发效率。

三、安全性问题。

随着node中间层的增加，系统、运维。安全部的同学们也会加入到基础建设中，他们会帮我们发现完善各个环节出现的问题，保障系统的稳定性。

四、为什么还需要后端？(java/php/go)

我们的初衷是前后端分离，各司其职，这个并不是我们需要考虑的问题。而且处于线程中node并不占优势。我们考虑的是专业的人做专业的事。(此时脑海里闪现复仇者联盟4最后雷神和星爵争船长的那段)

虽然node中间层的全栈开发模式让人兴奋，但是基于node的全栈开发变成稳定模式，还有很长的路要走。这种模式并不排除我们要我们还是那个目标：js终将一统天下。并不是真的一统所有语言，但是这表明了我们进步的决心。