At the end of a two-year development cycle, Node-RED IoT visual programming environment has finally reached version 1.0, bringing plenty of changes. Among the major new features in this release are a new asynchronous message passing model, new completion API, and message cloning by default. Additionally, the visual editor have been improved.
Created at IBM to make building industrial IoT solutions easier, Node-RED is an open-source visual programming environment enabling the creation of complex systems by interconnecting nodes representing physical devices, cloud systems, databases, API and so on. Nodes receive a message from any of their input nodes, process it, and propagate it through to output nodes. The overall resulting flow is what constitutes the computation carried through by the system.
Node-RED comes with a large collection of nodes to handle a variety of common tasks, including sending and receiving HTTP/UDP/TCP/MQTT messages, running commands, and processing files, as well as nodes that simplify the construction of complex logic, such as debug nodes, message multiplexers and demultiplexers, message buffers, and so on. More nodes are available from the Node-RED library.
(Image from Node-RED website)
Moving to a fully asynchronous message passing model -- meaning that all nodes have now async behaviour vs. some nodes being asynchronous and other synchronous -- brings some uniformity to Node-RED. However, this requires developers make sure their existing flows do not rely on any nodes being synchronous. In previous versions, if you had a flow made entirely of synchronous nodes, a message would flow through all of them in a single pass of the JavaScript event loop. With Node-RED 1.0, each node processes its input message, then relinquishes control to the main event loop. At the next step of the event loop, that message or a different one will be processed depending on which comes first on the runtime internal queue.
Switching over to fully asynchronous message passing was a prerequisite to a future feature on the Node-RED roadmap, the ability to plug code into a flow to customize the message routing path. Additionally, since a sequence of fully synchronous nodes could hijack the event loop for an unpredictable time span, ruling this behaviour out paves the way for using timeouts to control the system that has not entered a stale state, and guarantees that each message entering the system has a fair amount of computation time.
Related to the new async message passing model, nodes can now use a new API to specify when they have finished with a message. In short, when a node receives a new message, it will also receive a send and a done callback that are specific to that message, thus allowing the runtime to precisely track which messages have been dealt with fully. This also led to the introduction of a Complete node that can be triggered when a node with no output completed processing. All existing nodes should gradually migrate to the new API, but there is no need to rush, since the Node-RED runtime will still support the old API for some time.
Last but not least, introducing async message passing means all messages will be cloned by default. This represents a major departure from the previous model, which strived to avoid message duplication. While the new behaviour certainly has a performance impact, it will guarantee correctness and non-corruption of messages due to multiple asynchronous changes.
Finally, the Node-RED visual editor palette has been reorganized to make it more intuitive to use. A number of nodes have been removed, including the Twitter, Email, Feedparser, and others. Subflows configurability has been improved along with the JSON editor, which is now friendlier to newcomers.
Node-RED can run on the major OSes, including macOS, Windows, and Linux, as well as on IoT devices and industrial machines. You can easily run it using Docker images.