浅谈先后端分离与实践 之 nodejs 中间层服务（二）

1、背景

书接上文，浅谈先后端分离与实践(一) 咱们用mock服务器搭建起来了本身的前端数据模拟服务，先后端开发过程当中只需定义好接口规范，即可以相互进行各自的开发任务。联调的时候，按照以前定义的开发规范进行数据联调即可以了。先后端的职能更加清晰：

后端	前端
提供数据	接收数据，返回数据
处理业务逻辑	处理渲染逻辑
Server-side MVC架构	Client-side MV* 架构
代码跑在服务器上	代码跑在浏览器上

这里分离干净了，分工也很明确了，看似一切都那么美好，but...咱们也很容易发现问题的所在：

1. Client-side Model 是 Server-side Model 的加工
2. Client-side View 跟 Server-side是 不一样层次的东西
3. Client-side的Controller 跟 Sever-side的Controller 各搞各的
4. Client-side的Route 可是 Server-side 可能没有

也就是说服务端和客户端各层职责重叠，你们各搞各的，很难统一具体要作的事情。而且可能会伴随着一些性能上的问题。最具体的表现就是咱们经常使用的SPA应用：

1. 渲染，取值都在客户端进行，有性能的问题
2. 须要等待资源到齐才能进行，会有短暂白屏与闪动
3. 在移动设备低速网路的体验奇差无比
4. 渲染都在客户端，模版没法重用，SEO实现 麻烦

紧接着，咱们代码量愈来愈大，咱们须要校验的表单也会愈来愈多，有时候，前端提交须要校验一次表单。
服务端任须要进行校验来达到数据的可靠性；前端的路由可能在服务端并不存在....等等这一系列重用性的问题。因此咱们以前的重构可能须要更深层次的思考。

2、开始重构

在开始重构以前，咱们须要对先后端界线作一个划分，也就是说什么是属于前端的范畴，什么是属于后端的范畴，最传统的先后端划分多是这样的：

image.png

那么问题来了：咱们先后端划分的接线，是依照工做职责来划分的先后端；仍是依照硬体环境划分的先后端？自从了nodejs以后，咱们能够从工做职能上从新定义先后端的范畴：

image.png

能够看到，这里的前端比以前多了个nodejs，也就是在先后端之间咱们构建了一个 nodejs 服务做为中间层！
为何咱们选择的中间层是nodejs呢？由于咱们把中间层归在了前端的范畴，那么对前端小伙伴来讲，nodejs毕竟仍是个js，那么从语法角度来讲，上收起来应该没有什么问题。其次开发转移成本也想对较低，没必要来回切换语言的逻辑和语法：

1. 前端熟悉的语言，学习成本低
2. 都是JS，能够先后端复用
3. 体质适合：事件驱动、非阻塞I/O
4. 适合IO密集型业务
5. 执行速度也不差

好了，提早说了这么多东西，那么这个中间层能给咱们带来什么了？要知道引入nodejs的开发成本也是很大的，首先就是多了一层服务，多的不说，单凭传输时间，就多了一层的传输时间啊！下面咱们来研究一下什么应用场景下的nodejs能给咱们带来利大于弊的东西。

3、开始中间层之旅

引入nodejs以后，咱们来从新划分一下先后端的职能：

image.png

这个就是中间层nodejs的主要思路，下面咱们来看一下常见的业务场景：

1. 接口数据可靠性修复

有的时候服务端返回给咱们的数据可能并非前端想要的结构，全部用到的展示数据都是后端经过异步接口(AJAX/JSONP)的方式提供的，前端只管展示。可是后端常常提供后端的数据逻辑，在前端还须要去处理这些数据逻辑。好比我再开发一个功能的时候，有时候会碰到这样的问题：

image.png

image.png

服务端返回的某个字段为 null 或者服务端返回的数据结构太深，前端须要不断写这样的代码去判断数据结构是否真的返回了正确的东西，而不是个null 或者undefined：

if (params.items && params.items.type && ...) {
   // todo
}复制代码

对于这种状况，咱们前端其实不该该去重复校验数据的格式，这也本不该该是浏览器端js须要作的事情。咱们能够在中间层作接口转发，在转发的过程当中作数据处理。而不用担忧数据返回的问题：

router.get('/buyer/product/detail', (req, res, next) => {
  httpRequest.get('/buyer/product/detail', (data) => {
    // todo 处理数据
    res.send(data);
  })
})复制代码

2. 页面性能优化 和 SEO

有点时候咱们作单页面应用，常常会碰到首屏加载性能问题，这个时候若是咱们接了中间层nodejs的话，那么咱们能够把首屏渲染的任务交给nodejs去作，次屏的渲染依然走以前的浏览器渲染。（前端换页，浏览器端渲染，直接输入网址，服务器渲染）服务端渲染对页面进行拼接直出html字符串，能够大幅提升首屏渲染的时间，减小用户的等待时间。这种形式应用最广的好比 Vue 的服务端渲染，里面也有相关的介绍。
其次对于单页面的SEO优化也是很好地处理方式，因为目前的ajax并不被搜索百度等搜索引擎支持，因此若是想要获得爬虫的支持，那么服务端渲染也是一种解决方法。（PS：若是以为服务端渲染太麻烦，我这里还有一篇介绍处理SEO的另外一种思路处理 Vue 单页面 Meta SEO的另外一种思路能够参考）

3. 淘宝常见的需求解决方案

需求：在淘宝，单日四亿PV，页面数据来自各个不一样接口，为了避免影响体验，先产生页面框架后，在发起多个异步请求取数据更新页面，这些多出来的请求带来的影响不小，尤为在无线端。

解决方案：在NodeJS端使用 Bigpiper 技术，合并请求，下降负担，分批输出，不影响体验。同时能够拆分大接口为独立小接口，并发请求。串行 => 并行，大幅缩短请求时间。

4. 更多可能

image.png

结语

这里只是提供问题的一种解决思路，仍是那句话：一切看应用场景。若是你对本文内容有别的意见也欢迎一块儿交流探讨。

关于

做者：monkeyWang

本人主页：monkeyWang

本文部分图片断落参考文章： 淘宝先后端分离实践

微信公众号：会不按期推送前端技术文章，欢迎关注

image.png