Design: Runtime extension points

(Original thread: https://groups.google.com/forum/#!topic/node-red/LFu_z85G3Fg)

There are a number of places in the node-red runtime where it would be desirable to plug-in alternative implementations, or provide hooks to add functionality. There are a number of use cases this would enable.

This page is an attempt to start organising these thoughts.

Use Cases

Running multiple instances of a flow

This is where the flows are designed such that multiple instances can be run with some sort of load balancing in front of them. This is suited to HTTP-initiated flows, with any shared state maintained via an external service such as Redis.

The requirement is to be able to trigger the deploy of flows across all instances.

This could be done in the existing storage-plugin layer.

Running a flow across multiple instances

This is where a flow is distributed across multiple runtimes. Two connected nodes may not be running in the same instance.

The requirements are:

• co-ordinate the deploy of the flow across multiple machines
• perform some processing on the flows as part of the deploy process
• be able to route messages between the instances are defined by the flow

Extension Points

• Storage layer - how/where things get stored - already done.
• Message routing - how a message gets routed. Default implementation does the in-memory direct access to a node's .receive function. Alternative implementations could serialise the message to JSON and send over the network.
• Flow handling - sits in the load/save path for flows. Need to refine how much is exposed to the API and where exactly it sits in the deploy process.
• Context backing - we intend to make context more widely used. As soon as a flow can run in multiple instances, the shared context needs to be truly shared. This extension point would allow a backing store to be plugged in - for example Redis. Even in the single-instance case, this would allow context to be persisted.

##Multi-Process Model

• Using the Cluster module, instantiate the master process within which runs the main server instance with the admin interface. The settings file defines how many processes to spawn, with a 'max' argument spinning up one process per logical core. The master process listens for child death and respawns a set number of times as configured in the settings file.
• Communication between the cluster master and child processes is handled by passing serialized JSON messages. All messages are defined by originating node id designation, and multi-process enabled nodes listen to the message event from the cluster master on the local cluster and call the 'send' method on the enabled node, activating the flow at that point.
• Individual nodes that are multi-process enabled have a drop-down to define multi-process behavior
  • Node can receive a message from the identical node on another process/machine and execute flow as if request originated with that node, by listening to the process 'message' event.
  • Node can debounce request based on timed input (ws heartbeat, timer input), making sure that at least one or no more than one signal is processed during the timer duration
  • Node can debounce request based on external event (file system change, system state change) with a minimum debounce interval (e.g., disregard all messages from node with id 814577ba.7eba88 and payload /tmp/test.txt within 50 ms of the last message meeting those criterion)