Understanding Node-RED flows

This is lesson two in the series if you have not read it already then checkout the “How to use Node-RED”

During this lesson we are going to break down a flow into its sub-components and dissect what is happening as an information packet (IP) is sent along the flow from one node to the next. This fundamental knowledge will allow you to create flows quickly, giving you greater understanding of what is going on “under the hood”. Once you understand these fundamentals you will be able to create flows that deal with complex data scenarios. First we will take a look at nodes and how they are split into three distinct groups — those that have input, those that have output and those that have both.

Nodes

Input Nodes

To start with we shall take a look at input nodes. These nodes will trigger the start of a flow and create the initial information packet. Input nodes typically get triggered from an external operation such as a HTTP request or a trigger button. You can usually spot these nodes as they will have only a single connecting dot on the right-hand side (the output connector) and a missing connecting dot on the left (the input connector). Therefore, you cannot connect two input nodes together as these nodes have no input connector.

Function Nodes

Now that we have an input node, we need to pass the information packet to a function node so that we can process the request. These nodes have both an input connector and an output connector.

They receive the message on the input connector, execute the function using the information packet data for input then modify the information packet, sending it to the next node via the output connector.

Output Nodes

The last type of node that we will look at is the output node. This node sends data out of your RedConnect app and can be spotted as it is missing the output connector.

In the example flow below we can see that the input node creates the IP, sends it to the function node for processing, which then sends the modified IP to the output node. Finally, the output node sends the packet out of RedConnect.

Information Packet (msg)

The information packet is simply a javascript object named msg:

{

};

This msg can then be extended by the nodes in the flow, adding, modifying and removing properties from this object as required. Before we look into creating our own custom properties on the msg, there are a few property names that are reserved that we should be aware of.

Payload Property

The most important is the payload property, which is how we pass data from one node to the next. This payload will always be read by the receiving node, which can act on the data provided. The payload property can be of any type –Object, Date, Boolean, String or Number.

{
payload: {}
};

One thing to be conscious of when saving data to the payload is that this property can be overridden at any stage along the flow and you will lose the data. If you need the data to be used by a node that is further down the flow, you should use a custom property. We talk about custom properties later.

Topic Property

The topic property is a String used to give a user friendly description of what we are doing with this msg. It can be useful when debugging a msg.

{
topic: '',
payload: {}
};

_msgid Property

The last reserved property is the _msgid property, which is a unique ID given to this msg. It is useful for debugging.

{
_msgid: '1db99c6d.e24664',
topic: '',
payload: {}
};

Custom Properties

Quite often when working with flows you need to pass data between nodes that are not connected. As the payload can be overridden at any time, we must use custom properties to pass the data. For example, we may have three function nodes connected in a flow, such as:

This flow is very simple and it just adds two numbers together.

The first node creates a custom property called msg.x and assigns it the number 1:

The msg now looks like this:

{
x: 1,
payload: {}
};

The second node then adds the custom property called msg.y and assigns it the number 2:

The msg now looks like this:

{
x: 1,
y: 2,
payload: {}
};

The last node then adds the two numbers together and sends the result out on the payload:

Which results in the following msg:

{
x: 1,
y: 2,
payload: 3
};

This is an incredibly simple example, but hopefully it gives you an idea of how you can create your own custom properties. One thing to bear in mind is that although you can choose any property name you like, any other node could override this name. Therefore, choose unique names that are likely to be left intact.

Summary

We have learned about the three different types of nodes — those that create the msg, those that process the msg and those that send the msg out of the app. We have also learned how the msg is constructed, what properties it has and how you can add your own custom properties. In the next lesson we will look at persistence and state, how we store data and persist state along and between flows.