frodovdr/node-red
1
0
Fork 0
mirror of https://github.com/node-red/node-red.git synced 2023-10-10 13:36:53 +02:00
Code Issues Releases Wiki Activity

Added "scaled" use case - and discussion section

Dave Conway-Jones 2018-03-01 11:06:13 +00:00
parent 4855b22fec
commit c574976c32
1 changed files with 16 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Design:-Runtime-Editor-Split.md

@ -9,20 +9,27 @@ The plan is to break them up into their own discrete packages that can be used s
A device that runs a flow it is given. The flow is edited elsewhere and remotely pushed to the device (or hardcoded on the device). A device that runs a flow it is given. The flow is edited elsewhere and remotely pushed to the device (or hardcoded on the device).
- don't want the overhead of the editor that isn't going to be used - don't want the overhead of the editor that isn't going to be used
- supports http endpoints (just doesn't have full editor capability)
### Distributed Node-RED ### Distributed Node-RED
A node-red flow is edited in one place. When deployed, it gets carved up and different parts are pushed to different runtimes, either local or remote. A node-red flow is edited in one place. When deployed, it gets carved up and different parts are pushed to different runtimes, either local or remote.
- Serves up the editor without a local version of the runtime
- Custom actions are added behind the deploy action - Custom actions are added behind the deploy action
- Serves up the editor without a local version of the runtime
### Scaled Node-RED
A node-red flow is edited in one place. When deployed, it gets sent to multiple runtimes to provide horizontal scaling.
- Custom actions are added behind the deploy action
- Serves up the editor without a local version of the runtime
### Node-RED Editor ### Node-RED Editor
The Node-RED editor is used for another system entirely that shares the same node/wire visualisation. The Node-RED editor is used for another system entirely that shares the same node/wire visualisation.
## How we're going to do it (to be revisited)
## How we're going to do it
At the top level, we'll have four npm packages (names tbc) At the top level, we'll have four npm packages (names tbc)
@ -33,3 +40,9 @@ At the top level, we'll have four npm packages (names tbc)
This is an open question as to whether the git repository should also be split into four along the same lines, or if the release build process would create the four modules from the one repo. There are pros/cons to both. This is an open question as to whether the git repository should also be split into four along the same lines, or if the release build process would create the four modules from the one repo. There are pros/cons to both.
## Discussion
(DCJ) - One of the main items to think about are the UI changes. In the distributed case how is the partitioning of flows done? What attribute says where a particular node should be run? Is it an attribute of a node? Or a group of nodes? or a Tab/Flow? Or should the/a new link node be the thing that distinctly separates parts and holds "location" information for anything it connect to?
While distributed and scaled are similar, there is one possible distinction that should be highlighted. For the "simple" scaled case the entire flow is sent to multiple runtimes. Is this worth bringing out separately as this may not need any of these UI changes?