Table of contents
OpenPaaS modules (also called AwesomeModules) come on top of classic NPM modules, to provide an enterprise grade module system. The main improvements over the classic Node NPM system are:
- OpenPaaS modules brings dependencies, either by name, or by ability
- OpenPaaS modules supports asynchronous loading
- OpenPaaS modules got a lifecycle, and go through states during their initialization
OpenPaaS modules dependencies express, as we can expect, dependencies between modules. This dependency can be either by name, just like NPM, where you say “I’m dependant of the module example-logger version 2.0.0”, and also by ability : so you can say “I’m dependant of the logger ability”, and any module exposing this ability can be used. OpenPaaS modules use the well known dependency injection pattern, usefull to build extensible, and testable, systems.
During the startup of the NodeJS server, the modules are loaded. OpenPaaS provides three states. All states are optional: you don’t have to code them if you don’t need them.
This is the first step. Upon this step, your module should send back its library, that dependant modules (the modules that requires yours) will receive when they inject it. For example, a “user” module library will certainly expose a get() method, a create() method…
In this state, you can’t expect any of the underlying microservices to be ready. In particular, the MongoDB datastore, and pubsub systems, will not be ready at this point
The second step is deploy, which means that you should call here all the registration points that your module will use. This includes:
- the Express applications you add to the platform
- the LESS files
- the pub/sub events you register and subscribe to
In this last step, your module starts actually doing its stuff. For example, if your module should publish a message in the message queue, or if it should send an email on startup, that should be done in that step. Usually, that step is empty.