# \[Article\] Node-RED terminology
**URL:** https://discourse.nodered.org/t/article-node-red-terminology/79743
**Category:** General
**Created:** [11 July 2023 17:03 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743 "2023-07-11T17:03:19Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [11 July 2023 17:03 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/1 "2023-07-11T17:03:19Z")
Hi There!
So in my endeavours to bring Node-RED to the masses, I have written a short piece on the terminology of Node-RED. The intention is to reuse this text in other articles, so I've tried to keep in encapsulated.
I would love to get feedback on whether there is anything completely way-off from the language used within the community, e.g., is it links, wires or connections? Wires seems to be the term to be using.
Anyway I hope its worth reading, it has an epic ending! ð
_Great article would scan it again in an instance -- ChatGPT._
> **[Node-RED Terminology | Open Mind Map Blog](http://blog.openmindmap.org/blog/node-red-terminology)**
>
> Every application has its own language and so it is with Node-RED. The terminology of Node-RED is one of nodes, wires and flows - but what do they mean?
---
### Author:  [@stefan24](https://discourse.nodered.org/u/stefan24)
#### Post date: [11 July 2023 19:20 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/2 "2023-07-11T19:20:50Z")
> To trigger this, the inject not...
Should write the inject node...
---
### Author:  [@drmibell](https://discourse.nodered.org/u/drmibell)
#### Post date: [11 July 2023 23:42 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/3 "2023-07-11T23:42:08Z")
> [@gregorius](#):
>
> I would love to get feedback
Nothing in this piece is really wrong, but some things are off by just enough that I would hesitate to recommend it to a newcomer to Node-RED. The [Node-RED Concepts](https://nodered.org/docs/user-guide/concepts) section of the documentation covers much of the same ground without any of the minor issues I find in your piece. Some examples:
> [@gregorius](#):
>
> is it links, wires or connections? Wires seems to be the term to be using.
Wires, definitely (see the documentation). "Links" should be reserved for the `link` nodes. When "connections" are made by the network nodes (http, mqtt, tcp, etc.), they may be temporary.
> Flows are visual code, programs that describe the modification of data
This is correct in the context of [flow-based programming](https://nodered.org/about/), but unfortunately in Node-RED the term "flow" has become overloaded in ways that can cause confusion. The relevant [part](https://nodered.org/docs/user-guide/concepts#flow) of the Concepts documentation is the developers' best effort to deal with this.
> Node-REDs convention is that the data object passed into a node is called `msg` .
This is a bit muddled. From the documentation,
> Messages are what pass between the nodes in a flow. They are plain JavaScript objects that can have any set of properties. They are often referred to as `msg` within the editor.
>
> By convention, they have a `payload` property containing the most useful information.
You don't actually mention "messages" until almost the end of the piece, but the term should be used throughout.
Other thoughts: you should at least mention context variables and the distinction between the editor and the runtime. I think your efforts to promote the use and understanding of Node-RED are very valuable, and I hope you take these comments as a constructive effort to improve your document.
[EDIT]
> Connectors are the [small squares](http://blog.openmindmap.org/blog/node-red-terminology#) attached to the nodes.
These are "ports" not "connectors," and they are circles in the standard version of the editor.
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [12 July 2023 06:48 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/4 "2023-07-12T06:48:35Z")
> [@stefan24](#):
>
> Should write the inject node...
Fixed - Cheers!
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [12 July 2023 07:36 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/5 "2023-07-12T07:36:14Z")
> [@drmibell](#):
>
> I think your efforts to promote the use and understanding of Node-RED are very valuable, and I hope you take these comments as a constructive effort to improve your document.
Cheers for the feedback, much appreciated ð I will definitely include your feedback in my revisions of the article.
> [@drmibell](#):
>
> This is correct in the context of [flow-based programming](https://nodered.org/about/), but unfortunately in Node-RED the term "flow" has become overloaded in ways that can cause confusion. The relevant [part](https://nodered.org/docs/user-guide/concepts#flow) of the Concepts documentation is the developers' best effort to deal with this.
Hm, that makes it difficult to exactly explain what a collection of nodes + wires _actually_ represent. For me node + wires = flows ==\> code ==\> _programs that do stuff_. What is the term to be used instead of flow? ðĪ Even the [homepage](https://nodered.org) uses flow in this sense:
> It provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes[...]
The term "flow" is definitely not easy to nail down.
> [@drmibell](#):
>
> Wires, definitely (see the documentation). "Links" should be reserved for the `link` nodes. When "connections" are made by the network nodes (http, mqtt, tcp, etc.), they may be temporary.
It simplifies the explanation, I will definitely do that. You also correctly point out my inconsistence with the term "message" - I will fix that too.
> [@drmibell](#):
>
> These are "ports" not "connectors," and they are circles in the standard version of the editor.
Squares or circles? They look like squares to me! At least on the nodes, on the link nodes they are circles but squares on the opposite side of the link. Now I'm confused!
That's from v3.0.2 - for me: a circle, a rectangle (hm, square in this case), a square and the beginnings of a line, for Node-RED a link input port, a node, an output port and the beginnings of a wire. The port does seem like a square to me - the output port!
> [@drmibell](#):
>
> Other thoughts: you should at least mention context variables and the distinction between the editor and the runtime.
I'd rather do that in other articles, I think I will keep this article more focused on the concepts before getting into the technical workings of Node-RED. Also this is intended to be a text snippet that I can use in other articles.
To a certain extent, what the article shows is my own confusion and thereby mirroring the potential confusion of others. Once my confusions are gone, I can't write about them, so best to write now!
What I also wish to say is that to an extent it doesn't matter what one calls the "rectangles" and "lines" as long as one has understood the basic concepts of flow programming, one can _use_ but perhaps not _100% understand_ Node-RED.
The reason why I refer to rectangles and lines is because that is what many people see initially. I see Node-RED as something that non-programmers can use to create programs. So the common language IMHO, the overlap between programmers and non-programmers in this case, becomes shapes. Hence the low-level beginnings of the article.
I'm sure my article would pass the Turing test, but would it pass the Grandmother test? (i.e. does grandmother understand how to use Node-RED?) - The Grandmother test is what I'm aiming at.
Thank you for providing such detailed feedback ð Responding to your comments has given me a better focus for what I want to achieve with the article and clarified my thoughts ð
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [12 July 2023 14:05 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/6 "2023-07-12T14:05:41Z")
@drmibell based on your feedback, I've come with a completely different article
> **[Visual programming using Node-RED | Open Mind Map Blog](https://blog.openmindmap.org/blog/from-code-to-shapes-visual-programming)**
>
> Visual programming is a paradigm shift away from editor-based programing to a visual context. With this shift comes new challenges, not least of which are the shapes - does the rectangle actually mean?
I've changed the terminology but also the point of the article: instead I promote the use of a visual programming paradigm instead of trying to introduce the Node-RED terminology. From there I can go to what I actually want to write about: refactoring in a visual programming environment and some best practices using Node-RED.
---
### Author:  [@omrid](https://discourse.nodered.org/u/omrid)
#### Post date: [12 July 2023 14:29 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/7 "2023-07-12T14:29:54Z")
I proposed in the past (but got a pushback from dev team as such change would be too pervasive & impactful) to clear the confusion around the overloaded term "Flow".
In an ideal world, the terminology would differentiate between:
1. The whole "Workbook" (the full set of editor tabs, configured in a flows file instance)
2. A "Tab" (within the workbook)
3. A set of connected nodes (within or across tabs). Could be called "flow", "map", "blueprint" etc.
4. A sequence of messages, initiated/injected through a set of connected nodes ("run", "stream", "injection", "msg sequence" etc.)
Again, maybe too late to change now, but would have resolved some ambiguity.
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [12 July 2023 15:03 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/8 "2023-07-12T15:03:23Z")
> [@omrid](#):
>
> The whole "Workbook" (the full set of editor tabs, configured in a flows file instance)
I was just thinking of Jupyter, they use "notebook": perhaps Node-RED could use "Flowbook". Then the extension could become `.jfb` (theirs is `.ipynb` from ipython + notebook) ð
"run" is also good - a "flow run" for an execution of a flow?
But definitely agree with your suggestions, sound sensible to me.
---
### Author:  [@greengolfer](https://discourse.nodered.org/u/greengolfer)
#### Post date: [12 July 2023 15:11 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/9 "2023-07-12T15:11:15Z")
My 2 cents on terminology...
For me, the most confusing is "flow".
It can be either a tab (so "sets of connected nodes") or one set of connected nodes.
Calling two different things with the same word is quite confusing.
Especially when the flow context for variables means in fact the tab context ðĪŠ
And, from I can tell, there is no "set of connected nodes" variable which has made my life difficult in a few cases.
And thanks for the article !
---
### Author:  [@drmibell](https://discourse.nodered.org/u/drmibell)
#### Post date: [12 July 2023 15:39 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/10 "2023-07-12T15:39:55Z")
> Visual programming is a paradigm shift away from editor-based programming to a visually interactive context. With this shift comes new challenges and new approaches to programming.
This makes me feel like the sort of fossil that belongs in a museum. I learned to describe algorithms with flowcharts before I ever wrote a line of code. The goal of automatic translation or compilation of diagrams into executable code has been a theme of computer science for decades and has helped
motivate development of important programming languages and markup languages. I guess Node-RED deserves credit for reminding us of that "ancient history."
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [12 July 2023 16:16 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/11 "2023-07-12T16:16:38Z")
> [@drmibell](#):
>
> with flowcharts before I ever wrote a line of code.
UML, the good old days! But they never managed to have diagram and code in sync, i.e. change diagram --\> code changes and/or code changes --\> diagram changes. It was always model the diagrams, generate code one time, change code, update diagrams by hand ....
The holy grail of UML, SysMLv2 and BPMN ... and the rest. (Although apparently there have been successful projects in the SysMLv2 world that has managed to keep the two in sync ...)
That's why I find Node-RED so inspiring since it combines the two and keeps them in sync and that in the browser! Pity that Node-RED hasn't yet found wider adaption into areas that aren't IoT... ðĪ
> [@drmibell](#):
>
> This makes me feel like the sort of fossil that belongs in a museum. I learned to describe algorithms with flowcharts before I ever wrote a line of code.
Btw I can top that: I wrote code, then drew UML diagrams, then went back to coding and now I'm drawing again ... hm ... history, rinse, repeat.
---
### Author:  [@drmibell](https://discourse.nodered.org/u/drmibell)
#### Post date: [12 July 2023 22:15 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/12 "2023-07-12T22:15:52Z")
> [@gregorius](#):
>
> model the diagrams, generate code one time, change code, update diagrams by hand ....
Yes, that's a hot mess. Is the diagram the design or the documentation? If the programmers can force changes in the diagram, then where is the architecture, and who is responsible for it? I may actually have been lucky to work in organizations that were too rigid and bureaucratic to allow anything like that.
---
### Author:  [@oywino](https://discourse.nodered.org/u/oywino)
#### Post date: [17 July 2023 07:45 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/13 "2023-07-17T07:45:43Z")
NodeRED tends to refer to this as "Low-Code/No-Code", but that isn't true. There's very little one can achieve without resorting to JavaScript. Very little indeed.
I used NR as an add-on to Home Assistant, but as HA has grown to include if-then-else and support for PyScript, I find that I no longer need NR. Most automations are easier to do in HA as-is, until someone comes up with a true "No-Code" version of NR.
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [17 July 2023 08:20 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/14 "2023-07-17T08:20:30Z")
> [@oywino](#):
>
> support for PyScript
So that solution is not no-code either.
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [17 July 2023 08:20 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/15 "2023-07-17T08:20:33Z")
No-Code certainly not, low-code very much so - IMHO.
> [@oywino](#):
>
> There's very little one can achieve without resorting to JavaScript.
I initially thought that too but then began using the in-house nodes such as switch, change, template, and so on to reduce the usage of the function node. What really helped was learning [JSONata](https://jsonata.org/) which can do most of what I ended up doing in the function node.
For example this [change node + jsonata](https://demo.openmindmap.org/omm/#flow/1f980ab215b3d38b/n/c6d401a2115666f6/edit) does the same as this [function node](https://demo.openmindmap.org/omm/#flow/1f980ab215b3d38b/n/d5835b95f7c4d75d/edit). As in this example, I still find myself using the function node where a change node would also be usable - that's refactoring that I need to do.
Of course I always have something that isn't covered by a node and so I end up using a function node but that code is to the point, i.e. there is no converting between formats, there is no http requests to get the data, there is no boilerplate code. The function code tends to be very explicit functionality that is required at a specific point in the flow.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [17 July 2023 08:25 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/16 "2023-07-17T08:25:12Z")
> [@oywino](#):
>
> There's very little one can achieve without resorting to JavaScript
> [@oywino](#):
>
> if-then-else and support for PyScript
It is unfair to say you can do "little" "without resorting to JavaScript" then big up HA which makes you use an own if-then-else logic + pyscript. PS there are good reasons to learn JS over pyscript - [example](https://dev.to/kristiyan_velkov/pyscript-vs-javascript-1pph)
There is far more you can do in node-red without ever writing JS. You can chose to do JS if you are comfortable with it - ask @cymplecy - he uses NR extensively and pretty much refuses to touch JS.
---
### Author:  [@jbudd](https://discourse.nodered.org/u/jbudd)
#### Post date: [17 July 2023 08:40 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/17 "2023-07-17T08:40:04Z")
> [@gregorius](#):
>
> What really helped was learning [JSONata](https://jsonata.org/) which can do most of what I ended up doing in the function node.
"Not using the function node" is not the same thing as "low code" surely?
It may be strange and cryptic but Jsonata seems to be a coding language.
ps How come I have to click the "Go back" button three times to escape from that openmindmap link?
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [17 July 2023 08:51 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/18 "2023-07-17T08:51:50Z")
> [@jbudd](#):
>
> ps How come I have to click the "Go back" button three times to escape from that openmindmap link?
that's node-red - it's because your in the NR editor and it does not wish that you leave.
> [@jbudd](#):
>
> "Not using the function node" is not the same thing as "low code" surely?
How many grains of sand make a hill? Start with a single grain and then add grains individually, each time ask yourself is that a hill.
Where does "low code" begin? Where does "no code" end? What do I know and why would I want to argue against your opinion that not using the function node is _not_ low code - which, btw, I didn't say. What I was pointing out was that using the in-house nodes makes less usage of function nodes and less function nodes is less code (by definition since you're not using `msg.ZZZ = YYY` all the time).
Either way, typing a telephone number into a phone is coding: how else would the machine know whom to call? If I use an address book is that then low-code or no-code?
Hint: everyone has their own definition for low-code and no-code (since it comes down to experience), to claim tool X is low-code while tool Y is no-code is a bunch of marketing.
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [17 July 2023 09:06 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/19 "2023-07-17T09:06:38Z")
> [@jbudd](#):
>
> ps How come I have to click the "Go back" button three times to escape from that openmindmap link?
Hm having look at the code, this is what I do:
```auto
onpaletteadd: () => {
var nodeId = window.location.hash.match(/\/n\/([^\/]{16})(\/edit)?/);
// RED.nodes is not initialised at this point, so there is no way to
// check whether the nodeId really does exist, so we assume that nodeId
// will be eventually addded to a workspace.
if ( nodeId ) {
var hndlr = (node) => {
if ( node.id == nodeId[1] ) {
setTimeout( function() {
var nde = RED.nodes.node(nodeId[1]);
RED.workspaces.show(nde.z,false,false,true);
if ( nodeId[2] == "/edit" ) {
RED.editor.edit(nde);
}
RED.view.reveal(nodeId[1],true);
}, 1012);
RED.events.off("nodes:add", hndlr);
}
};
RED.events.on("nodes:add", hndlr);
}
// Highlight an entire path.
var pathIds = window.location.hash.match(/\/p\/((.{16},?)+)/);
if ( pathIds ) {
var nodeIds = [];
pathIds[1].split(",").forEach( function(ndeId) {
if ( ndeId.trim() != "" ) { nodeIds.push( ndeId.trim() ) }
});
var hndlr = (stst) => {
if ( stst.state == "start" ) {
setTimeout( () => {
RED.workspaces.show(RED.nodes.node(nodeIds[0]).z,false,false,true);
RED.view.selectNodes({ selected: nodeIds });
}, 321);
RED.events.off("runtime-state", hndlr);
}
};
RED.events.on("runtime-state", hndlr);
}
},
```
This simulates the deep linking functionality that is coming in 3.1.x for NR 3.0.x. Clarification: highlighting a node via a url, not deep linking associated with the link nodes.
I assumed that I manipulate the `window.location` value and push something on the stack but that's not the case. So not really sure what is going on. I definitely don't wish to break the back button and thanks for pointing it out ... fixing is now the problem.
EDIT: It does seem to be a Node-RED issue but only on Firefox, e.g., [link to node tab](https://demo.openmindmap.org/omm/#flow/1f980ab215b3d38b) will change the location twice:
- first to the [first tab](https://demo.openmindmap.org/omm/#flow/878170e6f86c502b)
- then back to the [intended tab](https://demo.openmindmap.org/omm/#flow/1f980ab215b3d38b)
Opera will combine these two and the back button isn't affected. Firefox with have two locations in the history that point to the first flow tab and the intended flow tab.
---
### Author:  [@oywino](https://discourse.nodered.org/u/oywino)
#### Post date: [31 July 2023 12:34 UTC](https://discourse.nodered.org/t/article-node-red-terminology/79743/20 "2023-07-31T12:34:46Z")
Excellent illustration of "low-code" ð
Sufficient to scare the sh\*\* out of every newbee who literally believed that NR was no-code/low-code.
[Next page](https://discourse.nodered.org/t/article-node-red-terminology/79743.md?page=2)