详解express与koa中间件模式对比

发布时间：2020-12-16 08:16:53 所属栏目：百科来源：网络整理

导读：起因最近在学习koa的使用，由于koa是相当基础的web框架，所以一个完整的web应用所需要的东西大都以中间件的形式引入，比如koa-router,koa-view等。在koa的文档里有提到：koa的中间件模式与express的是不一样的，koa是洋葱型，express是直线型，至于为什么

起因

最近在学习koa的使用，由于koa是相当基础的web框架，所以一个完整的web应用所需要的东西大都以中间件的形式引入，比如koa-router,koa-view等。在koa的文档里有提到：koa的中间件模式与express的是不一样的，koa是洋葱型，express是直线型，至于为什么这样，网上很多文章并没有具体分析。或者简单的说是async/await的特性之类。先不说这种说法的对错，对于我来说这种说法还是太模糊了。所以我决定通过源码来分析二者中间件实现的原理以及用法的异同。

为了简单起见这里的express用connect代替（实现原理是一致的）

用法

二者都以官网（github）文档为准

connect

下面是官网的用法：

var app = connect();

// gzip/deflate outgoing responses
var compression = require('compression');
app.use(compression());

// store session state in browser cookie
var cookieSession = require('cookie-session');
app.use(cookieSession({
keys: ['secret1','secret2']
}));

// parse urlencoded request bodies into req.body
var bodyParser = require('body-parser');
app.use(bodyParser.urlencoded({extended: false}));

// respond to all requests
app.use(function(req,res){
res.end('Hello from Connect!n');
});

//create node.js http server and listen on port
http.createServer(app).listen(3000);

根据文档我们可以看到，connect是提供简单的路由功能的：

connect的中间件是线性的，next过后继续寻找下一个中间件，这种模式直觉上也很好理解，中间件就是一系列数组，通过路由匹配来寻找相应路由的处理方法也就是中间件。事实上connect也是这么实现的。

app.use 就是往中间件数组中塞入新的中间件。中间件的执行则依靠私有方法 app.handle 进行处理，express也是相同的道理。

koa

相对connect，koa的中间件模式就不那么直观了，借用网上的图表示：

也就是koa处理完中间件后还会回来走一趟，这就给了我们更加大的操作空间，来看看koa的官网实例：

// x-response-time

app.use(async (ctx,next) => {
const start = Date.now();
await next();
const ms = Date.now() - start;
ctx.set('X-Response-Time',${ms}ms);
});

// logger

app.use(async (ctx,next) => {
const start = Date.now();
await next();
const ms = Date.now() - start;
console.log(${ctx.method} ${ctx.url} - ${ms});
});

// response

app.use(async ctx => {
ctx.body = 'Hello World';
});

app.listen(3000);

很明显，当koa处理中间件遇到await next()的时候会暂停当前中间件进而处理下一个中间件，最后再回过头来继续处理剩下的任务，虽然说起来很复杂，但是直觉上我们会有一种隐隐熟悉的感觉：不就是回调函数吗。这里暂且不说具体实现方法，但是确实就是回调函数。跟async/await的特性并无任何关系。

源码简析

connect与koa中间件模式区别的核心就在于next的实现，让我们简单看下二者next的实现。

connect

connect的源码相当少加上注释也就200来行，看起来也很清楚，connect中间件处理在于proto.handle这个私有方法，同样next也是在这里实现的

// 递增
var layer = stack[index++];

// 交由其他部分处理
if (!layer) {
defer(done,err);
return;
}

// route data
var path = parseUrl(req).pathname || '/';
var route = layer.route;

// 递归
// skip this layer if the route doesn't match
if (path.toLowerCase().substr(0,route.length) !== route.toLowerCase()) {
return next(err);
}

// call the layer handle
call(layer.handle,route,err,req,next);
}

删掉混淆的代码后我们可以看到next实现也很简洁。一个递归调用顺序寻找中间件。不断的调用next。代码相当简单但是思路却很值得学习。

其中 done 是第三方处理方法。其他处理sub app以及路由的部分都删除了。不是重点

koa

koa将next的实现抽离成了一个单独的包，代码更加简单，但是实现了一个貌似更加复杂的功能

看着上面处理过的的代码有些同学可能还是会不明觉厉。

那么我们继续处理一下：

return function (context,next) {
// last called middleware #
let index = -1
return dispatch(0)
function dispatch (i) {
index = i
let fn = middleware[i]
if (i === middleware.length) {
fn = next
}
if (!fn) return
return fn(context,function next () {
return dispatch(i + 1)
})
}
}
}

这样一来程序更加简单了跟async/await也没有任何关系了，让我们看下结果好了

compose(ms)()

执行上面的程序我们可以发现依次输出：

foo1 bar1 qux1 qux2 bar2 foo2

同样是所谓koa的洋葱模型，到这里我们就可以得出这样一个结论：koa的中间件模型跟async或者generator并没有实际联系，只是koa强调async优先。所谓中间件暂停也只是回调函数的原因（在我看来promise.then与回调其实没有什么区别，甚至async/await也是回调的一种形式）。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持编程之家。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!