Brainstorm session: core is too big
This is the summary of a brainstorm session that happened during the last AwesomePaaS CodeCamp.
What’s the matter
The Awesome team is aware that the current project organization, that is a monolithic repository with all components in a unique place is not scalable. In this brainstorm session we discussed the goals of a modular system, we looked at how others do it, our requirements, we finished by an open discussion.
Why do we need modules ?
We identified 4 main reasons to switch to a modular setup. 2 reasons are for our own interest. The first one is of course to ease the application modularity, which bring us clear separation of concerns between modules, make dependencies apparent, and allow us to grow more quickly and safely. The second one is that splitting the system in smaller chunks brings self contained features, and huge gain in the time needed to run the tests.
The other 2 reasons are more for the community. It’s clear that a modular structure ease the contributions, and can help us to clear the path between core features and optional ones.
What is a module, and what should a module be able to do ?
A module is a part of the application. It brings new features, be it server-side, client-side, or both.
A module can:
- provide libraries to other modules
- add API (REST endpoints) to the web server
- enhance the websocket server: it should be able to communicate from client to server through the websocket system
- bring browser components: images, css files, templates, javascript files
- use librairies provided by other modules
How others do ?
grunt
Grunt is a well known modular system. It uses imperative dependency injection: any module (grunt task) receive the grunt object to plug into
meteor
Meteor uses a complex module system, but the main mechanism is declarative dependency injection. A module uses some methods (use, imply, add_files) to give the module system what are the requirements, and the different parts of the module. Eg:
api.use(['deps', 'service-configuration', 'accounts-base',
'underscore', 'templating', 'session'], 'client');
api.imply('accounts-base', ['client', 'server']);
api.use('accounts-oauth', {weak: true});
api.add_files([
'accounts_ui.js',
‘other.js’
]);
express
The express framework uses imperative dependency injection. One way or another, you end up with having the application instance, where you can use methods to register your middlewares:
app.use(someMiddleware);
app.param('param', paramCallback);
Open discussion
Many interesting points were raised during the open discussion. Here are the main points:
- Do you know the architect ?
Architect is a node module system. It didn’t fals under the radar during the preparation of the session, but it’s of course an interesting project to look into when on the implementation phase
- OMG, security ?
Do we need to find some kind of sandbox system, so we can be sure a module can’t fsck up all the platform ? The global consensus of this discussion seems to be that modules are installed by administrators, and that they can do anything. To ease the collaboration with other systems in a more secure fashion, the good way is to provide an OAuth provider interface.
- How do we ensure that modules are setup on all nodejs nodes of the cluster ?
In the case modules can be deployed through a web interface, ala appstore, how do we ensure the module is deployed on all instances of the nodejs servers ? The question is still opened, and the answer is perhaps by leveraging the deployment facility.
Brainstorm session: related works on authorization mechanisms for Node.js Brainstorming session: XMPP integration into real time web application
