node中koa中间件机制详解

koa

koa是由express原班人马打造的一个更小、更富有表现力、更健壮的web框架。

在我眼中,koa的确是比express轻量的多,koa给我的感觉更像是一个中间件框架,koa只是一个基础的架子,需要用到的相应的功能时,用相应的中间件来实现就好,诸如路由系统等。一个更好的点在于,express是基于回调来处理,至于回调到底有多么的不好,大家可以自行搜索来看。koa1基于的co库,所以koa1利用Generator来代替回调,而koa2由于node对async/await的支持,所以koa2利用的是async/await。关于async以及co库等,大家可以参考我之前写过的一篇文章(理解async)。koa可以说是一个各种中间件的架子,下面就来看一下koa对于中间件部分的实现:

koa1的中间件

koa1主要利用的是Generator来实现,一般来说,koa1的一个中间件大概是长这个样子的:

app.use(function *(next){
  console.log(1);
  yield next;
  console.log(5);
});
app.use(function *(next){
  console.log(2);
  yield next;
  console.log(4);
});
app.use(function *(){
  console.log(3);
});

这样的输出会是1, 2, 3, 4, 5,koa的中间件的实现主要依靠的是koa-compose:

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(){}

源码非常的简单,实现的功能就是将所有的中间件串联起来,首先给倒数第一个中间件传入一个noop作为其next,再将这个整理后的倒数第一个中间作为next传入倒数第二个中间件,最终得到的next就是整理后的第一个中间件。说起来比较复杂,画图来看:

实现的效果如同上图,与redux需要实现的目标类似,只要遇到了yield next就去执行下一个中间件,利用co库很容易将这个流程串联起来,下面来简单模拟下,中间件完整的实现:

const middlewares = [];

const getTestMiddWare = (loggerA, loggerB) => {
  return function *(next) {
    console.log(loggerA);
    yield next;
    console.log(loggerB);
  }
};
const mid1 = getTestMiddWare(1, 4),
  mid2 = getTestMiddWare(2, 3);

const getData = new Promise((resolve, reject) => {
  setTimeout(() => resolve('数据已经取出'), 1000);
});

function *response(next) {
  // 模拟异步读取数据库数据
  const data = yield getData;
  console.log(data);
}

middlewares.push(mid1, mid2, response);
// 简单模拟co库
function co(gen) {
  const ctx = this,
    args = Array.prototype.slice.call(arguments, 1);
  return new Promise((reslove, reject) => {
    if (typeof gen === 'function') gen = gen.apply(ctx, args);
    if (!gen || typeof gen.next !== 'function') return resolve(gen);

    const baseHandle = handle => res => {
      let ret;
      try {
        ret = gen[handle](res);
      } catch(e) {
        reject(e);
      }
      next(ret);
    };
    const onFulfilled = baseHandle('next'),
      onRejected = baseHandle('throw');

    onFulfilled();
    function next(ret) {
      if (ret.done) return reslove(ret.value);
      // 将yield的返回值转换为Proimse
      let value = null;
      if (typeof ret.value.then !== 'function') {
        value = co(ret.value);
      } else {
        value = ret.value;
      }
      if (value) return value.then(onFulfilled, onRejected);
      return onRejected(new TypeError('yield type error'));
    }
  });
}
// 调用方式
const gen = compose(middlewares);
co(gen);

koa2的中间件

随着node对于async/await的支持,貌似不需要再借助于co这种工具库了,直接利用原生的就好,于是koa也做出了改变,来看目前的koa-compose:

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()
   // 用Promise包裹中间件,方便await调用
   try {
    return Promise.resolve(fn(context, function next () {
     return dispatch(i + 1)
    }))
   } catch (err) {
    return Promise.reject(err)
   }
  }
 }
}

koa-compose利用了Promise,koa2的中间件的参数也有一个变为了两个,而且执行下一个的中间件利用的是await next(),要达到与上面的示例代码的相同效果,需要更改中间件的写法:

const middlewares = [];
const getTestMiddWare = (loggerA, loggerB) => async (ctx, next) => {
  console.log(loggerA);
  await next();
  console.log(loggerB);
};

const mid1 = getTestMiddWare(1, 4),
  mid2 = getTestMiddWare(2, 3);
const response = async () => {
  // 模拟异步读取数据库数据
  const data = await getData();
  console.log(data);
};
const getData = () => new Promise((resolve, reject) => {
  setTimeout(() => resolve('数据已经取出'), 1000);
});
middlewares.push(mid1, mid2);

// 调用方式
compose(middlewares)(null, response);

如何做到兼容

可以看到的是,koa1与koa2对于中间件的实现还是有着很多的不同的,将koa1的中间件直接拿到koa2下面来使用肯定是会出现错误的,如何兼容这两个版本也成了一个问题,koa团队写了一个包来是koa1的中间件可以用于koa2中,叫做koa-convert,先来看看这个包怎么使用:

function *mid3(next) {
  console.log(2, 'koa1的中间件');
  yield next;
  console.log(3, 'koa1的中间件');
}
convert.compose(mid3)

来看下这个包实现的思路:

// 将参数转为数组,对每一个koa1的中间件执行convert操作
convert.compose = function (arr) {
 if (!Array.isArray(arr)) {
  arr = Array.from(arguments)
 }
 return compose(arr.map(convert))
}
// 关键在于convert的实现
const convert = mw => (ctx, next) => {
  // 借助co库,返回一个Promise,同时执行yield
  return co.call(ctx, mw.call(ctx, createGenerator(next)));
};

function * createGenerator (next) {
 /*
   next为koa-compomse中:
   function next () {
     return dispatch(i + 1)
   }
 */
 return yield next()
 // 执行完koa1的中间件,又回到了利用await执行koa2中间件的正轨
}

