Why Choose Losant vs Node-RED As Your Low-Code Development Platform?

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.

What is Node-RED?

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.

Defining the Comparison

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:

• Node-RED does have some applicable uses in the realm of the Internet of Things, but it is certainly not an IoT platform. It has no first-class features to help manage a fleet of devices; write to or read from a time-series database; or handle the scale and security needs of a full IoT application.
• There are no data visualization or batch analytics tools built into Node-RED. It is possible to serve a dashboard in a web page, but the page and the data integrations that power it must be written in code.
• While Node-RED can handle HTTP requests and issue responses, it has no end-user experience management built in (authentication, authorization, or user-specific content). Such functionality requires writing custom middleware that is advanced enough to render Node-RED’s primary value proposition—low-code application development—a moot point.

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.

Similarities

First, let’s point out some of the similarities between Losant’s workflow engine and Node-RED.

• Both are event-driven application enablers built on the flow-based programming paradigm.
• Both execute within a Node.js based runtime—though Losant’s full stack brings a number of other technologies into play.
• While it is possible to write flows manually in a JSON structure (with Losant’s uploaded through an API and Node-RED’s written to the environment’s file system), both expect users to write their applications using drag-and-drop editors.
• Both platforms are extensible through user contributions; Losant has its custom node catalog through the in-app Template Library, and Node-RED has its online flow catalog.
• Losant and Node-RED flows can both be triggered by third-party sources; for example, HTTP requests, messages on subscribed MQTT topics, and proprietary services such as Particle.io. Both can also issue replies to that input, make new requests to those same services, and publish messages on their topics or channels.

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.

Differences

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.

Scalability in Cloud Environments

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:

• Adding more instances of Node-RED, each with copies of all flows.
• Putting a load balancer in front of the instances to distribute requests.
• Managing the deployment of new flows and updates to all the instances.

By contrast, Losant’s workflow engine is built with scale and high availability in mind.

• Messages (flow executions) are queued up in a separate service and held there until it is their turn to process (usually no more than 250 milliseconds).
• The workflows themselves are stored in a database cluster and are looked up as needed at the time of execution.
• When it’s their turn to run, messages and their corresponding workflows are distributed to workflow runner containers whose sole job is to process the message through the flow.
• Any lookups of additional data (i.e. device configuration or data table rows) go back to the database cluster.

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.

Multitenancy and Security Boundaries

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.

Deployment to the Edge

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.

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 …

• Losant’s edge workflow editor lives in our cloud platform, meaning flows are built and saved independent of the hardware, and one flow can be deployed to thousands of devices.
• Workflows are deployed to edge compute devices in the field remotely through our MQTT broker, meaning it is not necessary to obtain physical access to the device or add additional functionality to allow for remote writing to the file system.
• Cloud-to-edge communication is secured through the use of access keys for device authentication, and data is encrypted when connecting through a secure protocol.

Required Coding Skills

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
The method (“get”) and route (“/hello-world”) are defined in an HTTP In node. A Function node gets the current time, converts it to a human-readable string, and places the result on the payload. Returning custom formats requires additional work in the Function Node. The page response is built in a Template node, mutating the original payload in the process. An HTTP Response node defines the status code and any headers to include, and automatically returns the current payload as the response body.	The Endpoint trigger for this flow asks the user to choose an endpoint from a dropdown menu. Endpoints are maintained as a separate resource, with features such as authorization and meta tags built into their definition. The Endpoint Reply node defines the status code and headers as well as the response body (which can be also maintained separately as an Experience Page). The current time is automatically on the payload and date formatting is built into the extended Handlebars library, so no Function Node is needed.

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).

User Support

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:

1. Wait for the software’s community to step up. Maybe your concerns will be addressed in a matter of minutes, or maybe they’ll never get addressed at all. The software is usually maintained by a small community of users as personal passion projects, and those individuals are not bound by SLAs or paid contracts. Your business needs depend on their availability and desire to help, even when faced with a critical, time-sensitive issue.
2. Solve the problem yourself. At Losant, the users of open-source software are our experienced and educated engineers, and we have the technical know-how to fix third-party library bugs or read the source code to identify undocumented quirks. But for a project like Node-RED, whose very purpose is to enable application development by those with a limited technical background, this will only be an option for a small set of end-users.

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.

Wrapping Up

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:

• Node-RED’s inability to scale in cloud environments.
• Node-RED’s lack of a remote fleet deployment system.
• The need to spin up additional services to build a robust IoT application.
• Node-RED’s unpredictable support channels and release cycle.

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.