先后端分离

1、什么是先后端分离?

最开始租内讨论的过程当中咱们发现。每一个人对先后端分离的理解不同。为了保证能在同一个频道讨论，先就什么是"先后端分离"达成一致

你们一致认同的先后端分离的例子就是SPA,全部用到的展示的数据都是后端异步接口的方式提供的，前端只管展示。

从某种意义来讲。SPA确实作到了先后端分离，但这种方式存在两个问题：

   WEB服务中。SPA类占用比例不多。很好状况下还有同步/异步混合的模式，SPA不能做为一种通用的解决方案。

   现阶段的SPA开发模式，接口一般是按照展示逻辑来提供的。有时候为了提升效率。后端会帮助咱们处理一些展示的逻辑。这就意味着后端仍是涉及到了View层的工做。不是真正的     后端分离。

SPA式的先后端分离，是从物理层作区分（认为只要是客户端的就是前端,服务器端的就是后端），这种状况已经没法知足咱们先后端分离的需求了。咱们认为从职责上划分才能知足目前咱们使用的场景:

前端:负责View和Controller层

后端:只负责Model层，业务处理/数据等

 

2、为何要先后端分离？

关于这个问题。玉伯的文章Web研发模式演变中解释得很是全面，咱们再大概理一下：

2.1 现有开发模式的适用场景

玉伯提到的几种开发模式，各有各的适用场景，没有哪种彻底取代另一种。

   好比后端为主的MVC,作一些同步展示效率很高，可是遇到了同步和异步结合的页面，与后端结合起来很麻烦。

Ajax为主SPA型开发模式，比较适合开发APP类型的场景。但适合作App，由于SEO等问题很差解决。对于不少系统，这种开发方式也太重。

2.2 先后端职责不清

在业务逻辑复杂的系统里。咱们最怕维护前端和后端混杂在一块儿的代码，由于没有约束，M-V-C每一层均可能出现别的层的代码，日积月累，彻底没有可维护性可言。虽然先后端分离没有办法解决这种问题。可是能够大大缓解。由于从物理层面上保证你了不可能这么作。

2.3 开发效率问题

淘宝的web基本上都是基于MVC框架的webx，架构决定了前端只能依赖后端。因此咱们的开发模式依然是，前端写好的静态demo,后端翻译成的VM模板，这种模式的问题早就不说了。被吐槽了好久，直接基于后端环境开发也很痛苦。配置安装使用很麻烦。为了解决问题。咱们发明了各类工具。好比VMarket，可是前端还要写VM.并且依赖后端数据，效率依然不高，另外，后端也无法摆脱对展示的强关注，从而专心于业务逻辑层的开发。

2.4 对前端发挥的局限

性能优化若是只在前端作空间很是有限，因而咱们常常须要后端合做才能碰撞成火花，可是因为后端框架的限制咱们很难使用Coment、Bigpipe等技术方案来优化性能。

为了解决以上的一些问题，咱们进行了不少尝试，开发了各类工具，但始终没有太多转机，主要是由于咱们只能在后端给咱们划分的那一小块空间去发挥。只有真正作到先后端分离，咱们才能完全解决以上问题。

3、怎么作先后端分离？

怎么作先后端分离，其实第一节中已经有了答案：

前端：负责VIew和Controller层

后端:负责Model层，业务处理/数据等

试想一下，若是前端掌握了Controller,咱们能够作url design,咱们能够根据场景决定在服务端同步渲染，仍是根据View层数据输出json 数据，咱们还能够根据表现层需求很容易的作Bigpipe，Comet,Socket等等,彻底是需求决定使用方式。

3.1 基于NodeJS“全栈”式开发

若是想实现上图的分层。就必然须要一种web服务帮助咱们实现之前后端作的事情。因而就有了标题提到的“基于NodeJS的全栈式开发”

 

 这张图看起来简单并且很好理解，但没尝试过，会有不少疑问。

 SPA模式中，后端已供了所需的数据接口，view前端已经能够控制，为何要多加NodeJS这一层？

 多加一层，性能怎么样？

 多加一层，前端的工做量是否是增长了？

 多加一层就多一层风险，怎么破？

 NodeJS什么都能作，为何还要JAVA？

这些问题要说清楚不容易，下面说下个人认识过程。

3.2 为何要增长一层NodeJS？

现阶段咱们主要之后端MVC的模式进行开发，这种模式严重阻碍了前端开发效率，也让后端不能专一于业务开发。

解决方案是让前端能控制Controller层，可是若是在现有的技术体系下很难作到。由于不可能让全部前端妹子学java,安装后端的开发环境，写VM,NodeJS就能很好的解决这个问题，

咱们无需学习一门新的语言。就能作到之前开发帮助咱们作的事情。一切都显的那么天然。‘

3.3 性能问题

分层就涉及到了每层之间的通讯。确定会有必定的性能损耗。可是合理的分层能让职责清晰，也方便协做。会大大提升开发效率。分层带来的损失，必定能在其余方面的收益弥补回来。另外，一旦决定分层，咱们能够经过优化通信方式，通信协议，尽量把损耗降到最低。

 

举个例子：

淘宝宝贝详情页静态化以后，仍是有很多须要实时获取的信息，好比物流、促销等等，由于这些信息在不一样业务系统中，因此须要前端发送5，6个异步请求来回填这些内容。
有了NodeJS以后，前端能够在NodeJS中去代理这5个异步请求，还能很容易的作Bigpipe,这块的优化能让整个渲染效率提高不少。
可能在PC上你以为发5,6个异步请求也没什么，可是在无线端，在客户手机上创建一个HTTP请求开销很大，有了这个优化，性能一下提高好几倍。

淘宝详情基于NodeJS的优化咱们正在进行中，上线以后我会分享一下优化的过程。

3.4 前端的工做量是否增长了？

相对于只切页面/作demo，确定是增长了一点，可是当前模式下有联调、沟通环节，这个过程很是花时间，也容易出bug，还很难维护。
因此，虽然工做量会增长一点，可是整体开发效率会提高不少。

另外，测试成本能够节省不少，之前开发的接口都针对表现层。很难写测试例。若是作了先后端分离，甚至测试均可以分开。

’