技术 - EggJS 渐进式开发 - 《咦，有只猪在天上飞~》

前言
应用
插件
框架
写在最后

前言

本文将详细介绍一个 EggJS 应用的演进过程，以及如何让我们的代码是有生命力的。

应用内的一段逻辑 → 在应用内孵化插件雏形 → 独立插件 → 内置到自定义框架

应用

先通过一个简单的演示，快速了解下 EggJS 的应用开发侧体感是怎么样的。

我们要实现一个简单的聚合接口，根据请求参数传递的 org 查询对应的 GitHub 组织的仓库列表。

初始化

先通过脚手架来初始化：

$ npm init egg --type=simple showcase
./showcase
├── app
│   ├── controller (控制器)
│   │   └── home.js
│   ├── serivce （业务逻辑）
│   │   └── github.js
│   └── router.js （路由）
├── config （配置）
│   ├── config.default.js
│   ├── config.prod.js
│   └── plugin.js
├── test （单测）
├── README.md
└── package.json

路由及控制器

编写 Controller 控制器逻辑：

// app/controller/home.js
const { Controller } = require('egg');
class HomeController extends Controller {
  async listReposByOrg() {
    // 获取请求参数
    const org = this.ctx.query.org || 'eggjs';
    // 调用业务逻辑
    const result = await this.ctx.service.github.listReposByOrg(org);
    // 渲染数据
    this.ctx.body = result;
  }
}
module.exports = HomeController;

编写路由映射：

// app/router.js
module.exports = app => {
  // 注册路由
  app.router.get('/api/repos', app.controller.home.listReposByOrg);
}

业务逻辑

编写 Service 业务逻辑：

// app/service/github.js
const { Service } = require('egg');
class GithubService extends Service {
  async listReposByOrg(org) {
    const { ctx, config } = this;
    // 读取配置
    const { endpoint, pageCount } = config.github;
    // 请求后端 API
    const repos = await ctx.curl(`${endpoint}/orgs/${org}/repos`, {
      data: { per_page: pageCount },
      dataType: 'json',
    });
    // 响应数据
    if (repos.status !== 200) return [];
    return repos.data.reduce((arr, repo) => {
      arr.push(repo.name);
      return arr;
    }, []);
  }
}
module.exports = GithubService;

配置文件

编写配置文件，这里我们有 2 个文件，一个是默认值，一个是正式环境的配置，会根据运行环境自动合并。

// config/config.default.js
exports.github = {
  endpoint: 'https://api.github.com',
  pageCount: 5, 
};
// config/config.prod.js
exports.github = {
  pageCount: 50, // 配置自动合并，线上环境
};

运行效果

一般业务开发还要有对应的单元测试，非常重要，在 EggJS 里面写起来也非常的简单没有负担。不过限于篇幅，本文暂时跳过，直接运行来体验。

$ npm run dev
[master] egg started on http://127.0.0.1:7001 (2216ms)
$ curl localhost:7001/api/repos
["eslint-config-egg","egg","egg-bin","egg-mock","egg-logger"]
$ curl localhost:7001/api/repos\?org=vuejs
["vue","vue-router","vuejs.org","vue-touch","Discussion"]

小结

我们实现了一个典型的 BFF 聚合场景：解析请求参数 → 调用后端 API → 响应数据。
典型的 MVC 目录规范，Rails-like 的研发体验。
内置的多环境配置能力、日志能力、错误处理能力、常见的 Web 能力等等。
注意：这是一个使用 EggJS 的上层框架来开发一个业务应用的体验。

插件

插件是什么？

Middleware 的局限性：

定位是拦截用户请求，并在它前后做一些事情。
但实际情况下，很多功能与请求无关，如定时任务，初始化，Application 扩展。
功能之间的顺序不能简单的交给开发者，需要统一编排，管理。

Egg 插件：

插件是 Egg 的核心能力之一，是围绕某个功能组织的扩展集合，它跟应用的目录结构几乎一样。
插件是能力沉淀的有效手段，让你团队的应用生态可以持续进化，它也是差异化的基础。

使用插件

回到我们的示例应用，我们希望把查询结果渲染成页面，此时则需要模板渲染能力。

先挑选插件并安装：

$ npm i --save egg-view-nunjucks

挂载插件以及配置：

// config/plugin.js
exports.nunjucks = {
  enable: true,
  package: 'egg-view-nunjucks',
};
// config/config.default.js
exports.view = {
  defaultViewEngine: 'nunjucks',
  mapping: {
    '.tpl': 'nunjucks',
  },
};

修改控制器逻辑：

class HomeController extends Controller {
  async listReposByOrg() {
    const org = this.ctx.query.org || 'eggjs';
    const result = await this.ctx.service.github.listReposByOrg(org);
    // 渲染模板
    await this.ctx.render('repos.tpl', { org, result });
  }
}

编写模板：

<!-- app/view/repos.tpl -->
<h1>{{ org }}</h1>
<ul>
{% for item in result %}
  <li>{{ item }}</li>
{% endfor %}
</ul>

