在koa中想要优雅的发送响应?看这就对了
背景
前不久把项目中用了很久的一个伪中间件撸成了一个npm包发布了出去。
为什么叫伪中间件?正常的中间件的引用方式, 就拿body-parser为例。
var Koa = require('koa'); var bodyParser = require('koa-bodyparser'); var app = new Koa(); app.use(bodyParser()); app.use(async ctx => { // the parsed body will store in ctx.request.body // if nothing was parsed, body will be an empty object {} ctx.body = ctx.request.body; });
反观我撸的伪中间件的引用方式。
const response = require('../uitls/Response'); const data = {}; response.success(ctx, data);
为什么要这么干呢...纯粹是因为这个伪中间件与现有项目的耦合度太高了,
为(就)了(是)方(懒)便在项目里面把这个伪中间件的引用方式从本地工具组件换成从node_modules里引用。
例如这样。
const response = require('koa2-response'); const data = {}; response.success(ctx, data);
经过一番折腾,项目中的引用方式全部替换完了。然后我的学弟就看不下去了。。。提了一个pullrequest给我。把这个着实封装成了一个中间件
优化
首先是改变了引用方式,之前的方式是直接导出了一个对象,这个对象有两个方法,分别是success和error。使用这种方式,就必须要在每个controller中都引用一次,如下。
const response = require('../utils/Response');
优化之后,只需要在node的入口文件中做如下操作就好
const koa = require('koa'); const app = new koa(); const router = require('koa-router')(); const response = require('koa2-response'); const code = { UNKNOWN_ERROR: [1, 'Sorry, you seem to have encountered some unknown errors.'] } router .get('/', (ctx, next) => { ctx.success({ name: 'test' }) }) .get('/error_test', (ctx, next) => { ctx.error(code.UNKNOWN_ERROR); }) app.use(router.routes()); app.use(router.allowedMethods()); app.listen(3000); console.log(`Server is running on port 3000`);
对比两种方式可能有有些疑问,第一种方式,需要传入ctx,而改良之后的方式没有了ctx。那是因为在中间件中做了如下处理。
const { success, error } = require('./util'); module.exports = async (ctx, next) => { ctx.success = success.bind(null, ctx); ctx.error = error.bind(null, ctx); await next(); }
这样一来,koa的上下文ctx就会被当作ctx.success的默认第一个参数。针对不同模块的controller,不需要再去单独引用一次依赖包,可以直接通过ctx对中间件进行调用。相对于最初的版本,这样大大的提高了开发的效率。
写在后面
对于这个,还是有些顾虑。如果koa之后更新的时候,也出现了success和error的方法,再引入这个包,就会覆盖掉koa方法。
不知道会不会带来什么问题。
Pull Request地址
Github传送门
个人博客传送门

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
「架构技术专题」9种高性能高可用高并发的技术架构(5)
每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复工作。所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行灯一系列问题与挑战。为此,在实践中提出了许多解决方案,以实现网站高性能、高可靠性、易伸缩、可扩展、安全等各种技术架构目标。 1、分层 分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统。 在网站的分层架构中,常见的为3层,即应用层、服务层、数据层。应用层具体负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储访问服务,如数据库、缓存、文件、搜索引擎等。 分层架构是逻辑上的,在物理部署上,三层架构可以部署在同一个物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,即三层结构分别部署在不同的服务器上,是网站拥有更多的计算资源以应对越来越多的用户访问。 所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护,但在网站的发展过程中,分层结...
- 下一篇
人人都应学习的公链知识——比原总体架构
【揭秘区块链技术从入门到精通】比原链整体设计&架构解读视频链接: "> 本文将会给大家介绍一下比原链总体的技术架构。如下图所示:比原链分为三个层次 第一层就是大家接触比较多的钱包层,就是进行收款和打款的模块,钱包一般带操作界面,大家都可以日常使用,所以会比较熟悉。 第二层是最核心的内核层,内核可以理解为分布式系统中每个节点认同的一套规则,只有有相同的规则,两个节点才能达成一致。如果规则不同,其实就是发生分叉了。 第三层是通信层,通信层是节点之间交换信息的方式,包含区块同步,交易同步等。 首先来看内核层,内核层主要由五个模块构成: 孤儿块管理:孤儿块就是由矿工挖出但未成为主链区块的区块(在相同高度产生2个甚至更多的合法区块,一个区块成为主链,剩下的则称为孤儿块),孤儿块管理就是将未成为主链区块的孤儿块存储起来。 共识层:确认一个块是否合法。分为区块头验证和交易验证。区块头验证需要验证它的父块和时间戳,同是需要算力来保证记账权利。交易验证比原特别的设计了一层BC层,这层在交易验证时会获得更好的性能,交易验证还和智能合约相关,交易被验证时参数会参入虚拟机验证该交易是否合法。 区块树...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装Docker,最新的服务器搭配容器使用
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS8编译安装MySQL8.0.19