Node-RED Hits 1.0, Looks to a Serverless, Microservices Future
After six years in development, the Node-RED low-code, event-driven programming platform has finally reached version 1.0, and the launch brings a couple key new features to its users, as well as an updated look and a more uniform Cascading Style Sheets (CSS) implementation for white label implementations.
According to Nick O’Leary, Node-RED Project Lead, reaching version 1.0 was part symbolic as an outward signal that the tool was more than just a toy but rather production-ready.
“Even though we weren’t 1.0, there are already a wide range of companies adopting Node-RED in their own products and services. It’s widely used in production. A large part of this was getting to 1.0 just to reflect the maturity of the project,” O’Leary told The New Stack. “Node-RED is stable and good for production. It is more than just a toy project that you pick up for five minutes and throw away – it’s a proper tool for being productive.”
While Node-RED started out as a tool focused on the IoT, O’Leary now says that the use cases have expanded, with possibilities for microservices among them, although some changes may be needed to fully realize that dream. Right now, for example, the Node-RED runtime and web-based visual editor are packaged together, and even installed as a default on the Raspberry Pi OS, but this may need to change to truly embrace microservices. Nonetheless, one primary change with Node-RED 1.0 could pave the way for future releases.
According to O’Leary, the move to flows (those are the linear motions of a program executing) being asynchronous by default not only provides certainty for developers as to how their applications will run but also opens new doors to future features.
“It enables some exciting new features later on in our roadmap. By being fully asynchronous we are able to do more work in between the nodes. One of the big features we’ve got coming up in the roadmap is allowing custom code to be inserted in the runtime when messages get passed between nodes,” said O’Leary. “For example, you could create a distributed Node-RED flow where, in the editor, you draw your flow as you logically think of it, but when you deploy, the system can realize that this part of the flow runs on this device but this second half needs to run on this other device or in the cloud.”
Beyond the move to asynchronous by default, Node-RED 1.0 also brings with it a newly retooled Docker container image. While the project had provided a Docker image for a while, O’Leary said that it has “languished slightly” and fallen out of pace with different things, including the Raspberry Pi architecture, and the new image is now fully up to date.
Beyond functionality, Node-RED also comes with a new look, with an overhauled CSS for white-label implementations, and a redesigned Node-RED Flow Library, which is home to more than 2,200 third-party add-ons that can be used in any flow. In the time Node-RED has been available, it has been downloaded two million times, but O’Leary pointed out that it took five years to reach the first million, and the second million happened in just the last year.
Looking to the future, O’Leary said that he could see some possibilities in integrating Node-RED with Knative, the project that runs containerized workloads in a serverless environment. Currently, Node-RED can run anywhere you can run Node.js, but he sees a possibility for Node-RED to run in the less-ephemeral serverless environment of Knative. He also said he could see the editor being used in other use-cases as well, with serverless environments again serving as a prime opportunity.
“We’ve broadened our horizons because we’ve recognized that, as a piece of tooling it’s applicable to a much broader audience of developers and scenarios and industries — to any sort of event-driven application,” said O’Leary. “You could easily create microservices with it.”