internal architecture of Node-RED

Core Development
1

Hello
Where can I get acquainted with the internal architecture of Node-RED?
I'm interested in exactly how the nodred works under the hood, how flows work, maybe there is a scheme of work already described.

The issue of horizontal scaling is also interesting.

2

Hi @YRoshcha

This isn't something that is particularly well documented.

There is a high-level description of the modules in the runtime here: Node-RED - whilst it says that's 1.3, the fundamental structure hasn't changed since then.

Are there particular questions you have? I'd be happy to try to answer them. It may also help us identify what sort of internal architecture documentation would be genuinely useful to produce.

3

Interested in how node-edit works in principle
What is flow in terms of node js
How deploy flow is implemented and what kind of entity as such, if you look at it from the point of view of node js
How do flows interact with each other inside
how can projects be scaled horizontally in coded if there are limited hardware resources

4

The front end builds a JSON array from the user configured nodes and posts them to the API (runtime / backend)

Flow is a little bit overloaded but in most basic terms, a flow is 2 or more connected nodes.
When a flow is deployed, the runtime instantiates objects based on the nodes in the JSON (flows).

deploy (the front end operation) sends a JSON representation of what you have in the the graphical canvas (the node-red editor).

In the runtime, messages are delivered to the nodes based on the wires property in the instantiated nodes. There is more to this but this basic info should give you a flavour of what is happening.

You can easily run multiple Node-RED projects and use one of many established mechanisms to coordinate messages between them. For example, you can use shared-subscriptions to load balance or a database shared among your instances, or create your own message queue, or ...

5

To be clear, while the descriptions of Node-RED all talk about "passing messages between nodes" - this is perhaps slightly confusing for those people looking at the internals since the reality is that a msg object is mostly passed by reference between node instances. Though there are some notable exceptions where a msg object is cloned to try and avoid async change issues.

The runtime of each Node (capital N) is a Node.js module and is registered to Node-RED. The exported function is run when Node-RED starts. It in turn registers another function that is run for each node instance (small n) added to a flow. That 2nd function registers a 3rd function if it accepts input messages and it is that inner function that runs whenever a msg is received by the node instance (via event handling).

1 Like
7

thanks, this is known, interested in a deeper structure

8

that is, each node is a function that is executed sequentially?

9

To what end? What do you hope to achieve by understanding the finer details? I don't know how gravity works but I understand what will happen if I jump off the roof!

I have answered your questions from a users perspective - you shouldn't really need any more info than this to get started.

If you wish to completely understand the internals, then you could always look through the publicly available source code.

Alternatively, if you have specific questions we can certainly answer those.

10

in order to start this information is really enough, but this information is not enough to stabilize my system

11

Sequential is a bit of a slippery concept in JavaScript and Node.js :slight_smile:

Since node processing can be partially or fully asynchronous. But in essence, yes, that's how I understand it.

Obviously though, one node can have multiple output wires going to different nodes. so the actual execution order might be hard to understand. I believe that the order of adding to the flow has an impact.

12

I'm just trying to understand what is a flow: a flow or a node

if a node, then it turns out that a flow is generated for each node
if it is a flow, then for each flow there is a flow and functions in it that branch to other functions depending on the output of the node

13

Urm, a flow is a flow :grin: It is defined by a series of node instances that are related via wires - those are simply a concept that helps understand the sequencing of calls to the message handler in each node instance. Well, that's how I understand them anyway. I expect that Nick and other core devs could explain it better than I.

I guess I'd put it as the flow is defined by node instances related to each other via the wires (the flows file makes this clear as it is remarkably simple in structure). But the actual processing is about the sequence of calls as you say since node-red is not, fundamentally, a message queue service but rather, a complex node.js app made up of many interconnected modules bound together by the core runtime.

2 Likes
14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.