Node-RED Basics: What are event-driven applications?
The first thing you should know before building your project in Node-RED.
Table of Contents
What is an event-driven application?
Industrial Internet-of-things (IIoT), data management, and many more applications are inherently event-driven. Being event-driven means that in these applications, processing occurs only when events occur, otherwise the applications are, conceptually, idle. What is an event depends on the application, but examples are a sensor reading being above a certain threshold, a database size exceeding a predetermined limit, etc.
You, in fact, are reading this article in an event-driven application: your Internet browser. One browser event is a mouse click over the word “File” in its menu bar, whose processing results in the display of the file menu, with options like “New Tab”, “New Window”, “Open File…”, etc.
Key concepts of event-driven applications: Emitter, listener, data
Core to event-driven applications are the concepts of event “emitter”, “listener”, and “data”. As their names imply, the event emitter is the software block that generates (emits) an event, with potentially some data associated to it, while the event listener waits for the event emitter to fire an event and then reacts to (processes) that event using the event data, if needed.
In the browser example, a software block that monitors the mouse for clicks could be an event emitter, the mouse click X and Y coordinates on the screen could be the event data, and a software block that checks whether the mouse click coordinates fall on the screen rectangle bounding the word “File” in the menu bar, and displays the file menu (if needed), could be an event listener.
Figure 1. Example of a digraph to show data flow
Event-driven applications may be conveniently represented graphically using a data flow diagram where arrows go from emitter circles to listener circles (Figure 1 above). In graph theory these types of graphs are called directed graphs or digraphs, the arrows are called edges and the circles are called nodes. In a digraph event data can be visualized as “flowing” or going from emitter to listener, and sometimes a description of the event data can annotate the appropriate arrow. Compared to alternative options (like lines of software code in a text editor) visualizing and designing event-driven applications as digraphs is quite powerful, as they make complex systems with all of their interrelationships more comprehensible, they enhance maintainability and they are largely self-documenting.
Event-driven applications with Prescient Designer and Node-RE
Prescient Designer (and Node-RED, the open-source tool which it is based on) is a graphical low-code platform that can be used to develop event-driven applications in the DataOps, IIoT, and workflow automation spaces, to name a few. In Designer, the digraphs are simplified thusly:
Nodes can be event emitters, event receivers or both. A node may have one input, which is an event listener; and it may have one or more outputs, which are event emitters.
Nodes are represented visually as rectangles with rounded corners, and to enhance digraph legibility, they may have a representative icon on the left, and a label on the right of the rectangle. Nodes cannot be flipped, neither horizontally nor vertically. The node input (if any) is represented by a small square with rounded corners and is always on the left side of the rectangle, while the outputs, if any, are also represented by small squares with rounded corners but are always on the right side of the rectangle.
Edge direction may be inferred by graph construction, as edges are only allowed to go from node outputs to node inputs, thus an arrow head is not needed and is omitted to avoid visual clutter.
Event data is called a “message”, and is represented as a JSON object.
Figure 2. Example of simple event-driven application in Prescient Designer
Figure 2 (above) shows a simple Prescient Designer application, where an event emitter, an alert node, is connected to an event listener, an SMS node, so that when there is an event (say a tank pressure exceeds a safety threshold), the event message will contain the alert description, tank number, etc., and the listener can send an SMS message to the parties that need to be notified.
Learn more about event-driven applications
In general, event-driven programming can help you build applications that are more efficient and easier to build, especially if you use a digraph-like or low-code software like Prescient Designer. Despite its simple appearance, you can build, deploy, and manage edge data applications with it. See our edge data use cases built with Prescient Designer here, and our IIoT use cases here. Want to try out event-driven programming? Did you know you can get a live demo and setup a Prescient Designer account for free, and start building your applications straight away? Try it out now!