koa源码解读
koa是有express原班人马打造的基于node.js的下一代web开发框架。koa 1.0使用generator实现异步,相比于回调简单和优雅和不少。koa团队并没有止步于koa 1.0, 随着node.js开始支持async/await,他们又马不停蹄的发布了koa 2.0,koa2完全使用Promise并配合async/await来实现异步,使得异步操作更臻完美。
一、快速开始
koa使用起来非常简单,安装好node.js后执行以下命令安装koa:
npm init
npm install --save koa
一个简单的Hello World程序开场,
//index.js const Koa = require('koa')
const app = new Koa() app.use(async ctx => {
ctx.body = 'Hello World' }) app.listen(3000, () => {
console.log("server is running at 3000 port");
})
在命令行执行
node index.js
打开浏览器查看http://localhost:3000就可以看到页面输出的 Hello World。
中间件 middleware
Koa中使用 app.use()用来加载中间件,基本上Koa 所有的功能都是通过中间件实现的。
中间件的设计非常巧妙,多个中间件会形成一个栈结构(middle stack),以”先进后出”(first-in-last-out)的顺序执行。每个中间件默认接受两个参数,第一个参数是 Context 对象,第二个参数是 next函数。只要调用 next函数,就可以把执行权转交给下一个中间件,最里层的中间件执行完后有会把执行权返回给上一级调用的中间件。整个执行过程就像一个剥洋葱的过程。
比如你可以通过在所有中间件的顶端添加以下中间件来打印请求日志到控制台:
app.use(async function (ctx, next) { let start = new Date() await next() let ms = new Date() - start console.log('%s %s - %s', ctx.method, ctx.url, ms) })
常用的中间件列表可以在这里找到: https://github.com/koajs/koa/wiki
二、koa源码解读
打开项目根目录下的node_modules文件夹,打开并找到koa的文件夹,如下所示:
打开lib文件夹,这里一共有4个文件,
application.js - koa主程序入口
context.js - koa中间件参数ctx对象的封装
request.js - request对象封装
response.js - response对象封装
我们这里主要看下application.js,我这里摘取了主要功能相关的 代码如下:
/**
* Shorthand for:
*
* http.createServer(app.callback()).listen(...)
*
* @param {Mixed} ...
* @return {Server}
* @api public
*/ listen(...args) {
debug('listen');
const server = http.createServer(this.callback());
return server.listen(...args);
} /**
* Use the given middleware `fn`.
*
* Old-style middleware will be converted.
*
* @param {Function} fn
* @return {Application} self
* @api public
*/ use(fn) {
if (typeof fn !== 'function') throw new TypeError('middleware must be a function!');
if (isGeneratorFunction(fn)) {
deprecate('Support for generators will be removed in v3. ' +
'See the documentation for examples of how to convert old middleware ' +
'https://github.com/koajs/koa/blob/master/docs/migration.md');
fn = convert(fn);
}
debug('use %s', fn._name || fn.name || '-');
this.middleware.push(fn);
return this;
} /**
* Return a request handler callback
* for node's native http server.
*
* @return {Function}
* @api public
*/ callback() {
const fn = compose(this.middleware); if (!this.listenerCount('error')) this.on('error', this.onerror); const handleRequest = (req, res) => {
const ctx = this.createContext(req, res);
return this.handleRequest(ctx, fn);
}; return handleRequest;
} /**
* Handle request in callback.
*
* @api private
*/ handleRequest(ctx, fnMiddleware) {
const res = ctx.res;
res.statusCode = 404;
const onerror = err => ctx.onerror(err);
const handleResponse = () => respond(ctx);
onFinished(res, onerror);
return fnMiddleware(ctx).then(handleResponse).catch(onerror);
}
通过注释我们可以看出上面代码主要干的事情是初始化http服务对象并启动。我们注意到 callback()方法里面有这样一段代码 :
const fn = compose(this.middleware);
compose其实是Node模块koa-compose,它的作用是将多个中间件函数合并成一个大的中间件函数,然后调用这个中间件函数就可以依次执行添加的中间件函数,执行一系列的任务。遇到await next()时就停止当前中间件函数的执行并把执行权交个下一个中间件函数,最后next()执行完返回上一个中间件函数继续执行下面的代码。
它是用了什么黑魔法实现的呢?我们打开node_modules/koa-compose/index.js,代码如下 :
function compose(middleware) { return function (context, next) { // last called middleware # let index = -1 return dispatch(0) function dispatch(i) { if (i <= index) return Promise.reject(new Error('next() called multiple times')) index = i let fn = middleware[i] if (i === middleware.length) fn = next if (!fn) return Promise.resolve() try { return Promise.resolve(fn(context, dispatch.bind(null, i + 1))); } catch (err) { return Promise.reject(err) } } } }
乍一看好难好复杂,没事,我们一步一步的来梳理一下。
这个方法里面的核心就是dispatch函数(废话,整个compose方法就返回了一个函数)。没有办法简写,但是我们可以将dispatch函数类似递归的调用展开,以三个中间件为例:
第一次,此时第一个中间件被调用,dispatch(0),展开:
Promise.resolve(function(context, next){ //中间件一第一部分代码 await/yield next(); //中间件一第二部分代码}());
很明显这里的next指向dispatch(1),那么就进入了第二个中间件;
第二次,此时第二个中间件被调用,dispatch(1),展开:
Promise.resolve(function(context, 中间件2){ //中间件一第一部分代码 await/yield Promise.resolve(function(context, next){ //中间件二第一部分代码 await/yield next(); //中间件二第二部分代码 }()) //中间件一第二部分代码}());
很明显这里的next指向dispatch(2),那么就进入了第三个中间件;
第三次,此时第二个中间件被调用,dispatch(2),展开:
Promise.resolve(function(context, 中间件2){ //中间件一第一部分代码 await/yield Promise.resolve(function(context, 中间件3){ //中间件二第一部分代码 await/yield Promise(function(context){ //中间件三代码 }()); //中间件二第二部分代码 }) //中间件一第二部分代码}());
此时中间件三代码执行完毕,开始执行中间件二第二部分代码,执行完毕,开始执行中间一第二部分代码,执行完毕,所有中间件加载完毕。
再举一个例子加深下理解。新建index.js并粘贴如下代码:
const compose = require('koa-compose') const middleware1 = (ctx, next) => {
console.log('here is in middleware1, before next:');
next();
console.log('middleware1 end');
} const middleware2 = (ctx, next) => {
console.log('here is in middleware2, before next:');
next();
console.log('middleware2 end');
} const middleware3 = (ctx, next) => {
console.log('here is in middleware3, before next:');
next();
console.log('middleware3 end');
} const middlewares = compose([middleware1, middleware2, middleware3])
console.dir(middlewares())
在命令行输入node index.js执行,输出结果如下:
here is in middleware1, before next:
here is in middleware2, before next:
here is in middleware3, before next:
middleware3 end
middleware2 end
middleware1 end
Promise { undefined }
可以看到每个中间件都按照“剥洋葱”的流程一次执行。当我们初始化app对象并调用app.use()时,就是在不断往app.middleware数组里添加中间件函数,当调用app.listen()再执行组合出来的函数。
-END-
转载请注明来源
扫描下方二维码,或者搜索 前端提高班 关注公众号,即可获取最新走心文章
记得把我设为星标或置顶哦
在公众号后台回复 前端资源 即可获取最新前端开发资源
koa源码解读的更多相关文章
- 从koa-session源码解读session本质
前言 Session,又称为"会话控制",存储特定用户会话所需的属性及配置信息.存于服务器,在整个用户会话中一直存在. 然而: session 到底是什么? session 是存在 ...
- SDWebImage源码解读之SDWebImageDownloaderOperation
第七篇 前言 本篇文章主要讲解下载操作的相关知识,SDWebImageDownloaderOperation的主要任务是把一张图片从服务器下载到内存中.下载数据并不难,如何对下载这一系列的任务进行设计 ...
- SDWebImage源码解读 之 NSData+ImageContentType
第一篇 前言 从今天开始,我将开启一段源码解读的旅途了.在这里先暂时不透露具体解读的源码到底是哪些?因为也可能随着解读的进行会更改计划.但能够肯定的是,这一系列之中肯定会有Swift版本的代码. 说说 ...
- SDWebImage源码解读 之 UIImage+GIF
第二篇 前言 本篇是和GIF相关的一个UIImage的分类.主要提供了三个方法: + (UIImage *)sd_animatedGIFNamed:(NSString *)name ----- 根据名 ...
- SDWebImage源码解读 之 SDWebImageCompat
第三篇 前言 本篇主要解读SDWebImage的配置文件.正如compat的定义,该配置文件主要是兼容Apple的其他设备.也许我们真实的开发平台只有一个,但考虑各个平台的兼容性,对于框架有着很重要的 ...
- SDWebImage源码解读_之SDWebImageDecoder
第四篇 前言 首先,我们要弄明白一个问题? 为什么要对UIImage进行解码呢?难道不能直接使用吗? 其实不解码也是可以使用的,假如说我们通过imageNamed:来加载image,系统默认会在主线程 ...
- SDWebImage源码解读之SDWebImageCache(上)
第五篇 前言 本篇主要讲解图片缓存类的知识,虽然只涉及了图片方面的缓存的设计,但思想同样适用于别的方面的设计.在架构上来说,缓存算是存储设计的一部分.我们把各种不同的存储内容按照功能进行切割后,图片缓 ...
- SDWebImage源码解读之SDWebImageCache(下)
第六篇 前言 我们在SDWebImageCache(上)中了解了这个缓存类大概的功能是什么?那么接下来就要看看这些功能是如何实现的? 再次强调,不管是图片的缓存还是其他各种不同形式的缓存,在原理上都极 ...
- AFNetworking 3.0 源码解读 总结(干货)(下)
承接上一篇AFNetworking 3.0 源码解读 总结(干货)(上) 21.网络服务类型NSURLRequestNetworkServiceType 示例代码: typedef NS_ENUM(N ...
随机推荐
- hdoj5842【水题】
比赛的时候还特别撒比地写了二分的那个写法,然后wa了一发,因为这个集合的翻译成自然数集.还是转换了一下,还是去写了一个二分. 后面就是出现几种就是多长... 比赛的真的非常非常挫的code-. #in ...
- HDOJ1584蜘蛛牌【DFS】
10张牌,大的只能跟小的跑,可以针对每一个状态进行搜索,求一个最小的移动距离. 但是不会怎么遍历整个状态是硬伤? 因为只能大的跟着小的. 先把小的标记,去寻找大的点,最终一定是满足的吧. 比如先标记1 ...
- Luogu P1156 垃圾陷阱 【dp】By cellur925
题目传送门 这题...看上去浓浓的背包气息...但是并不好设计状态啊emmm. 我们考虑可能成为状态的量:高度.血量.时间.物品.看数据范围也猜到应该大概是个二维dp了w. 正确的状态设计之一:设$f ...
- Asp.net WebApi 异常处理解决方案
一.使用异常筛选器捕获所有异常 我们知道,一般情况下,WebApi作为服务使用,每次客户端发送http请求到我们的WebApi服务里面,服务端得到结果输出response到客户端.这个过程中,一旦服务 ...
- Mysql的外键
概念:如果一个实体A的某一字段,刚好指向或引用另一个实体B的主键,那么实体A的这个字段就叫作外键,所以简单来说,外键就是外面的主键,就是其他表的主键. 例: 以上的学生表的班级字段,就是一个外键! 其 ...
- PV,UV,IP概念
PV是网站分析的一个术语,用以衡量网站用户访问的网页的数量.对于广告主,PV值可预期它可以带来多少广告收入.一般来说,PV与来访者的数量成正比,但是PV并不直接决定页面的真实来访者数量,如同一个来访者 ...
- [转]ASP.NET MVC URL重写与优化(进阶篇)-继承RouteBase玩转URL
本文转自:http://www.cnblogs.com/John-Connor/archive/2012/05/03/2478821.html 引言-- 在初级篇中,我们介绍了如何利用基于ASP.NE ...
- PL/SQL笔记(1)-流程控制,循环,异常,块
流程控制 1.If,then,else,elsif(不是elseif) ' then null; endif; 2.Case 简单case表达式: 搜索型Case表达式: 3.goto语句 begin ...
- position 位置、表单
一.position 位置 1.只要使用了定位,必须有一个相对的参照物 2.具体定位的那个元素需加position:absolute:(绝对的) 绝对的:就是具体到某一个地方,特别详细的意思 ...
- laravel学习笔记(三)
模型传值 路由: Route::get('/posts/{post}','\App\Http\Controllers\PostController@show'); 方法: public functio ...