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.
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
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 ...
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).
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.
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
Urm, a flow is a flow 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.