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)
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.
|
Loading…
Reference in New Issue
Block a user