Eggjs 从放弃到开始使用

咦,这篇文章标题为什么反了?

实际上这是个人走过的心路历程,最初看到 eggjs 的时候,我就觉得 Egg 很明显不符合我的审美——我选择 koa 的理由就是小巧精致,all in middleware. 而 eggjs 不是画蛇添足吗?

这次新项目用到了公司自改版 egg,不过其实也就是 egg 多封装了几个 service。

——一开始我是拒绝的。

egg 与 koa

egg 底层用了 koa,从开发体验上来说,有种求同存异的感觉,因为 koa 是自己一个个包找来的,所以我仿佛从 0 开始知道了为什么世界这么转,而封装好的世界就没有这种快感,同时,它扩展了一些概念:service / model / middleware / controller 都会进行自动注册,在 koa 的世界里,你可能需要自己写一段代码来实现自动注册。

此外,在 koa 的基础上,它免于了一些选择困难症,也就是说,只要开启它的插件,你就遵守 egg 的规定就可以了。

当然,这种时候也带来了另一种纠结,这类企业开发的框架规定了一种开发的标准语法和规范,你没法按照自己喜欢的方式来,只能遵守它的规定,没有 koa 那种爱怎么写怎么写的自由感——不过从另一个角度来看,可能是为了长期维护的可行性做出的牺牲。

配置

和我们平时用的配置库差不多,都是根据 env 区分文件名,值得一提的是,单元测试时,环境变量为变更为 unittest,所以可以定制测试环境时的配置。如果没有找到的配置会降级到 config.default.js 中取寻找。

测试

如果我这篇文章只是简单的把官方文档压缩压缩再灌输给大家,大家肯定也读的不(hen)开心。主要想说的还是 egg 给我们在测试环节带来的便利。

测试时往往我会思考以下问题:测些什么,mock 些什么,选择啥库,这三个问题往往会阻碍我行进的步伐,尤其是 mock 步骤太多的时候——SSO 要不要 mock,某些服务要不要 mock。调用了其他外部服务要不要 mock。这样一来一去可能就更不想测试了。

在 egg 中封装好的 Service 或者是 context 的属性是可以直接 mock 配置的,使得整个过程非常的流畅,流畅的另一个原因当然是不用想如同「今天吃什么」一样的问题——「今天挑什么库用」。

文档

剩下的就是 koa 和 egg 的文档了,koa 概念很少,基本是用到什么查什么就行了,而 egg 相比之下引入的新概念和内置的 API 就比较多了,按照我们的尿性,字太长不看,很有可能会错过什么,这里已经把某些我曾经错过的部分抽出来介绍了(逃)。

在 egg API 文档的阅读时,请记住,如果写着 the same as 或者 alias,请到指定位置查看接口信息;点击源代码也可能有意外之喜。

总之

如果你期待被规范,egg 还是一个值得选择的框架,于此同时,也可以定制自己的 egg 版本,封装一些常用 Service 给自己用,不过另一方面,由于封装的太齐全,我也遇到了:egg 是照着这个来的 -> 点击进入这个东西的文档 -> 这一部分请看这个文档 -> 又进入了另一个文档的深层窘境,这种深化带来的问题是,出了 Bug,如果定位到不是你——接下来甩锅给谁好呢?

总的来说,虽然有些蛋疼,还不算太惨不忍睹,某些场景下还是比较棒的。

植入部分

如果您觉得文章不错,可以通过赞助支持我。

如果您不希望打赏,也可以通过关闭广告屏蔽插件的形式帮助网站运作。

标签: 知识, node.js

已有 2 条评论

  1. 开发者头条

    感谢分享!已推荐到《开发者头条》:https://toutiao.io/posts/9sdmn4 欢迎点赞支持!
    使用开发者头条 App 搜索 77790 即可订阅《全栈大道宽又长》

  2. a

    有觉悟,手动赞一个

添加新评论