FEATURE: nanoservice injection

[dmerkushov]

Problems solved by the feature

• Boilerplate code when creating a new nanoservice project
• Even more boilerplate when creating nanoservices using languages other than C/C++
• Incompatibility of nanoservice APIs written in different languages
• Potentially incompatible implementations of nanoservices known for Python and JavaScript (EcmaScript)
• Complexity of nanoservices framework testing

Describe the solution you'd like C/C++: A nanoservice must NOT be an executable, but must be a shared object (.so) library having several predefined methods (such as initialize(), processRequest(), finalize(), etc). A globalized runner for C/C++, provided as part of the nanoservices framework, loads the shared object and calls its methods whenever the service is invoked. Other languages: A nanoservice is arranged as a library. The library is specific to the language the nanoservice is written in. A globalized runner for that language loads that library, and so on. Anyway, the core functionality of the framework (service publishing, interaction with other services) remains in a single .so that is loaded by all those runners.

Support for the following minimum of languages is required (in order of precedence): C/C++11, Golang >=1.13, Python >=2.7, EcmaScript 6 (maybe TypeScript), Java >=1.6, Rust >=1.40.0

The feature implementation must NOT break existing nanoservices that do not use a global runner and run by themselves.

Feature optionality The feature must be available to whichever nanoservice needs it. Nanoservice development without using injection must be available, too.

Using nanoservice injection is planned to be the recommended practice of nanoservice development.

[dmerkushov]

Priorities:

Bushmin: C Petelin: B Merkushov: B

[v-bus]

Предлагаю тестить MQProxy, он на питоне. К нему тестилка есть на питоне. @a-petelin он же на питоне?