frodovdr
/
node-red
mirror of https://github.com/node-red/node-red.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Updated Design: Runtime extension points (markdown)

TJKoury 2015-05-12 06:51:58 -04:00
parent 4876fe9724
commit 05b18a024b
1 changed files with 9 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Design:-Runtime-extension-points.md

@ -22,15 +22,17 @@ 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 as defined by the flow
### Running different flows for different users
This is the case where different users have access to different node red instances/run times on a single multi-core server or cluster. To do this may require a suitable UI to manage users and instances, a way to broker communications to instances for administration (flow deployment, debugging) and access to flow inputs (e.g. HTTP, web sockets, others) based on user identity and credentials.
- be able to route messages between the instances are defined by the flow
## Extension Points
- Storage layer - how/where things get stored - [already done](http://nodered.org/docs/api/storage/index.html).
- 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
- 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](https://github.com/node-red/node-red/issues/567). 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.
- Context backing - we intend to make [context more widely used](https://github.com/node-red/node-red/issues/567). 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