koa中间件核心(koa-compose)源码解读分析

最近经常使用koa进行服务端开发,迷恋上了koa的洋葱模型,觉得这玩意太好用了。而且koa是以精简为主,没有很多集成东西,所有的东西都需按需加载,这个更是太合我胃口了哈哈哈哈。

相对与express的中间件,express的中间件使用的是串联,就像冰糖葫芦一样一个接着一个,而koa使用的V型结构(洋葱模型),这将给我们的中间件提供更加灵活的处理方式。

基于对洋葱模型的热衷,所以对koa的洋葱模型进行一探究竟,不管是koa1还是koa2的中间件都是基于koa-compose进行编写的,这种V型结构的实现就来源于koa-compose。
附上源码先:

function compose (middleware) {
 // 参数middleware 是一个中间件数组,存放我们用app.use()一个个串联起来的中间件
 // 判断中间件列表是否为数组,如果不为数组,则抛出类型错误
 if (!Array.isArray(middleware)) throw new TypeError('Middleware stack must be an array!')
 // 判断中间件是否为函数,如果不为函数,则抛出类型错误
 for (const fn of middleware) {
  if (typeof fn !== 'function') throw new TypeError('Middleware must be composed of functions!')
 }

 /**
 1. @param {Object} context
 2. @return {Promise}
 3. @api public
  */

 return function (context, next) {
  // 这里next指的是洋葱模型的中心函数
  // context是一个配置对象,保存着一些配置,当然也可以利用context将一些参数往下一个中间传递

  // last called middleware #
  let index = -1 // index是记录执行的中间件的索引
  return dispatch(0) // 执行第一个中间件 然后通过第一个中间件递归调用下一个中间件

  function dispatch (i) {
   // 这里是保证同个中间件中一个next()不被调用多次调用
   // 当next()函数被调用两次的时候,i会小于index,然后抛出错误
   if (i <= index) return Promise.reject(new Error('next() called multiple times'))
   index = i
   let fn = middleware[i] // 取出要执行的中间件
   if (i === middleware.length) fn = next // 如果i 等于 中间件的长度,即到了洋葱模型的中心(最后一个中间件)
   if (!fn) return Promise.resolve() // 如果中间件为空,即直接resolve
   try {
    // 递归执行下一个中间件 (下面会重点分析这个)
    return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));
   } catch (err) {
    return Promise.reject(err)
   }
  }
 }
}

看到这里,如果下面的那些能够理解,那么下面的可以不用看的,还是不能理解的就继续往下看,详细一点的分析。

首先,我们用app.use()添加一个中间件,在koa的源码里app.use()这个方法就是将一个中间件push进middleware这个中间件列表里。源码里是这么写的(这个比较简单 不做分析):

 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;
 }

compose这个方法传入一个中间件列表middleware,这个列表就是我们使用use()添加进去的方法列表,首先会判断列表是否为数组,中间件是否为方法,如果不是就直接抛出类型错误。

  1. compose返回的是一个函数,这里使用闭包来缓存中间件列表,然后这个函数接收两个参数,第一个参数是context,是一个存放配置信息的对象。第二份参数是一个next方法,也是洋葱模型的中心或者说是V型模型的拐点。
  2. 创建一个index变量来保存执行的中间件索引,然后从第一个中间件开始开始递归执行。
let index = -1
return dispatch(0)

dispatch方法就是执行中间件,先判断索引,如果i小于index那么说明在同一个中间件里执行了两次或两次以上的next函数,如果i>index则说明该中间件还未执行,那么将该中间件的所以记录下来

if (i <= index) return Promise.reject(new Error('next() called multiple times'))
index = i

取出该中间件,如果i等于中间件的长图,则说明执行到了洋葱模型的中心,则最后一个中间件,如果中间件为空,那么就直接resovle掉

    let fn = middleware[i]
    if(i === middleware.length){
     fn = next
    }
    if(!fn){
      return Promise.resolve()
    }

到了最刺激的部分了,也是有点绕的部分了,首先为啥return的是一个Promise的对象(Promise.resolve也是一个promise对象)呢,因为我们await next()的时候,await是等待且执行一个async函数的完成,async会默认返回一个promise对象,所以这里return的是一个promise对象。我们在每个中间里面await mext() next()指的就是下一个中间件,也就是

