Express中间件

Express和Koa是目前最主流的基于node的web开发框架，他们的开发者是同一班人马。貌似现在Koa更加流行，但是仍然有大量的项目在使用Express，所以这里我们说说Express中间件的原理。以下所说中间件皆为Express中间件。

中间件的功能和分类

中间件的本质就是一个函数，在收到请求和返回相应的过程中做一些我们想做的事情。Express文档中对它的作用是这么描述的：

执行任何代码。 修改请求和响应对象。 终结请求-响应循环。 调用堆栈中的下一个中间件。

Express文档中把他们分为了五类，但是他们的原理相同，只是用法不同：

应用级中间件 路由级中间件 错误处理中间件 内置中间件 第三方中间件

引发的思考

需求本身就复杂，还经常变更时，后端实现和维护接口就越来越力不从心了，所以就有了微服务（Micro Services），把原来的很多复杂接口拆分成多个细粒度的接口，让前端去分别调用再自己组合起来，这又导致了前端的工作量大幅增加，而且有时就算把各种接口组合起来仍然不能解决问题，尤其是需要同时渲染UI的需求时，必须用一个接口一次性返回数据。
例如 获取朋友圈，后端给了以下几个接口：
moments/1, 
users/1, 
moments/priase,
comments?momentId=1 
分别调用并分段渲染会导致UI的评论区高度不断跳动，因为预设的高度和拿到数据后渲染出来的高度不一致；
如果是依次调用再同时渲染，不但多了几次HTTP连接导致时间变长，还会导致moment里评论数commentCount=1，但下面的评论comments却不止1条 这种因为几次调用接口期间数据已更改导致的不一致问题）。
前端为了解决这个问题就出现了中间件，将后端的接口聚合起来然后做数据整合，甚至结构变换。
Node.js用的是和前端一样的语言JavaScript，于是就顺手做了。
还有 
版本迭代导致的兼容问题，后端还需要开发和维护大量重复功能的接口；
操作数据库时delete忘加where直接删光全部数据；
以及 繁琐恼人的开发流程：
后端写接口>后端写文档>前端/客户端查文档>(前端/客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端调用接口>(前端/客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端/客户端解析返回结果>(前端/客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)
这些都导致了 前后端各种扯皮、前后端开发间歇性忙碌与闲置、接口bug不断漏洞频出、开发周期很长版本迭代慢