Koa中间件（middleware）实现探索

发表于 |

说起Node，最常用的估计就是express和koa，两者都用到了中间件（middleware）这一概念，主要用于对请求的统一处理。

koa的请求处理是典型的洋葱模型,下面是官方的配图，而这一模型的组成部分就是middleware

接下来我们来看一下koa的源码，了解中间件的实现方式。

首先我们找到了koa的仓库Koa,好吧,我知道你们都会这一步。

在package.json中找到模块的入口文件application.js,稍微浏览一下(不得不说，tj大神的代码写的真的漂亮)就可以找到Koa处理请求的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
app.callback = function(){
  if (this.experimental) {
    console.error('Experimental ES7 Async Function support is deprecated. Please look into Koa v2 as the middleware signature has changed.')
  }
  var fn = this.experimental
    ? compose_es7(this.middleware)
    : co.wrap(compose(this.middleware));
  var self = this;
  if (!this.listeners('error').length) this.on('error', this.onerror);

  return function handleRequest(req, res){
    res.statusCode = 404;
    var ctx = self.createContext(req, res);
    onFinished(res, ctx.onerror);
    fn.call(ctx).then(function handleResponse() {
      respond.call(ctx);
    }).catch(ctx.onerror);
  }
};

看完这个函数，我们了解到真正处理请求内容的函数是fn,而这个函数的定义就是下面这段函数

1
2
3
var fn = this.experimental
    ? compose_es7(this.middleware)
    : co.wrap(compose(this.middleware));

好吧，准确来说就是

1
co.wrap(compose(this.middleware));

其实我们只需要知道这段函数做了什么，就知道中间件是如何运行的了。

同时，我们在appliction.js文件找到了app.use函数

1
2
3
4
5
6
app.use = function(fn){
  ...
  
  this.middleware.push(fn);
  return this;
};

从这段代码，我们可以知道this.middleware就是一个generator函数的数组。

接下来我们需要知道compose函数做了什么，我们找到compose函数，其实compose很短

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function compose(middleware){
  return function *(next){
    if (!next) next = noop();

    var i = middleware.length;

    while (i--) {
      next = middleware[i].call(this, next);
    }

    return yield *next;
  }
}

function *noop(){}

这里compose函数返回了一个Generator，所以上面的代码可以变成下面的样子（当然还有middleware的变量再闭包中）

1
2
3
4
5
6
7
8
9
10
11
co.wrap(function *(next){
    if (!next) next = noop();

    var i = middleware.length;

    while (i--) {
      next = middleware[i].call(this, next);
    }

    return yield *next;
  })

接下来我们看一下co.wrap

1
2
3
4
5
6
7
co.wrap = function (fn) {
  createPromise.__generatorFunction__ = fn;
  return createPromise;
  function createPromise() {
    return co.call(this, fn.apply(this, arguments));
  }
};

所以代码可以变为下面的样子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function createPromise() {
    var fn = function *(next){
        if (!next) next = noop();
    
        var i = middleware.length;
    
        while (i--) {
          next = middleware[i].call(this, next);
        }
    
        return yield *next;
      } 
    return co.call(this, fn.apply(this, arguments));
  }

接下来，我们仔细看一下这段代码

1
2
3
4
5
6
7
if (!next) next = noop();
    
var i = middleware.length;
    
while (i--) {
    next = middleware[i].call(this, next);
}

这段代码遍历了我们的中间件数组，最终生成了一个类似下面的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
next = (function*(){
    // middleware1
    ...
    
    yield (function*(){
        // middleware2
        ...
        
        yield (function*(){
            // middleware3
            ...
            
            yield (function *(){
                // noop
                // NO next yield !
            })()
            
            // ...middleware3
        })
        
        // ...middleware2
    })
    // ...middleware1
})()

其实看到这里就已经可以看到洋葱模型的样子了。

而最后就是这个next的运行，其实这个next就是一个Generator函数生成的迭代器（iterator）对象，然后由co来运行，类似下面

1
2
3
4
5
co(function*(){
    ...

    yield *next
})

co可以对generator的进行自执行。到这基本就完成可中间件的实现。

眼尖的读者可以看到这里最后用到了yield *而非yield,可以有关于co的执行，其实就是为了减少co的一次运行，其实每次都应该用yield next,可能是tj大神怕大家忘记加了，就索性在demo里面就建议大家直接yield next就好了。具体的可以看我对于co源码实现的分析，我这里就提一下`yield 可以自动执行后面的表达式的迭代器属性，而yield只会直接返回后面的表达式，所以一个yield *可以使co直接拿到后面迭代器中的每一步，而yield只可以拿到迭代器，然后递归调用co`来执行迭代器。

最后欢迎大家吐槽，谢谢。