Benefits of Modularization

In the large-scale web business system, it is inevitable to include a large number of businesses and functions. The adoption of modularization for system development will bring the following advantages:

  1. Clear code structure and fully decoupled logic
  2. Easy for team development
  3. Convenient to deposit technical assets and reuse them in different systems
  4. Easy to compile separately and protect business intellectual property
  5. Easy code version management and seamless upgrade

Naming Convention

In order to increase the business modules continuously and achieve a highly reusable effect, the namespace of all modules must be fully isolated, to avoid mutual pollution and conflict. Thus the naming convention is as follows:

Name Description
providerId It is strongly recommended to use the Username of GitHub as the Provider ID, so as to ensure that the modules contributed to the community will not conflict
moduleName module name

Based on this naming convention, module-related resources are referenced at the frontend and backend as follows:

Module egg-born-module-test-party as example:

Name Description
providerId test
moduleName party
fullName egg-born-module-test-party
relativeName test-party
frontend page route url /test/party/{page}
backend api route url /test/party/{controller}/{action}

Module Namespace Isolation

In order to adapt to the scenario of large-scale business development and avoid variable pollution and conflict between modules, the framework implements a module namespace isolation mechanism for both the frontend and the backend, including the frontend components, frontend configuration, backend logic, backend routing, backend configuration and other elements of the module (see the following chapters of module development)

Module Type

There are two types of modules in EggBornJS: Public Module, Private Module

Name Description
Public Module path: {project}/node_modules
Private Module path: {project}/src/module

Loading Mechanism

Backend Loading

EggBornJS implements a custom loader based on EggJS. When the system is started, all modules are loaded synchronously at one time, and the upgrade logic of module data version is automatically determined and completed

Frontend Loading

The module frontend supports both asynchronous loading and synchronous loading

Generally, the default is asynchronous loading

If you want to change it into synchronous loading, just add -sync suffix behind the module name, such as the module egg-born-module-a-components-sync

Create a module

If want to create a new module named as test-party, enter the project path and run the scaffold command:

$ cd /path/to/project
$ npm init cabloy src/module/test-party --type=module-business

Two module templates are currently available:

Name Description
module-business this template creates business-related code that greatly simplifies the workload
module this template contains only the basic skeleton code files

Module Dependencies

Manage module dependencies through the module’s file package.json

For example, module aa-module1 depends on aa-module2. Need to make the following configuration in the file package.json of module aa-module1

  "name": "egg-born-module-aa-module1",
  "version": "0.0.1",
  "eggBornModule": {
    "dependencies": {
      "aa-module2": "0.0.1"
  "dependencies": {
    "egg-born-module-aa-module2": "^0.0.1"
Name Description
“aa-module2”: “0.0.1” This declaration ensures the loading order between dependent modules
“egg-born-module-aa-module2”: “^0.0.1” This declaration ensures that module aa-module2 will be installed automatically when module aa-module1 is installed