一 先簡單講講中間件
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的實作都會放到handler中，且僅有這個handler會做主要邏輯處理，開發者明确的知道這裡寫的就是主邏輯。
API的主要實作就在handler中，隻需要維護handler就行，有特殊的問題，再去看使用的中間件。
使用者明确的知道隻需要了解handler的實作就行，中間件的邏輯大部分是用于公共使用，隻要統一了解就行。
到這裡，會杠的同學還是會問，其實你這好像問題也沒有完全解決，隻要開發者想搞你，還是會出現之前的問題，比如就會有騷的人把邏輯寫到中間件裡面，不寫到handler裡面，你這種設計不還是一樣。
這說的一點都沒錯，因為設計這個API難免的就是要開放給開發者這樣的能力，也就是：1）自定義API；2）對若幹API做一些個性化的統一邏輯。API的設計者能夠做到的就是在API上傳達給開發者一種規範，就比如 bridge.plugin() 這種開放性的API，就沒有 bridge.API() 這種好，因為後者很明确的讓開發者申明一個API，而前者不明确，前者讓開發者覺得中間件就是API的實作。
五 結語
本篇我們從中間件聊到中間件的使用執行個體，再聊到了裝飾器模式，最後聊到了使用中間件的API的設計。在日常API設計中，我不僅會面對底層設計的選型，還會面對對外開放API的設計，兩者都同樣重要。不過本篇僅代表個人觀點，歡迎在評論區指教、讨論。