简介： 中间件能够算是一种前端中罕用的”设计模式“了，有的时候甚至能够说，整个利用的架构都是应用中间件为根底搭建的。那么中间件有哪些利弊？什么才是中间件正确的应用姿态？本文将分享作者在理论应用中的一些想法，欢送同学们独特探讨。
一 先简略讲讲中间件
const compose = (middlewares) => {const reduce = (pre, cur) => {if (pre) {return (ctx) => cur(ctx, pre)
} else {return (ctx) => cur(ctx, () => ctx)
}
}
return [...middlewares].reverse().reduce(reduce, null);
}这是一段十分简洁的中间件代码，通过传入的相似这样的函数的列表：
const middlware = async (ctx, next) => {
/**
* do something to modify ctx
*/
if (/* let next run */true) {await next(ctx)
}
/**
* do something to modify ctx
*/
}失去一个新的函数，这个函数的执行，会让这些中间件一一解决并且每个中间件能够决定：
- 在下个中间件执行之前做些什么?
- 是否让下个中间件执行？
- 在下个中间件执行之后做些什么？
当初的中间件都是应用的洋葱模型，洋葱模型的大抵示意图是这样的：
依照这张图，中间件的执行程序是：
middleware1 -> middleware2 -> middleware3 -> middleware2 -> middleware1
解决程序是先从外到内，再从内到外，这就是中间件的洋葱模型。
在中间件的利用上，开发者能够将对立逻辑做成一个中间件，这样就能在其余中央复用这个逻辑。我感觉这其实是中间件这种模式的初心吧，好，那咱们先把这个初心放一放。
但实际上这个模式就是一个空壳，通过不同的中间件，就能够实现各种自定义的逻辑。比方：
const handler = compose([(ctx, next) => {if (ctx.question === 'hello') {
ctx.answer = 'hello';
return
}
if (next) [next(ctx)
]
}, (ctx, next) => {if (/age/.test(ctx.question)) {
ctx.answer = 'i am 5 yours old';
return
}
if (next) [next(ctx)
]
}])
const ctx = {question: 'hello'};
handler(ctx)
console.log(ctx.answer) // log hello
ctx.question = 'how about your age?'
handler(ctx)
console.log(ctx.answer) // log i am 5 yours old这样看起来咱们甚至能够去实现一个机器人，把中间件这么拿来用，相当于是把中间件作为一个 if 语句开展了，通过不同的中间件对 ctx 的劫持来拆散逻辑，看起来如同也不错？
得益于中间件的灵活性，每个中间件能够实现：1）实现独立的某个逻辑；2）管制后续的流程是否执行。
二 聊聊几个栗子
往年有参加做个小程序的 Bridge，先简略的介绍一下 Bridge 的性能。
- 从支付宝小程序的视角来抹平其余小程序的 JSAPI。
- Bridge 领有扩大能力，可能扩大 JSAPI。
看到“扩大能力”，纯熟的同学应该就晓得我能够切入正题了。
Bridge 当初的设计采纳插件的模式来注入一系列 API，每个插件都有插件名、API 名、中间件三个属性，注入 Bridge 后，Bridge 会将雷同 API 名的插件整合在一起，让这个 API 的实现指向这些插件带有的中间件的 compose，用这种形式来实现自定义 API。
这种形式其实看起来是十分美好的，因为所有的 API 都能够通过插件的模式注入到 Bridge 中，能够很灵便地扩大 API。
家喻户晓，有得必有失。这种模式其实有本人的毛病，具体的毛病咱们能够从“面向开发者”和“面向使用者”两方面来整顿，面向开发者指的是面向写插件（也就是写中间件）的开发者，面向使用者（用户）指的是最终应用 Bridge 的开发者。
1 面向开发者
API 的不确定性
多个中间件注册在同一个 API 下面，开发者本人的 API 是否可能运行失常有的时候是依赖上下文的，而零散的中间件被载入 Bridge，对于上下文的批改是未知的，因而会对 API 的执行带来很多不确定性。
从洋葱模型的图下面，咱们能够发现，内层往往会受内部的影响，当然在回流的时候，内部中间件也会受外部中间件的影响，在开发中间件的时候，咱们须要思考本人的依赖，在已知依赖没有问题的状况上来做开发，才会比拟稳当，然而以后 Bridge 这种散装载入 Plugin 的形式，让依赖关系没有方法稳固的形容。
API 的保护老本高
因为有多个插件注册到单个 API 上，保护某个 API 的状况下就会有比拟高的老本，就有点像是当初服务端排查问题的状况了，多个插件的状况下最差状况可能要一一开发者去做排查，最终能力分锅，尽管理论状况可能没有这么蹩脚，但还是要考虑一下最差的状况。
那么为什么服务端这种架构是正当的呢，因为服务端的微服务架构的确可能将多个业务逻辑拆分来解耦比较复杂的逻辑，然而 Bridge 这里只是想要实现某个 API 的实现，也很显著的发现理论在应用过程中，根本都采纳了单插件的注册形式。所以感觉用中间件来实现某个 API，有点过渡设计了，反而造成了保护老本的进步。
2 面向使用者
面向使用者其实要分为两种不同的场景：间接应用插件和通过 preset 来应用插件的集成。
3 间接应用插件
这种模式下，使用者要本人去援用插件，通过援用一系列插件来取得一个能够失常应用的 API，可是使用者往往冀望的是可能开箱即用，也就是说拿到这个 Bridge，看一下文档，就可能调用某个 API 了，现在须要 Bridge 的使用者通过本人注册一个 Plugin 这样的货色来取得一个可用的 API，显然是不合理的，不合理的中央次要体现在：
API 难了解
Bridge 使用者本来只须要了解一下 Bridge 的文档就可能轻松应用 API，当初须要了解 plugin 的运作机制以及如果有若干个插件的话，还要了解插件独自的运作和互相运作的实现。这些都很难让一个 Bridge 使用者承受，对于业务开发来讲，老本变高了。
问题排查难度回升
这点和之前提到的应用中间件这种形式会造成 API 的逻辑不连贯的状况是相似的，Bridge 在应用 API 的时候如果发现有问题，那么排查问题的时候就会因为有多个 Plugin 实现而减少难度，总的来说他还是须要简略的去了解每个插件根本实现和插件间的运作机制，对于业务开发来讲，老本较高。
4 通过 Preset 来应用插件的集成
因为上述 Bridge 使用者间接应用 Bridge 的问题，其实通过 preset 的封装能够解决一部分的痛点，而 Bridge 的 preset 的概念就是，通过编写一个 preset，这个 preset 去保护一个 API 和多个插件的关系，而后给到用户的是一个集成好的 Bridge，上述的两个问题都能够被解决。
这个模式看起来模式上就是之前的 Bridge 用户选了一个“最懂插件的人”来做他们的替身，做了之前的那个 User 的角色，让这个人来了解所有的 Plugin，并保护这些 API，这个 ” 最懂 ” 趋势极限，根本就等于开发 Plugin 的人了，那么饶了这么大一圈，做的这么灵便，最初保护插件的人是同一个人，也是这个人对外输入 API，那么这个货色真的有简单到要这么拆分么。就我集体来讲感觉还是间接简单明了的的实现一个 API 来的不便。那是中间件这种模式辣鸡吗？
5 抬走，咱们来看下一个
除了 Bridge，陈词滥调的还有相似 Fetch 这样的根底库，Fetch 是另一波同学做的了，然而我也是小撇了几眼代码，发现竟然也用了中间件来做，正好能够看看他们在设计 API 的时候应用中间件的合理性。先说说 Fetch 为啥走了这条路吧，看看诉求：
因为切实是有太多种不同的申请类型了，因而想实现在雷同的入参下，通过 adaptor 参数来辨别最终走怎么的申请逻辑。
因而 Fetch 在设计的时候，是这么应用中间件的：
fetch.use(commonMiddleware)
fetch.use('adaptor-xxx', [middleware]) // 比方 adaptor-json
fetch({...requestConfig, adaotpr: 'adaptor-xxx'})
Fetch 的中间件应用会绝对正当一点，通过利用中间件的个性，对外输入了雷同的出入参，再借助不同的中间件对申请的过程做流式解决。
但理论的应用过程中，也要很多同学反馈，有相似 Bridge 的应用问题。
6 调用过程排查艰难
和 Bridge 相似，业务在应用过程中如果遇到问题，排查难度会比拟高，首先业务开发同学的理解能力就很难了，因为要同时了解这套中间件 + 每个中间件的实现原理，而 adaptor 开发同学也比拟难排查问题，首先他须要晓得业务开发同学本地是如何应用这些适配器的，在晓得了之后再零散的一一插件去排查，相比于间接看某个类型的申请的实现，难度会较高。
三 引出观点
那么回头看看这两个 Bridge 和 Fetch 到底有必要应用中间件么，有没有更好的抉择。
先思考如果咱们不应用中间件来做，是不是当初的窘境都会不存在了，就比方：
fetch.rpc = () => {}
fetch.mtop = () => {}
fetch.json = () => {}这样实现不同类型的申请，每个申请的实现就会比拟直观的收敛在具体的函数中，随之带来的应该有如下的问题：
不同申请实现之间的共享逻辑会不那么直观，说白了就是将中间件前置后置那堆货色拿放到各自的实现中，哪怕是抽了公共函数而后再放到各自函数的实现中，这些共享逻辑都不直观，而中间件那种共享逻辑的解决，能够缩小肯定的保护老本。
那么会杠的同学就要开始问了：方才你说多个中间件会加大保护的老本，当初又说共享的逻辑做成中间件可能缩小保护老本，你这前后矛盾啊！
这波流程 Q 的不错。
那终于，要在这里抛一个观点：
中间件的这种模式，应该作为某个函数的装璜者模式来应用。
那么既然提到装璜者模式，咱们能够援用一本《维基百科》中的形容：
the decorator pattern is a design pattern) that allows behavior to be added to an individual object), dynamically, without affecting the behavior of other objects from the same class).
装璜者模式是一个能够在不影响其余雷同类的对象的状况下，动静批改某个对象行为的设计模式。
其实这段形容的体感不是很强，因为其实中间件自身曾经不是一个对象了，而维基百科中的设计模式针对面向对象的语言做了形容。
为了更有体感一点，附上一张《Head First 设计模式》中的一图：
能够发现几点：
- 装璜器和咱们须要扩大的 Class 都是实现了同一个接口。
- 装璜器是通过接管一个 Component 对象来运作的。
看到下面这两点就会发现其实装璜器模式和中间件的概念是大致相同的，只不过在 Javascript 中，通过一个 compose 的函数将几个毫不相干的函数串了起来，但最终的模式是和这个装璜者模式基本一致的。
另外《Head First 设计模式》中还有一张图：
这是他举的咖啡计算价格的例子，看到这张图不是特地眼生么，这和咱们最开始说的洋葱模型十分相近，这也再一次证实了其实咱们用的“中间件设计模式”其实就是“装璜者模式”。
那么聊了一下装璜者模式，其实是为了阐明我之前论述的“中间件的这种模式，应该作为某个函数的装璜者模式来应用”的观点，因为装璜器自身是为了解决继承带来的类的数量爆炸的问题的，而应用场景正如同它的名字个别，是有装璜者和被装璜者的辨别的，只管装璜者最终也能成为一个被装璜者，就如同例子中，计算咖啡的价格，装璜者能够依据加奶或者加奶泡等等来计算免费，然而其实着这个场景下，去做对加奶的装璜，就没什么意义了，也很难懂。反推我感觉中间件这种模式，亦是如此。
四 回应
通过如上的剖析，咱们得悉，咱们在使用中间件的时候，起码要有一个次要的函数，而其余的中间件，都是用于装璜应用。
就比方咱们在应用 Koa 做 Node 开发的时候，经常把业务逻辑放到某个中间件中，其余的都是一些拦挡或者预处理的中间件，在 egg 中次要的业务逻辑被做成了一个 controller，当然他最初必定还是一个中间件，这是一种 API 的丑化，十分迷信。
再比方咱们在应用 redux 的时候，中间件往往都是做一些简略的预处理或者 action 监听等等，当然也有另类的做法，比方 redux-saga 整个将逻辑接管掉的，这块另说，咱们这次先只聊惯例用法。
那回过头来，想比方 Bridge 这类如何做批改呢？
我感觉 Bridge 底层应用中间件来做 API 的解决流齐全没有问题，但造成当初这样的问题次要是他的 API，就如同 egg 做了 koa 的 API 的丑化个别，Bridge 也应该在 API 的设计上丑化一下，限度二次开发者的脑洞，API 不是越自在就越好，有句话说的好“你在号召多弱小的自在，就是在号召多弱小的奴役”。
那么咱们应该如何限度 API 呢？
按照之前论述过的说法“中间件的这种模式，应该作为某个函数的装璜者模式来应用”，因而，首先要有一个显式申明的主函数，这块咱们的 API 应该如下设计：
bridge.API('APINAME', handler)
// 或者更加间接的
bridge.APINAME = handler这样一来，开发者在查找 API 实现的时候，就可能比拟明确的找到这块的实现，而最底层 Bridge 还是会吧这个 handler 丢到一个中间件中去做解决，这样就能做到对这个 handler 的装璜。
在这个的根底上，再设计一个可能反对中间件的 API：
bridge.use(middleware) // 对所有的 API 失效
bridge.use('APINAME', middleware) // 对某个 API 失效 再回顾一下之前列进去的问题：
API 的不确定性
API 的实现都会放到 handler 中，且仅有这个 handler 会做次要逻辑解决，开发者明确的晓得这里写的就是主逻辑。
API 的保护老本高
API 的次要实现就在 handler 中，只须要保护 handler 就行，有非凡的问题，再去看应用的中间件。
API 难了解
用户明确的晓得只须要了解 handler 的实现就行，中间件的逻辑大部分是用于公共应用，只有对立了解就行。
到这里，会杠的同学还是会问，其实你这如同问题也没有齐全解决，只有开发者想搞你，还是会呈现之前的问题，比方就会有骚的人把逻辑写到中间件外面，不写到 handler 外面，你这种设计不还是一样。
这说的一点都没错，因为设计这个 API 不免的就是要凋谢给开发者这样的能力，也就是：1）自定义 API；2）对若干 API 做一些个性化的对立逻辑。API 的设计者可能做到的就是在 API 上传播给开发者一种标准，就比方 bridge.plugin() 这种开放性的 API，就没有 bridge.API() 这种好，因为后者很明确的让开发者申明一个 API，而前者不明确，前者让开发者感觉中间件就是 API 的实现。
五 结语
本篇咱们从中间件聊到中间件的应用实例，再聊到了装璜器模式，最初聊到了应用中间件的 API 的设计。在日常 API 设计中，我不仅会面对底层设计的选型，还会面对对外开放 API 的设计，两者都同样重要。不过本篇仅代表个人观点，欢送在评论区指教、探讨。