Modular core

Some basic concepts behind a modular meanio core will be described here:

Modular core

Modular core is, in fact, the very Meanio function itself. An instance of Meanio will be the very mean.io server. That instance is returned from

require('meanio');

These are the tasks of the modular core:

1. Provide a mechanism for singleton operation
2. Provide a mechanism for registering dependencies.
3. require all core modules.
4. Provide a mechanism for core modules to register themselves for one special event - the instantiation "event" (onInstance "event").

Each of these tasks will be dicussed in more detail.

Singleton operation

There may be only one instance of Meanio. This is achieved in the Meanio constructor, by setting a global property Singleton of the Meanio function to this.

Dependency handling

Meanio inherits from lazy-dependable; methods register, resolve and get are available on the Meanio.prototype. lazy-dependable is an in-place replacement for dependable, with two crucial improvements:

1. Dependencies are resolved in a "lazy" manner. One is free to ask for resolution of a dependency even if the dependency is still not registered. The handler for the not-yet-registered dependency is put on a waiting queue, and will be triggered when the dependency is registered.
2. Dependencies and dependency handlers need not be declared in the form function(database, auth){...} because this declaration method is clumsy (does not allow for a single handler to handle different dependencies) and severely sub-optimal (because the handler function need to be stringified and the resulting string parsed in order to read the names of formal parameters). The preferred way of asking for a dependency now is 'database','auth',function(database,auth){...}.

Requiring core modules

Each core module will be required. Because of that, the index entry file of the core module has to export a single entry function that will be called during core module initialization. The exported function will be passed the very Meanio function. Thereby, the core module is given a freedom to

1. extend the Meanio function (introduce new static methods of the Meanio class)
2. extend the Meanio.prototype (introduce new methods of the Meanio instance).
3. register an onInstance "event handler" (see [onInstance])

onInstance "event"

The onInstance is not a real event, because a real event imposes no constraints on event handlers. However, the onInstance event handlers will be passed two parameters:

1. the Meanio instance being created
2. a q defer that a handler needs to eventually resolve.

It is important to note that a Meanio server will not be started until all the onInstance handlers resolve the defers they were given.

Benefits of the modular design

Bilateral communication

Each modular core is given a way to bilaterally communicate to other core modules.

1. Core => Core module Core initiates the communication by calling the Core module's entry function (some frameworks call this entry function a hook) giving the Core module full control by passing the Meanio function.
2. Core module => Core Core module modifies the Meanio function and creates possibilities to all other elements of the mean.io framework to ask for services from the Core module throughout the lifecycle of the Meanio instance.

Abstraction layers

Since a Core module's job might turn out to be complex and layered, it proves beneficial for a Core module to further "layerize" the services it offers. Here is where a concept of Abstraction layers comes in handy.