No chance for the service developer to plug in into any moment of the nanoservices framework except for the processing of the request.
Some plugin ideas:
service firewall, allowing or disallowing access to the service based on the connection information
special logging/monitoring connectors allowing for connecting with certain frameworks
Description of the proposed solution
In general, the idea is the same as for #10:
A plugin is a Linux shared object populating several functions, one for every ablilty that this plugin implements.
An ability itself is a predefined name for its triggering event(s), input and output data. All plugins populating the same ability are queued and called one by one as soon as the triggering event happens. The plugins themselves are allowed to define abilities, too, so other plugins could bind to their triggering events.
Plugins used for a nanoservice are listed in its configuration. The plugin queue for every triggering event is ordered according to the configuration order.
Plugins can depend on each other. Every dependency must be listed in the service configuration BEFORE the dependant.
The framework should have special populated functions to:
list currently initialized plugins (their names, versions)
list plugins allowing for the given ability, by its triggering event name
trigger an event
Plugins should have special functions for:
plugin name
plugin version
check for dependencies
initialization
finalization
list of abilities
The plugins are loaded in order of the configuration, one by one. For every plugin found in the service configuration, the framework loads it in the following order:
Check for plugin dependencies. If not successful, continue with the next plugin
Initialize using the plugin's initialization function
Register the plugin:
3.1. Add the plugin abilities functions to the end of the queues for the abilities that were listed by the plugin
3.2. Add the plugin's name and version to the plugin list for the future-initialized plugins to be able to find it
Plugins are unloaded in reverse order of the configuration, using their finalization functions.
Impact on nanoservice development
The service developer is allowed to write plugins that will ease the treatment of special cases of nanoservice development, such as generalization of specific functionality.
Plugging in and out some functions simplifies nanoservice testing in separate environments.
Feature optionality
The feature is not mandatory to use by the developer, but possible.
dmerkushov
commented
4 years ago
The proposed feature is a generalization of #10 .
Problem solved by the feature
No chance for the service developer to plug in into any moment of the nanoservices framework except for the processing of the request.
Some plugin ideas:
Description of the proposed solution
In general, the idea is the same as for #10:
A plugin is a Linux shared object populating several functions, one for every ablilty that this plugin implements.
An ability itself is a predefined name for its triggering event(s), input and output data. All plugins populating the same ability are queued and called one by one as soon as the triggering event happens. The plugins themselves are allowed to define abilities, too, so other plugins could bind to their triggering events.
Plugins used for a nanoservice are listed in its configuration. The plugin queue for every triggering event is ordered according to the configuration order.
Plugins can depend on each other. Every dependency must be listed in the service configuration BEFORE the dependant.
The framework should have special populated functions to:
Plugins should have special functions for:
The plugins are loaded in order of the configuration, one by one. For every plugin found in the service configuration, the framework loads it in the following order:
Plugins are unloaded in reverse order of the configuration, using their finalization functions.
Impact on nanoservice development
The service developer is allowed to write plugins that will ease the treatment of special cases of nanoservice development, such as generalization of specific functionality.
Plugging in and out some functions simplifies nanoservice testing in separate environments.
Feature optionality
The feature is not mandatory to use by the developer, but possible.