1.在前后端开发过程中，只需定义好接口规范，即可进行各自的开发任务。联调时，按照之前定义的开发规范进行数据联调即可。前端和后端的功能比较明确：后端和前端提供数据接收数据，返回数据处理业务逻辑处理渲染逻辑。服务器端MVC架构客户端MV*架构代码在服务器上运行，代码在浏览器上运行。到这里，分离的干干净净，分工也很明确，似乎一切都是那么的美好，但是……我们很容易发现问题所在：Client-sideModel是Server-sideModelClient的处理-sideView和Server-side是不同层次的东西Client-sideController和Sever-sideController各自有自己的Client-sideRoutes，但是Server-side可能没有。也就是说，每一层服务端和客户端的职责都是重叠的。每个人都做自己的事情，很难统一起来。事物。并且它可能伴随着一些性能问题。最具体的表现就是我们常用的SPA应用：渲染和取值都是在客户端进行的。如果存在性能问题，则需要等待资源可用后再继续。在低速网络的移动设备上会有短暂的白屏和闪烁体验。渲染全部在客户端，模板无法复用，SEO实现麻烦。然后，我们的代码量越来越大，需要验证的表单也越来越多。有时候，前端提交需要验证一次表单。服务器端需要进行验证，以实现数据的可靠性；服务器端可能不存在前端路由……等等，一系列的复用性问题。所以我们之前的重构可能需要更深入的思考。2.开始重构在开始重构之前，我们需要先划分一下前后端的界限，也就是说，什么属于前端类，什么属于后端类。最传统的前后端划分可能是这样的：那么问题来了：我们前后端划分的布线是按照工作职责划分的；还是根据硬件环境划分前后端？既然有了nodejs，我们就可以在工作职能上重新定义前后端的范围：可以看到，这里的前端比之前多了nodejs，也就是我们之间建立了一个nodejs服务前端和后端作为中间层！为什么我们选择nodejs作为中间层？因为我们把中间层放在了前端的范畴里，那么对于前端小伙伴来说，nodejs毕竟还是一个js，所以从语法上来说，关闭起来应该是没有问题的。其次，开发迁移的成本也比较低，不需要来回切换语言的逻辑和语法：前端熟悉的语言，学习成本低的是JS，前后端分离end可以重复使用。大型业务的执行速度还不错，前面说了那么多，那么这个中间层能给我们带来什么呢？要知道引入nodejs的开发成本也是非常高的。首先，有一个额外的服务层。下面我们就来研究下nodejs在哪些应用场景下能够给我们带来的利多于弊。3.开始中间层的旅程介绍完nodejs，我们来重新定义一下前后端功能：这就是中间层nodejs的主要思想。我们来看看常见的业务场景：1.接口数据可靠性修复，有时service客户端返回给我们的数据可能不是前端想要的结构。所有用到的显示数据都是后端通过异步接口（AJAX/JSONP）提供的，前端只需要显示即可。但是，后端往往会提供后端数据逻辑，需要在前端进行处理。比如我在开发另外一个功能的时候，有时会遇到这样的问题：服务器返回的某个字段为null或者服务器返回的数据结构太深，前端需要不断的写这样的代码来判断是否数据结构是否真实返回正确的东西而不是null或undefined：if(params.items&¶ms.items.type&&...){//todo}在这种情况下，我们的前端不应该重复验证数据格式，这应该不是浏览器端js需要做的事情。我们可以在中间层做接口转发，在转发过程中做数据处理。而不是担心数据返回：router.get('/buyer/product/detail',(req,res,next)=>{httpRequest.get('/buyer/product/detail',(data)=>{//todoprocessingdatares.send(data);})})2.页面性能优化和SEO有时候我们在做单页应用的时候，经常会遇到首屏加载性能的问题。这时候，如果我们把中间层连接到nodejs的话，那么我们就可以把渲染第一屏的任务交给nodejs了，而第二屏的渲染还是使用之前的浏览器渲染。（前端换页，浏览器端渲染，直接输入URL，服务端渲染）服务端渲染拼接页面，直接输出html字符串，可以大大增加首屏渲染时间，减少用户等待时间.这种形式应用最为广泛，比如Vue的服务端渲染，里面也有相关介绍。其次，它也是处理单页SEO优化的好方法。由于目前百度等搜索引擎不支持ajax，如果想获得爬虫的支持，服务端渲染也是一种解决方案。（PS：如果你觉得服务端渲染太麻烦，我这里还有一篇文章介绍了另一种处理SEO的方法，你可以参考另一种处理Vue单页MetaSEO的方法。）三、常见需求淘宝解决方案需求：在淘宝，单日4亿PV，页面数据来自不同接口，为了不影响体验，先生成页面框架，然后发起多个异步请求去抓取数据更新页面，这些额外请求的影响不小，尤其是在无线端。解决方案：在NodeJS端使用Bigpiper技术合并请求，减轻负担，批量输出，不影响体验。同时可以将大接口拆分成独立的小接口，用于并发请求。Serial=>Parallel，大大缩短了请求时间。4.更多可能的结论这里只是解决问题，还是那句话：一切取决于应用场景。如果您对本文内容有其他看法，欢迎大家一起讨论。作者简介：monkeyWang我的主页：monkeyWang部分图片段落参考文章：淘宝前端分离实践微信公众号：我会不定期推送前端技术文章，欢迎关注
