一、什么是前后端分离？
前后端分离的典型例子就是 SPA(Single Page Application)，所有用到的展现数据都是后端通过异步接口（AJAX/JSONP）的方式提供的，前端只管展现。
从某种意义上来说，SPA 确实做到了前后端分离，但这种方式存在两个问题：
WEB 服务中，SPA 类占的比例很少。很多场景下还有同步/同步+异步混合的模式，SPA 不能作为一种通用的解决方案。 现阶段的 SPA 开发模式，接口通常是按照展现逻辑来提供的，有时候为了提高效率，后端会帮我们处理一些展现逻辑，这就意味着后端还是涉足了 View 层的工作，不是真正的前后端分离。
SPA 式的前后端分离，是从物理层做区分（认为只要是客户端的就是前端，服务器端的就是后端），这种分法已经无法满足我们前后端分离的需求，我们认为从职责上划分才能满足目前我们的使用场景：
前端：负责 View 和 Controller 层。 后端：只负责 Model 层，业务处理/数据等。
二、为什么要前后端分离？
- 前端依赖服务端开发环境
- 在服务端View层高度耦合
- 沟通成本高
- 职责不清晰
- 维护变成灾难
三、怎么做前后端分离？是大前端还是传统前端？
传统前后端职责划分：
| 后端 | 前端 | |
|---|---|---|
| 提供数据 | 接收数据，返回数据 | |
| 处理业务逻辑 | 处理渲染逻辑 | |
| Server-side MVC架构 | Client-side MV* 架构 | |
| 代码跑在服务器上 | 代码跑在浏览器上 |
各层职责重叠，并且各玩各的
- Client-side Model 是 Server-side Model 的加工
- Client-side View 跟 Server-side是 不同层次的东西
- Client-side的Controller 跟 Sever-side的Controller 各搞各的
- Client-side的Route 但是 Server-side 可能没有
性能问题
- 渲染，取值都在客户端进行，有性能的问题
- 需要等待资源到齐才能进行，会有短暂白屏与闪动
- 在移动设备低速网路的体验奇差无比
跨终端问题
- 业务太靠前，导致不同端重复实现
- 逻辑太靠前，造成维护上的不易
SEO问题
- 渲染都在客户端，模版无法重用，SEO实现 麻烦 传统认知的前后端
传统前后端的思考？SEO、首屏渲染【白屏】、加载速度.....?
因為有了NODEJS
我们有机会从工作职责上
重新定义前后端的分层
重新定义的前后端:
- 前端：负责 View 和 Controller 层。
- 后端：负责 Model 层，业务处理/数据等。
试想一下，如果前端掌握了 Controller，我们可以做 URL design，我们可以根据场景决定在服务端同步渲染，还是根据 View 层数据输出 JSON 数据，完全是需求决定使用方式。
新的前后端职责划分
3.1 基于NodeJS“全栈”式开发
如果想实现上图的分层，就必然需要一种web服务帮我们实现以前后端做的事情，于是就有了标题提到的“基于NodeJS的全栈式开发”。
这张图看起来简单而且很好理解，但没尝试过，会有很多疑问。
SPA 模式中，后端已供了所需的数据接口，View 前端已经可以控制，为什么要多加 Node.js 这一层？ 多加一层，性能怎么样？ 多加一层，前端的工作量是不是增加了？ 多加一层就多一层风险，怎么破？ Node.js 什么都能做，为什么还要 后端语言？
这些问题要说清楚不容易，下面说下我的认识过程。
3.2 为什么要增加一层 Node.js？
现阶段我们主要以后端 MVC 的模式进行开发，这种模式严重阻碍了前端开发效率，也让后端不能专注于业务开发。 解决方案是让前端能控制 Controller 层，但是如果在现有技术体系下很难做到，因为不可能让所有前端都学 后端语言，安装后端的开发环境，写 VM。 Node.js 就能很好的解决这个问题，我们无需学习一门新的语言，就能做到以前开发帮我们做的事情，一切都显得那么自然。
3.3 性能问题
分层就涉及每层之间的通讯，肯定会有一定的性能损耗。但是合理的分层能让职责清晰、也方便协作，会大大提高开发效率。分层带来的损失，一定能在其他方面的收益弥补回来。
另外，一旦决定分层，我们可以通过优化通讯方式、通讯协议，尽可能把损耗降到最低。
举个例子：
比如物流、促销等等，因为这些信息在不同业务系统中，所以需要前端发送 5，6 个异步请求来回填这些内容。
有了 Node.js 之后，前端可以在 Node.js 中去代理这 5 个异步请求，还能很容易的做 Bigpipe，这块的优化能让整个渲染效率提升很多。
可能在 PC 上你觉得发 5、6 个异步请求也没什么，但是在无线端，在客户手机上建立一个 HTTP 请求开销很大，有了这个优化，性能一下提升好几倍。
3.4 前端的工作量是否增加了？
相对于只切页面/做 demo，肯定是增加了，对前端的能力也要求提高不小，但是当前模式下有联调、沟通环节，这个过程非常花时间，也容易出 bug，还很难维护。所以，虽然工作量会增加，但是总体开发效率会提升很多。
3.5 增加 Node.js 层带来的风险怎么控制？
随着 Node.js 大规模使用，系统/运维/安全部门的同学也一定会加入到基础建设中，他们会帮助我们去完善各个环节可能出现的问题，保障系的稳定性。
3.6 Node.js 什么都能做，为什么还要 后端语言？
我们的初衷是做前后端分离，如果考虑这个问题就有点违背我们的初衷了。即使用 Node.js 替代后端语言，我们也没办法保证不出现今天遇到的种种问题，比如职责不清。
我们的目的是分层开发，专业的人，专注做专业的事。基于后端语言【 Java/go】 的基础架构已经非常强大而且稳定，而且更适合做现在架构的事情
