写在前面
工作后很久没有更新博文了,一些事看不惯,一些事改变不了,从开始积极地想要做些什么,到现在连伪工作都算不上,让自己不得不好好想想了。回过头来看自己工作这半年多,能说道说道的也只有混淆了(ps.接触了混淆,真心觉得混淆这门艺术高大上),不过不能在这里分享,就只能在这里巩固拓展学习了~
Koa
koa
由express
的原班人马打造,和express
相比,koa
是一个轻量级的node框架,它的所有功能都能通过中间件实现,这种插拔式的架构设计模式,很符合unix
哲学。
有关unix哲学,核心是简单原则,可以看这篇以及文末的评论。
想到最近实现的一个混淆策略,已经在实现第二版,但代码还是越写越绕,mentor在发现我第二版的混淆策略仍然有处理不了的样例时说让我改的下一版更优雅些、代码易懂一点。代码越写越绕的原因应该是写的过程中发现需要兼容到某几种特殊样例的情况,每次为了兼容这种情况都会在原有基础上改,改到后面看见那一坨坨的代码就晕。。。感觉还是自己思考时站的高度不够。
目前所用的框架是koa2
,与koa1
不同,koa1
使用的是generator+co
的执行方式,而koa2
使用的是async/await
,所以需要node v7.6.0
更高版本对async
的支持。
async/await
async
函数允许你把异步的代码(当然这个异步方法支持promise
时)当成同步的去对待,可读性高一些。在async function
内部使用await
来暂停async function
的执行,等待一个promise
对象处理完成。await
返回需要是Promise
对象。
先来一个最简单的koa样例:
|
|
启了一个node http server
,监听端口3000
,app.use
中维护了一个中间件队列,代码中的这个中间件的功能是对请求curl http://localhost:3000
响应内容hello world
。
next()
不是必须的,用来在当前中间件中想要downstream到下一个中间件时调用。
Middleware onion diagram
下面图中很清晰的表明了一个请求是如何经过中间件最后生成响应的:
理解洋葱模型怎么运作,来看下面的样例:
|
|
输出结果为:
|
|
每个中间件都接受一个koa context object
和一个next function
作为参数,调用next
函数会执行到下一个中间件中(如果在middleware1
中注释掉next
调用,就会发现并不会执行到middleware2
中)。
其中await next()
的作用是当程序运行到它时会暂停当前中间件的执行,进入下一个中间件,等后面的中间件都处理完之后再回过头来处理。也就是说,当一个请求发来时,middleware0
是第一个进入最后一个离开。
特殊地,koa
实现了对context
的保存和传递(将context
一路传下去给中间件),每个中间件的next
返回值是下一个中间件的返回值。
koa
这种洋葱结构,可以很方便的进行错误处理。
这里提一下,在回调函数中抛出错误,如果没有任何错误捕获处理,node进程会崩溃。同时对回调函数
try/catch
也是没有用的,是捕获不到的,解决方法一个是监听error
事件,在koa中的解决方法就是在外层中间件对错误进行捕获。可以看koa demo #Demo16: error handling & #Demo17: error listener。
|
|
在所有中间件中抛出的错误都可以在第一个中间件中捕获到,这样就可以包装一个统一的错误处理中间件。
Tips
- koa的一些demo
- koa context api
koa-bodyparser
:解析post请求的body数据koa-static
:把静态文件serve出去。针对koa demo #Demo12: static assets的样例,访问http://localhost:3000/12.js
页面上显示文件内容,而正常未使用koa-static
的访问时会显示Not Found
。koa-router
:路由,样例:
|
|
|
|