1
0
mirror of https://github.com/node-red/node-red.git synced 2023-10-10 13:36:53 +02:00

Updated Design: Runtime extension points (markdown)

Nick O'Leary 2015-05-11 21:56:16 +01:00
parent 5fecd81f64
commit f59d3f2462

@ -16,7 +16,7 @@ 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 on the same instance.
This is where a flow is distributed across multiple runtimes. Two connected nodes may not be running in the same instance.
The requirements are:
@ -27,4 +27,5 @@ The requirements are:
- 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
- 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.
- 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.