frodovdr
/
node-red
mirror of https://github.com/node-red/node-red.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Alternate node structure proposal

Jeff Eiden 2018-04-13 10:29:28 -07:00
parent 89b282a8f5
commit 2b71cc704a
1 changed files with 14 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
Design:-Runtime-Editor-Split.md

@ -136,4 +136,18 @@ In our past discussion, a runtime needs to receive the information from editor a
We may also need to consider the case that both runtime and editor authenticate with different servers.
(MAB) - started a test project to demonstrate how to use npm install <folder> (npm 5.x) to set up symlinks in a mono-repo during development. https://github.com/mblackstock/test-project. Normal `npm install` uses published npm packages. If you run the devInstall script, it sets up the symlinks to the local code in the repo. More info in the README.
(JME) - I'd like to propose a slightly different structure of the npm packages for the editor/runtime split per ideas from @townlyn. We've discussed this lightly in calls but want to document here.
The current proposal in this design doc is to have 4 nodes: `runtime`, `core-nodes`, `editor`, and `node-red`.
We've been having discussions at Particle around the idea of seeing this split as 5 packages: `runtime`, `admin-api`, `core-nodes`, `editor`, and `node-red`. This is because you can think about what currently is bundled together as the "runtime" as 2 separate things:
- The application that actually processes messages and runs flows, ongoing, in real time
- The admin API that allows for managing node and flow configuration
At Particle, we would likely want to run the message processing using _separate_ infrastructure than the admin API. The message-processing runtime should (be able to) run as a separate process, with some form of IPC between the runtime and the admin API. This would provide more flexibility in how one could deploy Node-RED, as well as create more control over scaling the different parts of the system.
We currently follow a similar pattern for our [webhooks system](https://docs.particle.io/guide/tools-and-features/webhooks/). Our REST API is a standalone app that allows for CRUD of webhooks. Separately we have a webhooks service that is responsible for actually queuing, sending and receiving the HTTP requests. The API and the webhooks service can communicate with one another, but functionally carry out distinct and separate responsibilities. This has served us very well in managing these two systems as their nature requires optimizing for different things in infrastructure-land (i.e. load-balancing inbound, synchronous requests to an API is quite different to managing queues of work in the background).
What would y'all think of this proposal?
</details>