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

Updated Design: Runtime Editor Split (markdown)

Nick O'Leary 2018-03-19 14:43:05 +00:00
parent fd2c1bdf41
commit 5550cf4ece

@ -24,59 +24,97 @@ The plan is to break them up into their own discrete packages to provide some mo
## Use Cases ## Use Cases
### Headless ### Headless
<details>
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) - supports http endpoints (just doesn't have full editor capability)
</details>
### Multi-user, single-tenet runtimes ### Multi-user, single-tenet runtimes
<details>
- A single hosted instance of the editor is backed by multiple runtimes - one per user or group of users - A single hosted instance of the editor is backed by multiple runtimes - one per user or group of users
- The user access the editor and the underlying api requests are proxied to the appropriate runtime - The user access the editor and the underlying api requests are proxied to the appropriate runtime
- Authentication is handled at the proxy layer - Authentication is handled at the proxy layer
- API requests can be proxied unmodified (other than auth tokens) - API requests can be proxied unmodified (other than auth tokens)
</details>
### Multi-user, multi-tenet runtimes ### Multi-user, multi-tenet runtimes
<details>
- A single hosted instance of the editor is backed by multiple runtimes. - A single hosted instance of the editor is backed by multiple runtimes.
- The user access the editor and the underlying api requests are proxied to the appropriate runtime. - The user access the editor and the underlying api requests are proxied to the appropriate runtime.
- 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 </details>
### Scaled
<details>
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.
- 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 - Serves up the editor without a local version of the runtime
### Distributed </details>
### Distributed
<details>
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.
- 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 - Serves up the editor without a local version of the runtime
</details>
### Repurposed Editor ### Repurposed Editor
<details>
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.
</details>
---
## Packaging ## Packaging
At the top level, we'll have N 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/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/editor` - the editor component
- `node-red` - the existing package that pulls the above packages together and delivers *exactly* the same experience as it does today - `node-red` - the existing package that pulls the above packages together and delivers *exactly* the same experience as it does today
### node-red-core-runtime ### @node-red/runtime
### node-red-core-nodes ### @node-red/core-nodes
### node-red-core-editor Moving the core nodes into their own repository poses some challenges in how they get loaded.
#### Current core node load mechanism
1. In the current code, the runtime starts at the path identified by `settings.coreNodesDir` and scans for js/html file pairs. `coreNodesDir` defaults to the `nodes` directory of the node-red module. It also walks up the tree from this directory looking for `node_modules` directories to scan.
2. The scan of the core nodes happens before the scan for node modules - so the core nodes are guaranteed to appear first in the palette.
3. The files are loaded as part of the `node-red` module namespace and there are various hardcoded shortcuts taken with the `node-red` namespace.
4. A single message catalog is registered that covers all core nodes - rather than one-per node-set as is the requirement for nodes loaded from modules.
#### Changes needed
1. have a mechanism to prioritise loading of `@node-red/core-nodes` to ensure node ordering
2. handle the migration case where `node-red` disappears from the list of nodes - if the auto-reinstall option is enabled (such as in IBM Cloud), we really don't want this to trigger a re-install as we know the nodes are being provided elsewhere
3. Either:
1. split up the message catalog to match the current file name scheme required of modules
2. allow a node module to declare a single message catalog that is loaded for all nodes in the module
4. Many nodes expect their message catalog namespace to be `node-red`. Need to either handle this as a special case, or update all the nodes to the correct catalog. Even then, there are 3rd party nodes that will be using `node-red:common.*` messages that must not change.
### @node-red/editor
### node-red ### node-red