fn(context, function next () {
      return dispatch(i + 1)
     })

所以我们上一个中的await 等待的就是dispatch(i+1)的执行完成,dispatch返回的是Promise.resolve(fn(context, function next () { xxxx })),这样来看虽然一开始只执行了dispatch(0),但是是由这个函数形成了一条执行链。

以三个中间件执行为例,dispatch(0)执行后就形成:

Promise.resolve( // 第一个中间件
 function(context,next){ // 这里的next第二个中间件也就是dispatch(1)
   // await next上的代码 (中间件1)
  await Promise.resolve( // 第二个中间件
   function(context,next){ // 这里的next第二个中间件也就是dispatch(2)
     // await next上的代码 (中间件2)
    await Promise.resolve( // 第三个中间件
     function(context,next){ // 这里的next第二个中间件也就是dispatch(3)
       // await next上的代码 (中间件3)
      await Promise.resolve()
      // await next下的代码 (中间件3)
     }
    )
     // await next下的代码 (中间件2)
   }
  )
   // await next下的代码 (中间件2)
 }
)

先执行await上面的代码,然后等待最后一个中间件resolve一个个往上传递,这就形成了一个洋葱模型。
最后附上测试代码:

async function test1(ctx, next) {
  console.log('中间件1上');
  await next();
  console.log('中间件1下');
 };

 async function test2(ctx, next) {
  console.log('中间件2上');
  await next();
  console.log('中间件2下');
 };

 async function test3(ctx, next) {
  console.log('中间件3上');
  await next();
  console.log('中间件3下');
 };
 let middleware = [test1, test2, test3];

 let cp = compose(middleware);

 cp('ctx', function() {
  console.log('中心');
 });

OK,到这里koa2的中间件核心(koa-compose)就解析完成了,一开始看的时候,也被绕了好久,多看几遍多分析一步一步捋顺。koa1的中间件等过几天有时间再补上吧,koa1是基于generator,源码比起koa2相对简单。

最近在看koa2源码,等有时间再继续更新koa一些源码的分析。

