EggBornJS新增了Startup机制，允许在每个工作进程启动时执行初始化工作

声明Startup

src/module/test-party/backend/src/config/config.js

module.exports = appInfo => {
  const config = {};

  // startups
  config.startups = {
    startupAll: {
      path: 'test/feat/startup/all',
    },
    startupInstance: {
      instance: true,
      path: 'test/feat/startup/instance',
    },
  };  

  return config;
};
名称 说明
path 需要执行的后端API路由
instance 系统调用后端API路由时，是否需要向上下文环境注入实例信息

属性instance的本质是什么？

  • 前面我们提到EggBornJS支持多实例。由于Startup是由系统触发执行的，此时上下文环境是没有实例信息的
  • 如果instance设为false，那么后端API路由就需要自行处理与多实例相关的逻辑
  • 如果instance设为true，那么系统就会自动对多实例进行循环，依次调用后端API路由，并向上下文环境注入实例信息，从而简化后端API路由的开发工作量

声明API路由

src/module/test-party/backend/src/routes.js

// test/feat/startup
{ method: 'post', path: 'test/feat/startup/all', controller: testFeatStartup, middlewares: 'inner', meta: { instance: { enable: false } } },
{ method: 'post', path: 'test/feat/startup/instance', controller: testFeatStartup, middlewares: 'inner', meta: { auth: { enable: false } } },
名称 说明
middlewares 指定中间件inner，只允许内部调用
instance.enable 禁止全局中间件instance
auth.enable 禁止全局中间件auth

为何要禁止全局中间件auth?

  • 因为Schedule是由系统触发执行的，其上下文环境没有用户信息

为何不同时禁止全局中间件instance和auth？

  • 由于中间件auth依赖中间件instance，如果禁止中间件instance，那么中间件auth就会自动被禁止

添加控制器方法

src/module/test-party/backend/src/controller/test/feat/startup.js

const require3 = require('require3');
const assert = require3('assert');

module.exports = app => {

  class StartupController extends app.Controller {

    async all() {
      console.log('test/feat/startup: all');
      assert.equal(this.ctx.instance, undefined);
      this.ctx.success();
    }

    async instance() {
      console.log(`test/feat/startup: instance:${this.ctx.instance.id}`);
      assert(this.ctx.instance.id > 0);
      this.ctx.success();
    }

  }

  return StartupController;
};