From 5550cf4eced22e83773d53f8198096a43b8d5a66 Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Mon, 19 Mar 2018 14:43:05 +0000 Subject: [PATCH] Updated Design: Runtime Editor Split (markdown) --- Design:-Runtime-Editor-Split.md | 60 +++++++++++++++++++++++++++------ 1 file changed, 49 insertions(+), 11 deletions(-) diff --git a/Design:-Runtime-Editor-Split.md b/Design:-Runtime-Editor-Split.md index 2661bad..9ae5ceb 100644 --- a/Design:-Runtime-Editor-Split.md +++ b/Design:-Runtime-Editor-Split.md @@ -24,59 +24,97 @@ The plan is to break them up into their own discrete packages to provide some mo ## Use Cases ### Headless - +
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 - supports http endpoints (just doesn't have full editor capability) +
+ ### Multi-user, single-tenet runtimes +
- 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 - Authentication is handled at the proxy layer - API requests can be proxied unmodified (other than auth tokens) +
+ ### Multi-user, multi-tenet 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. - 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. -### Scaled +
+### Scaled +
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 -### Distributed +
+### Distributed +
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 - Serves up the editor without a local version of the runtime - +
### Repurposed Editor - +
The Node-RED editor is used for another system entirely that shares the same node/wire visualisation. +
+ +--- ## Packaging 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-nodes` - the default set of nodes in the palette - - `node-red-core-editor` - the editor component + - `@node-red/runtime` - the core runtime of Node-RED + - `@node-red/core-nodes` - the default set of nodes in the palette + - `@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-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