个人感觉koa-convert的思路就是对Generator封装一层Promise,使上一个中间件可以利用await next()的方式调用,对于Generator的执行,利用co库,从而达到了兼容的目的。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • 详解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

  • Java中的反射机制详解

    Java中的反射机制详解 反射,当时经常听他们说,自己也看过一些资料,也可能在设计模式中使用过,但是感觉对它没有一个较深入的了解,这次重新学习了一下,感觉还行吧! 一,先看一下反射的概念: 主要是指程序可以访问,检测和修改它本身状态或行为的一种能力,并能根据自身行为的状态和结果,调整或修改应用所描述行为的状态和相关的语义. 反射是Java中一种强大的工具,能够使我们很方便的创建灵活的代码,这些代码可以再运行时装配,无需在组件之间进行源代码链接.但是反射使用不当会成本很高! 看概念很晕的,继续往下

  • Android中的binder机制详解

    前言 Binder做为Android中核心机制,对于理解Android系统是必不可少的,关于binder的文章也有很多,但是每次看总感觉看的不是很懂,到底什么才是binder机制?为什么要使用binder机制?binder机制又是怎样运行的呢?这些问题只是了解binder机制是不够的,需要从Android的整体系统出发来分析,在我找了很多资料后,真正的弄懂了binder机制,相信看完这篇文章大家也可以弄懂binder机制. 1.Binder是什么? 要理解binder,先要知道IPC,Inter

  • C++中函数匹配机制详解

    首先,编译器会确定候选函数然后确定可行函数可行函数,再从可行函数中进一步挑选 候选函数:重载函数集中的函数 可行函数:可以调用的函数 最后进行寻找最佳匹配 有以下几种规则 1.该函数的每个实参的匹配都不劣于其他可行函数 2.至少有一个实参的匹配优于其他可行函数的匹配 3.满足上面两种要求的函数有且只有一个 如果上面三个要求都没满足,则出现二义性 一些演示 各有一个精确匹配的实参,编译器报错,不满足条件3 error void func(int a,int b) { cout << "

  • Node.js 的 GC 机制详解

    V8 的内存限制 在一般的后端开发语言中,在基本的内存使用上没有什么限制,然而在 Node 中通过 JavaScript 使用内存时就会发现只能使用部分内存(64位系统下约为1.4GB,32位系统下约为0.7GB).在这样的限制下,将会导致 Node 无法直接操作大内存对象. 造成这个问题的主要原因在于 Node 的 JavaScript 执行引擎 V8. 在 V8 中,所有的 JavaScript 对象都是通过堆来进行分配的.Node 提供了 V8 中内存的使用量查看方法 process.me

  • node.js中的事件处理机制详解

    EventEmitter类 在Node.js的用于实现各种事件处理的event模块中,定义了一个EventEmitter类.所有可能触发事件的对象都是一个集成了EventEmitter类的子类的实例对象,在Node.js中,为EventEmitter类定义了许多方法,所有与对象的事件处理函数的绑定及解除相关的处理均依靠这些方法的调用来执行. EventEmitter类的各种方法 event:代表事件名 listener:代表事件处理函数 中括号内的参数代表该参数为可选参数 方法名与参数 描述 a

  • C++中的异常处理机制详解

    异常处理 增强错误恢复能力是提高代码健壮性的最有力的途径之一,C语言中采用的错误处理方法被认为是紧耦合的,函数的使用者必须在非常靠近函数调用的地方编写错误处理代码,这样会使得其变得笨拙和难以使用.C++中引入了异常处理机制,这是C++的主要特征之一,是考虑问题和处理错误的一种更好的方式.使用错误处理可以带来一些优点,如下: 错误处理代码的编写不再冗长乏味,并且不再和正常的代码混合在一起,程序员只需要编写希望产生的代码,然后在后面某个单独的区段里编写处理错误的嗲吗.多次调用同一个函数,则只需要某个

  • C++中的RAII机制详解

    前言 在写C++设计模式--单例模式的时候,在写到实例销毁时,设计的GC类是很巧妙的,而这一巧妙的设计就是根据当对象的生命周期结束时会自动调用其析构函数的,而这一巧妙的设计也是有专业的名词的--RAII.那以下将围绕RAII,全面的讲解RAII的相关知识. 什么是RAII? RAII是Resource Acquisition Is Initialization的简称,是C++语言的一种管理资源.避免泄漏的惯用法.利用的就是C++构造的对象最终会被销毁的原则.RAII的做法是使用一个对象,在其构造

  • Android中NestedScrolling滑动机制详解

    1,如今NestedScrolling运用到很多地方了,要想好看一点的滑动变换,基本上就是使用这个来完成的,让我们来简单的了解一下. 2,NestedScrolling机制能够让父View和子View在滚动式进行配合,其基本流程如下: 当子view开始滚动之前,可以通知父View,让其先于自己进行滚动: 子View自己进行滚动: 子view滚动之后,还可以通知父view继续滚动. 而要实现这样的交互机制,首先父view要实现NestedScrollingParent接口,而子View需要实现N恩

  • C++中的RTTI机制详解

    前言 RTTI是"Runtime Type Information"的缩写,意思是运行时类型信息,它提供了运行时确定对象类型的方法.RTTI并不是什么新的东西,很早就有了这个技术,但是,在实际应用中使用的比较少而已.而我这里就是对RTTI进行总结,今天我没有用到,并不代表这个东西没用.学无止境,先从typeid函数开始讲起. typeid函数 typeid的主要作用就是让用户知道当前的变量是什么类型的,比如以下代码: 复制代码 代码如下: #include <iostream&g

随机推荐