RFC: Our PR on extending Node's shared library interface

[Maximilian]

Hi everyone,

TL;DR: We created a pull request to allow an easier and more flexible development experience when embedding Node.js into C++ applications by giving more control to the application developer while staying backwards compatible with the existing interface (node::Start(argc, argv), etc.). We would love to hear your feedback.

Motivation

As a C++ application developer, it can sometimes be hard to find maintained libraries with appropriate licenses. Furthermore, it can be relatively difficult to integrate C++ libraries into projects. In order to unlock the full potential of the NPM package ecosystem for C++ applications, we embedded Node.js as a shared library. We wanted to build a Qt based C++ application using NPM packages for data retrieval. However, we ran into various difficulties during the development process, such as:

• sparse documentation
• low controlability
  • event loop blocks calling thread, once Node.js is started
  • parameters (e.g. for Start(argc, argv)) are difficult to construct

Thus, we tried to improve the usability of Node.js as a shared library.

Flexible event loop

We wanted to give the user full control over the behavior of the Node.js event loop. Although the initial implementation allowed the user to start the event loop with just one call, we missed the possibility to also stop and resume the loop at will. Therefore, we introduced two different ways for the user to interact with the event processing in Node.js: The user might just (1) let Node.js take care of the event loop. This interaction is very close to the initial behavior, since the node::RunEventLoop(callback) blocks the calling thread until all events are processed. However, the user gains the possibility to react to changes by providing a callback, which is executed once per loop tick. The other way of controlling the event loop is by (2) executing single event loop ticks. By calling node::ProcessEvents(), Node.js processes events once and returns to the caller.

Be sure to check out our pull request on Github, including code examples.

What are your thoughts? Would you use such an interface? Is there something you would like us to change?