打开浏览器访问，完美。

渐进式开发 - 插件雏形

在 EggJS 里面，我们有一套渐进式的演进模式： 可复用代码片段 → 应用内部的插件雏形 → 独立插件 → 下沉到框架。

接着我们上面的 showcase，我们很容易意识到 GitHub 相关逻辑是可以复用的。

第一步我们把这部分的代码挪个窝，以便孵化：

$ ls
├── app
│   ├── controller
│   └── router.js
├── config
│   ├── config.default.js
│   └── plugin.js （插件配置）
│
├── plugin
│   └── egg-github （孵化插件）
│
├── test
├── README.md
└── package.json
$ ls ./plugin/egg-github
├── app
│   └── serivce
│       └── github.js
├── config
│   ├── config.default.js
│   └── config.prod.js
├── test
├── README.md
└── package.json

如上，我们把 GitHub 相关的 Service 和 Config 挪到了一个独立目录。

然后再修改下应用的插件配置，通过相对路径来挂载插件：

// config/plugin.js
exports.github = {
  enable: true,
  path: path.join(__dirname, '../plugin/egg-github'),
};

渐进式开发 - 独立插件

再迭代一段时间后，我们发现这个插件已经具备了基础的功能，此时就可以把它独立出来，让其他应用也能试用：

把 plugin/egg-github 目录剪切出去，独立发布为一个 npm 包。
应用安装对应的 npm 依赖。
修改应用的插件配置，挂载该 npm 插件。

$ npm i --save egg-github
$ more config/plugin.js
exports.github = {
  enable: true,
  package: 'egg-github',
};

小结

应用侧也可以编写对应的 config 来覆盖插件提供的配置值。
通过观察上面的操作，我们看到了一个插件的孵化之旅。
可以发现，整个演进过程，对应用来说，几乎是无痛的，仅仅是一两行配置的变化。

框架

框架是什么？

当你的团队所维护的应用数超过一定数量时，你是否会遇到：

每新建一个应用，都需要重复折腾插件和默认配置，而脚手架只能解决首次初始化问题。
修改一个默认配置后，希望所有应用都能更新。
希望给所有应用都新增一个插件。

Egg 的另一个核心能力就是上层框架机制，也是 Egg 的初心：帮助架构师孵化出适合特定团队业务场景的上层框架。

框架是对适合特定业务场景的最佳实践的约束和封装。
便于统一团队的开发模式，一致的开发体验，一次性学习成本，也便于统一管控、升级、维护。
支持多层继承。

渐进式开发 - 自定义框架

继续我们的渐进式之旅，当我们沉淀出几个插件后，可以考虑把它们抽离出来，封装为一个上层框架，这里就叫它 yadan 吧。

框架跟应用的目录结构也几乎一样，并支持多层继承。
应用逻辑下沉到框架，几乎无痛。

EggJS 渐进式开发 - 图1

渐进式开发 - 自定义规范

除了常规的扩展外，在实际业务开发中，我们往往需要为团队定制一些新的目录规范。

譬如我们想增加一个约定：所有放置在 app/utils 目录下的文件，都会被自动挂载为 app.utils.*。

非常简单，只需一个配置：

// config/config.default.js
exports.customLoader = {
  utils: {
    directory: 'app/utils',
    inject: 'app',
  },
};

差异化定制

类似于云原生里面的 no-vender-lock 机制，在不同场景下，底层的实现可能不一样，但我们希望在应用层的用法规范是一致的。

譬如：

模板渲染可以是 nunjucks 或 ejs，但应用层只需知道 ctx.render()，如 egg-view-nunjucks 和 egg-view-ejs 都是基于 egg-view 规范。
用户模型不一样，但用法都类似只需 ctx.user，如 egg-passport-* 系列插件。

我们可以在框架里面集成特定的插件，来实现针对特定团队场景的约定的差异化定制，又能减少用户的理解成本。

小结

详细操作也可以参见《如何为团队定制自己的 Node.js 框架？（基于 EggJS）》

以上是自定义框架的演进过程，可以发现，对应用来说，几乎是无痛的，仅仅是一两行配置的变化。

每个企业内部，应该有一层面向企业开发者的 EggJS 上层框架，哪怕它很薄，那也是有价值的。

在阿里内部，我们甚至还有多层：

EggJS 渐进式开发 - 图2

写在最后

以上就是基于 EggJS 的完整的渐进式开发：

应用内的一段逻辑 → 在应用内孵化插件雏形 → 独立插件 → 内置到自定义框架

整个演进过程，对应用来说，几乎是无痛的，同时我们的逻辑是有生命力的，可以不断的低成本下沉，完成闭环。

再回顾下我们的选择：

🆘 课题：企业级大规模应用场景下，如何既能在尽可能共建和不重复造轮子的情况下，保证灵活的差异化定制，并可持续治理及维护？

✅ 我们的选择是：做框架的框架，EggJS 提供了一套 Loader 规范以及延伸出的插件和框架能力，期望能帮助前端架构师孵化出适合团队的业务场景的上层框架。

以上。