到此这篇关于koa中间件核心(koa-compose)源码解读分析的文章就介绍到这了,更多相关koa中间件核心内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • koa2的中间件功能及应用示例

    最近因为开发一个自己的博客网站,学习了koa2的搭建,写了一些自己认为比较重要或需要知道的koa2中间件作用和使用场景. koa-router 路由中间件 下载 npm i koa-router 使用 普通使用方法 需要注意的是引入的koa-router是一个方法,引入后需要执行这个方法. const Koa = require('koa'); const app = new Koa(); const router = require('koa-router')(); // 配置路由url //

  • 深入解析koa之中间件流程控制

    前言 koa被认为是第二代web后端开发框架,相比于前代express而言,其最大的特色无疑就是解决了回调金字塔的问题,让异步的写法更加的简洁.在使用koa的过程中,其实一直比较好奇koa内部的实现机理.最近终于有空,比较深入的研究了一下koa一些原理,在这里会写一系列文章来记录一下我的学习心得和理解. 在我看来,koa最核心的函数是大名鼎鼎的co,koa正是基于这个函数实现了异步回调同步化,以及中间件流程控制.当然在这篇文章中我并不会去分析co源码,我打算在整个系列文章中,一步一步讲解如何实现

  • 详解KOA2如何手写中间件(装饰器模式)

    前言 Koa 2.x 版本是当下最流行的 NodeJS 框架, Koa 2.0 的源码特别精简,不像 Express 封装的功能那么多,所以大部分的功能都是由 Koa 开发团队(同 Express 是一家出品)和社区贡献者针对 Koa 对 NodeJS 的封装特性实现的中间件来提供的,用法非常简单,就是引入中间件,并调用 Koa 的 use 方法使用在对应的位置,这样就可以通过在内部操作 ctx 实现一些功能,我们接下来就讨论常用中间件的实现原理以及我们应该如何开发一个 Koa 中间件供自己和别

  • Koa日志中间件封装开发详解

    对于一个服务器应用来说,日志的记录是必不可少的,我们需要使用其记录项目程序每天都做了什么,什么时候发生过错误,发生过什么错误等等,便于日后回顾.实时掌握服务器的运行状态,还原问题场景. 日志的作用 记录服务器程序运行状态: 帮助开发者快速捕获错误,定位以及决解故障. 日志中间件开发工具log4js 在node当中没有自带的日志模块,所以需要使用第三方模块 使用模块:log4js 安装: npm i log4js -S logsjs官方文档 日志分类: 访问日志: 记录客户端对项目的访问,主要是

  • 浅谈redux, koa, express 中间件实现对比解析

    如果你有 express ,koa, redux 的使用经验,就会发现他们都有 中间件(middlewares)的概念,中间件 是一种拦截器的思想,用于在某个特定的输入输出之间添加一些额外处理,同时不影响原有操作. 最开始接触 中间件是在服务端使用 express 和 koa 的时候,后来从服务端延伸到前端,看到其在redux的设计中也得到的极大的发挥.中间件的设计思想也为许多框架带来了灵活而强大的扩展性. 本文主要对比redux, koa, express 的中间件实现,为了更直观,我会抽取出

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

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

  • node中koa中间件机制详解

    koa koa是由express原班人马打造的一个更小.更富有表现力.更健壮的web框架. 在我眼中,koa的确是比express轻量的多,koa给我的感觉更像是一个中间件框架,koa只是一个基础的架子,需要用到的相应的功能时,用相应的中间件来实现就好,诸如路由系统等.一个更好的点在于,express是基于回调来处理,至于回调到底有多么的不好,大家可以自行搜索来看.koa1基于的co库,所以koa1利用Generator来代替回调,而koa2由于node对async/await的支持,所以koa

  • 深入理解 Koa 框架中间件原理

    Node 主要用在开发 Web 应用,koa 是目前 node 里最流行的 web 框架. 在 Node 开启一个 http 服务简直易如反掌,官网 demo. const http = require("http"); const server = http.createServer((req, res) => { res.statusCode = 200; res.setHeader("Content-Type", "text/plain&quo

  • 傻瓜式解读koa中间件处理模块koa-compose的使用

    最近需要单独使用到koa-compose这个模块,虽然使用koa的时候大致知道中间件的执行流程,但是没仔细研究过源码用起来还是不放心(主要是这个模块代码少,多的话也没兴趣去研究了). koa-compose看起来代码少,但是确实绕.闭包,递归,Promise...看了一遍脑子里绕不清楚.看了网上几篇解读文章,都是针对单行代码做解释,还是绕不清楚.最后只好采取一种傻瓜的方式: koa-compose去掉一些注释,类型校验后,源码如下: function compose (middleware) {

  • koa中间件核心(koa-compose)源码解读分析

    最近经常使用koa进行服务端开发,迷恋上了koa的洋葱模型,觉得这玩意太好用了.而且koa是以精简为主,没有很多集成东西,所有的东西都需按需加载,这个更是太合我胃口了哈哈哈哈. 相对与express的中间件,express的中间件使用的是串联,就像冰糖葫芦一样一个接着一个,而koa使用的V型结构(洋葱模型),这将给我们的中间件提供更加灵活的处理方式. 基于对洋葱模型的热衷,所以对koa的洋葱模型进行一探究竟,不管是koa1还是koa2的中间件都是基于koa-compose进行编写的,这种V型结构

  • java线程池核心API源码详细分析

    目录 概述 源码分析 Executor ExecutorService ScheduledExecutorService ThreadPoolExecutor ScheduledThreadPoolExecutor 总结 概述 线程池是一种多线程处理形式,处理过程中将任务添加到队列,然后在创建线程后自动启动这些任务.线程池线程都是后台线程.每个线程都使用默认的堆栈大小,以默认的优先级运行,并处于多线程单元中.如果某个线程在托管代码中空闲(如正在等待某个事件),则线程池将插入另一个辅助线程来使所有

  • 详解webpack-dev-middleware 源码解读

    前言 Webpack 的使用目前已经是前端开发工程师必备技能之一.若是想在本地环境启动一个开发服务,大家只需在 Webpack 的配置中,增加 devServer的配置来启动.devServer 配置的本质是 webpack-dev-server 这个包提供的功能,而 webpack-dev-middleware 则是这个包的底层依赖. 截至本文发表前,webpack-dev-middleware 的最新版本为 webpack-dev-middleware@3.7.2,本文的源码来自于此版本.本

  • Ajax::prototype 源码解读

    AJAX之旅(1):由prototype_1.3.1进入javascript殿堂-类的初探  还是决定冠上ajax的头衔,毕竟很多人会用这个关键词搜索.虽然我认为这只是个炒作的概念,不过不得不承认ajax叫起来要方便多了.所以ajax的意思我就不详细解释了. 写这个教程的起因很简单:经过一段时间的ajax学习,有一些体会,并且越发认识到ajax技术的强大,所以决定记录下来,顺便也是对自己思路的整理.有关这个教程的后续,请关注http://www.x2design.net 前几年,javascri

  • 基于线程池的工作原理与源码解读

    随着cpu核数越来越多,不可避免的利用多线程技术以充分利用其计算能力.所以,多线程技术是服务端开发人员必须掌握的技术. 线程的创建和销毁,都涉及到系统调用,比较消耗系统资源,所以就引入了线程池技术,避免频繁的线程创建和销毁. 在Java用有一个Executors工具类,可以为我们创建一个线程池,其本质就是new了一个ThreadPoolExecutor对象.线程池几乎也是面试必考问题.本节结合源代码,说说ThreadExecutor的工作原理 一.线程池创建 先看一下ThreadPoolExec

  • vue3 源码解读之 time slicing的使用方法

    今天给大家带来一篇源码解析的文章,emm 是关于 vue3 的,vue3 源码放出后,已经有很多文章来分析它的源码,我觉得很快又要烂大街了,哈哈 不过今天我要解析的部分是已经被废除的 time slicing 部分,这部分源码曾经出现在 vue conf 2018 的视频中,但是源码已经被移除掉了,之后可能也不会有人关注,所以应该不会烂大街 打包 阅读源码之前,需要先进行打包,打包出一份干净可调试的文件很重要 vue3 使用的 rollup 进行打包,我们需要先对它进行改造 import cle

  • 深入理解Java线程池从设计思想到源码解读

    线程池:从设计思想到源码解析 前言初识线程池线程池优势线程池设计思路 深入线程池构造方法任务队列拒绝策略线程池状态初始化&容量调整&关闭 使用线程池ThreadPoolExecutorExecutors封装线程池 解读线程池execute()addWorker()Worker类runWorker()processWorkerExit() 前言 各位小伙伴儿,春节已经结束了,在此献上一篇肝了一个春节假期的迟来的拜年之作,希望读者朋友们都能有收获. 根据穆氏哲学,投入越多,收获越大.我作此文时

  • 浅谈SpringMVC请求映射handler源码解读

    请求映射源码 首先看一张请求完整流转图(这里感谢博客园上这位大神的图,博客地址我忘记了): 前台发送给后台的访问请求是如何找到对应的控制器映射并执行后续的后台操作呢,其核心为DispatcherServlet.java与HandlerMapper.在spring boot初始化的时候,将会加载所有的请求与对应的处理器映射为HandlerMapper组件.我们可以在springMVC的自动配置类中找到对应的Bean. @Bean @Primary @Override public RequestM

  • 深入了解Java线程池:从设计思想到源码解读

    目录 为什么需要线程池 线程池设计思路 线程池的工作机制 线程池的参数及使用 线程池的状态 提交任务 任务队列 线程工厂 拒绝策略 关闭线程池 Executors 静态工厂 合理地配置线程池 线程池的监控 源码分析 execute addWorker Worker runWorker getTask processWorkerExit 面试题 为什么需要线程池 我们知道创建线程的常用方式就是 new Thread() ,而每一次 new Thread() 都会重新创建一个线程,而线程的创建和销毁

  • mybatis源码解读之executor包懒加载功能 

    ProxyFactory是创建代理类的工厂接口,其中的setProperties方法用来对工厂进行属性设置,但是mybatis内置的两个实现类都没有实现该接口,所以不支持属性设置.createProxy方法用来创建一个代理对象 public interface ProxyFactory {   // 设置工厂属性   default void setProperties(Properties properties) {   }   // 创建代理对象   Object createProxy(O

随机推荐