Since our company’s founding, visitors to our trade show booths—particularly those getting their first exposure to Losant—have looked at our visual workflow editor and had a common reaction:
“Is that Node-RED?”
It’s a fair question. In addition to the visual similarities, both tools serve a common purpose: to simplify application development by reducing the code language barrier to entry. After all, most humans can break complex problems into logical steps; take different actions based on conditions and outcomes; and track those outcomes in short-term memory from one cognitive step to the next. But very few of us know a programming language.
In this article, we’ll break down the differences between Losant and Node-RED, along with the reasons you’d choose either one as your low-code development platform.
Node-RED is an open-source, low-code programming tool for event-driven applications. It was first developed by IBM and is now maintained by the OpenJS Foundation. It was—and still is—a powerful visual programming platform that follows the flow-based programming paradigm, and it has every right to call itself a pioneer in both categories.
As to how it works, “events” trigger the kickoff of flows, and “messages” are passed from one “node” to the next. Along the way, nodes may mutate the message, spin-off side-effect processes, or conditionally follow different programmatic paths.
This is, of course, strikingly similar to Losant’s workflow engine. Prior to our public launch, we even considered using Node-RED as the backbone of our workflow feature but decided to develop a proprietary solution for reasons we’ll discuss below, instead opting for a user interface that was visually inspired by Node-RED but was otherwise entirely our own.
Losant vs. Node-RED is not an apples-to-apples comparison. The out-of-the-box functionality of Node-RED really only lines up with Losant’s Visual Workflow Engine and Edge Compute features. For example:
Therefore, we will stick to comparing Node-RED to Losant in terms of our drag-and-drop workflow engine only; by doing so we can draw some stark but fair contrasts between the two.
First, let’s point out some of the similarities between Losant’s workflow engine and Node-RED.
This list of similarities, though not exhaustive, shows that both Losant and Node-RED can accomplish almost any individual task that the other can perform, especially when you consider Node-RED’s user-contributed flows.
Now that we’ve described some of the key similarities between Losant’s workflow engine and Node-RED—in terms of their architecture, features, and usage goals—let’s talk about what separates the two.
Running each engine in a cloud environment—where flows can be executed through the public Internet via HTTP requests or through other events—is where Losant’s workflow engine really outshines Node-RED. It is possible to run Node-RED on a cloud server, though it’s rare to do so, given the technical challenges of setting the platform up outweigh the benefits of using a low-code platform.
Simply put, Node-RED does not scale well. The runtime is very self-contained (which is beneficial when running in a smaller, controlled environment), meaning the queue of runs, the flows stored on disk, and the code to execute each flow are all wrapped up in a single package. As demand for your application usage increases over time, including additional compute power to handle unexpected surges in traffic, the only real way to scale up is to do so horizontally, which involves:
By contrast, Losant’s workflow engine is built with scale and high availability in mind.
Any one of these components can scale independently. Losant often spins up additional workflow runners during periods of high demand, and regular backups of flow configuration mean your work is never lost.
Another shortcoming, when running in a cloud environment, is that Node-RED lacks support for multitenant applications. This missing functionality more than anything else is why Losant decided to build our own drag-and-drop workflow runner instead of using Node-RED.
As stated previously, an instance of Node-RED requires storing all flows, global credentials, and shared context in the runtime environment. Users have figured out ways to support multitenancy in Node-RED, but it requires a significant amount of additional setup and maintenance.
Losant, by comparison, draws clear security boundaries between tenants. Applications serve as hard security boundaries, where devices, workflows, third-party integrations, end-user experiences, and other resources from one application are unreachable through a different application. A level up from that, users have their own individual sandbox accounts (separate from organizations they may be members of), and those accounts allow a user to build multiple, completely separate applications for their IoT solutions.
Node-RED is much better suited to run on edge hardware, such as a Raspberry Pi. It can be installed on most Linux distributions or any operating system capable of running Node.js; it may also be installed as a Docker container, in much the same way that Losant’s Edge Agent is installed.
Through its user-contributed node catalog, Node-RED supports interacting with many of the same protocols supported by Losant’s Edge Agent, including Modbus, BACnet, OPC UA, and even some protocols that are not yet supported within Losant. Bearing in mind the additional work of installing and configuring these dependencies, it’s fair to say that Node-RED boasts more edge runtime functionality than Losant.
Node-RED on top, Losant on bottom. These two flows are identical, in that they allow for:
However, setting up the Node-RED version requires some additional work:
Where Losant differentiates itself is in the maintenance and deployment of workflows once devices are out in the real world. Node-RED’s flows are stored on disk within the runtime environment, as is the browser-based editor for creating and editing those flows. Therefore, in order to make changes to flows at a later date, you must either have physical access to the device, or set up a service to allow remote deployment—which is no easy task, much less with even basic security in place. By contrast …
Both Losant and Node-RED bill themselves as “low-code” platforms—meaning that users with no software development experience will find the solutions usable and accessible, but those with an entry-level knowledge of coding concepts will excel.
Installing either framework in an edge environment requires a slight amount of programming expertise. Node-RED requires installing Node.js and the Node-RED module as a global package, though they do offer alternative methods and helper scripts. Losant requires installing Docker and pulling the Edge Agent, setting up a configuration file, and then running the image in a container.
For referencing values on the payload and constructing new values, Losant supports Handlebars templates, payload paths, and JSON templates rendered against the current payload. Node-RED’s reference scheme varies from node to node; many require declaring the variable type separately from the input. Its Template Node renders a Mustache template and replaces the entire payload with the result. And some nodes accept JSONata expressions, which are not supported in Losant. Some users may find the explicitness of Node-RED less confusing, while others may appreciate Losant’s more succinct style.
| Node-Red | Losant |
|---|---|
|
|
|
|
A “Hello World” HTTP request that returns the current date and time in a human-readable format, built in Node-RED and in Losant.
For those who wish to write code, both Losant and Node-RED expose a Function Node, which allows users to fall back to writing JavaScript directly within the flow. Node-RED’s Function Node is a bit more robust as it provides APIs for adding multiple node outputs; executing asynchronous operations; accessing global storage contexts without adding them to the payload through other nodes first; and adding third-party libraries (which Losant disallows in its cloud environment for security reasons).
Finally, while not directly related to the software itself, it is worth pointing out that Node-RED is open source (in other words, “free”) while Losant is, outside of our free sandbox accounts, a fee-based platform.
Let’s be absolutely clear: At Losant, we are fans of, contributors to, and users of open-source projects, both professionally and in our employees’ lives outside of work. Many components of our platform leverage open-source software today. For example, our Modbus: Read and Modbus: Write Nodes utilize the open-source modbus-serial npm package—the same package used by Node-RED’s Modbus Node.
The downside of open-source software is, when it comes to user support, you get what you pay for. If you wish to extend the software’s functionality, or if you encounter a bug, or even if you just have questions about usage, you have two options:
Losant, by comparison, has a dedicated support team monitoring our public forums and enterprise support channels, and that team answers user questions; catalogs and prioritizes new feature requests; and issues immediate fixes when critical bugs are discovered.
While Node-RED has its advantages when running in an edge environment—particularly its vast catalog of user contributions built up over the years—it falls short of Losant’s workflow engine when used as part of an IoT solution due to:
All of that does not even take into account Losant’s additional product offerings that make it a better choice as a usable, scalable, and secure IoT platform for developers and end-users alike.