Startup

EggBornJS新增了Startup机制，允许在系统启动时执行初始化工作

Startup的开发机制与Schedule类似

声明Startup

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

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

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

  return config;
};

名称	说明
type	all/worker
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;
};

声明Startup

声明API路由

添加控制器方法

评论: