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

Updated Design: Runtime Editor Split (markdown)

Nick O'Leary 2018-03-08 11:28:36 +00:00
parent 3dc1e337e8
commit 201b71a23a
1 changed files with 24 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
Design:-Runtime-Editor-Split.md

@ -9,6 +9,13 @@ The plan is to break them up into their own discrete packages to provide some mo
- [Distributed](#distributed) - [Distributed](#distributed)
- [Scaled](#scaled) - [Scaled](#scaled)
- [Repurposed Editor](#repurposed-editor) - [Repurposed Editor](#repurposed-editor)
- [Packaging](#packaging)
- [node-red-core-runtime](#node-red-core-runtime)
- [node-red-core-nodes](#node-red-core-nodes)
- [node-red-core-editor](#node-red-core-editor)
- [node-red](#node-red)
- [Code structure](#code-structure)
## Use Cases ## Use Cases
@ -33,8 +40,6 @@ A device that runs a flow it is given. The flow is edited elsewhere and remotely
- Each runtime may host flows of different users that should not see each other - Each runtime may host flows of different users that should not see each other
- The proxy layer provides a filtered view of the flow to ensure the editor only displays information available to the logged in user. - The proxy layer provides a filtered view of the flow to ensure the editor only displays information available to the logged in user.
### Scaled ### Scaled
A node-red flow is edited in one place. When deployed, it gets sent to multiple runtimes to provide horizontal scaling. A node-red flow is edited in one place. When deployed, it gets sent to multiple runtimes to provide horizontal scaling.
@ -54,20 +59,33 @@ A node-red flow is edited in one place. When deployed, it gets carved up and dif
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) ## Packaging
At the top level, we'll have four npm packages (names tbc) At the top level, we'll have N npm packages (names tbc)
- `node-red-core-runtime` - the core runtime of Node-RED - `node-red-core-runtime` - the core runtime of Node-RED
- `node-red-core-nodes` - the default set of nodes in the palette - `node-red-core-nodes` - the default set of nodes in the palette
- `node-red-core-editor` - the editor component - `node-red-core-editor` - the editor component
- `node-red` - the existing package that pulls the above three together, shakes them around, plumbs them together and delivers *exactly* the same experience as it does today (well, hopefully an even better one...) - `node-red` - the existing package that pulls the above three together, shakes them around, plumbs them together and delivers *exactly* the same experience as it does today (well, hopefully an even better one...)
### node-red-core-runtime
### node-red-core-nodes
### node-red-core-editor
### node-red
## Code structure
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.
If we stick with a mono-repo, [lerna](https://lernajs.io/) could be used to manage it - needs some more investigation.
## Discussion ## Discussion
<details>
(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? (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? 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?
</details>