Prototyping messaging + UI with Node-RED and Docker

Suppose your next big challenge is giving some important prospect customer a feeling of how the big data coming from his products will translate into a modern and responsive UI on the Web. This is what’s happening daily to many of us working in the embedded electronics systems design industry, and after a few iteration using several different strategies (drawing with LibreOffice included) we now find Node-RED as a Docker container as the definitive recipe for success.

Node-RED as a messaging + logics + UI solution for the Web solves a lot of architectural problems in elegant ways, but I agree it may not be the best solution for the real product based on the actual requirements, environment, scaling needs and many other factors. It gives however big advantages in the prototyping stage and has no rivals for showing some amazing user story, simulating situations and producing interfaces.

But what’s Node-RED?

Describing Node-RED in details is out of the scope of this brief note. Its Web site gives a lot in the first sentence: Node-RED is a tool for wiring together hardware devices, APIs and online services in new and interesting ways. I’m trying to describe Node-RED as a is a client / server framework based on Javascript and Node. Credits go to IBM Emerging Technologies and Nick O’Leary for inventing and maintaing Node-RED and its ecosystem.

Node-RED is a tool for wiring together hardware devices, APIs and online services in new and interesting ways (IBM Emerging Technologies).

The Server here refers to a Node application running on a host delivering dynamic web pages, and the Client is the combination of those pages being displayed in a browser and included Javascript code for automation and rendering. Dynamic refers to the ability of building a full graphical editor in a browser so that the developer will design an application by moving and connecting small Lego-like blocks. Each block acts as a simple messages transformation engine, linked to the others with an input and output(s). Connections with real hardware existing on the host is an important feature (serial lines, USB ports, filesystem etc) but connection to networked services like messaging brokers, databases and URI / API based hooks is where Node-RED gives maximum value to prototyping.

Node-RED tranforms messages and creates output from an information flow. The output can be more messages or Web pages. An important part of Node-RED from this point of view is the availablity of libraries for rendering charts, gauges, graphical switches and other UI building blocks. Simple but effective, extensible to almost anything and closely integrated in the graphical editor.

When building a prototype of a dynamic Web site that will (when coming to a real product) show views of information collected from devices located anywhere and connected to the Internet (do Internet of Things, Big Data Analytics and Predictive Maintanance sound familiar?) the ability to simulate some interesting behaviour of the devices originating data is almost as much important as the rendering is. Node-RED excels in this and gives full power to the developer to change and add features in minutes while keeping consistent and attractive, responsive Web views.

do Internet of Things, Big Data Analytics and Predictive Maintanance sound familiar?

The typical workflow for developing a prototype that will be used as a demo or for getting screenshots to be included in a quotation is:

• start designing a simple Web UI with Node-RED blocks
• use messages loops to add fake realistic data that feeds the UI
• (if really useful) start connecting the prototype to some real data coming from the hardware or from the Internet
• add more UI features while discussing with the client

The error to be avoided here is to let the client believe that this presentation of a Web product will magically evolve to the real one by cycling again with similar efforts. Robustness, resilience, scaling, continuity, security, cloning (DevOps stuff) is something very serious that must be built on top of all the demo oriented features, again based on Node-RED if this is the right tool.

Robustness, resilience, scaling, continuity, security, cloning is something very serious.

Docker and automation

Here comes Docker as the way for starting and porting a consistent self-enclosed Node-RED prototype between hosts. Again no details given here, so many developers today use Docker and the related services like docker-compose, Consul and Registrator for microservices orchestration.

The idea is to prepare a simple recipe for starting at least one Node-RED service paired to one messaging broker for an easy and fast simulation of messages flowing between devices, adding more microservices while evolving to more complex situations. Everything enclosed and self described as a set of Docker containers to be started based on a docker-compose recipe. Simple, extensible and easy to be scaled on a developer host.

So here is my proposed solution that fits the mentioned requirements, as usual based on works and comments found googling around and documented as a Github project. Feel free to post comments or open issues and contribute to the recipe!

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!