Gerrit Riessen, Experimentalist FlowHub

Sam Machin, Principal Engineer Jambonz

Viacheslav Katsuba, CEO & Founder at Scalicon.

Introduction

Gerrit created Erlang RED to experiment with visual Flow Based Programming (FBP) in conjunction with Erlang. FBPs message-passed concurrency is well suited to Erlang, conversely Erlangs Supervisor design pattern is well suited to FBP.

Erlang RED is an experimental Erlang backend to replace Node-RED’s existing NodeJS backend, aiming for 100% compatible with existing flow code, that’s the vision. Read more about the project here.

The goal is to bring the advantages of low-code visual flow-based programming to a programming language that is designed for message passing and concurrency from the ground up, Erlang.

Node-RED is great for creating data flows that actually describe concurrent processing, it is just a shame the NodeJS is single threaded. So why not use something that is multi-process from the ground up? Concurrency is guaranteed and included.

Erlang isn’t the most understandable of programming language. So won’t it be great to have the simplicity of low-code visual flow based programming and the performance (and concurrency) of Erlang?

This ended up a deep conversation on design templates / philosophies, and a planned follow-up discussion focused on telecom applications using Erlang Red.

Gerrit reviews Elang RED

Erlang RED is the front end of Node RED with an Erlang backend. His motivation came from an online discussion about creating a Python Frontend for Node RED, when ths discussion mentioned Erlang would be a better choice.

Gerrit has worked with Node RED for 2.5 years, and understands the editor. It turns out there’s 5/6 APIs required, it ends up a large JSON file that defines the APIs. From which he created the Erlang code. The first nodes were the inject (used to manual trigger a flow by clicking the node’s button within the editor. It can also be used to automatically trigger flows at regular intervals.) and debug node (display messages in the Debug sidebar within the editor.) You can read about the core nodes here.

Gerrit openly shares the lack of applications at the moment, its an experiment on how flow based programming works with Erlang. So I took a step back to the main application areas of flow based programming which is IoT; and the main application area of Node Red in my experience.

Surprisingly Gerrit had no IoT applications. He came to Node Red through Yahoo Pipes, that provided a graphical user interface for building data mashups that aggregate web feeds, web pages, and other services. Which is currently in the process of closing down. However, this web driven approach can lead to some interesting people and problems. Telecoms has a habit of being a monoculture.

Where is Erlang RED Going?

Given the web focus, I asked about ELIXIR, rather than Erlang. Which boiled down to Gerrit’s dislike of Ruby. The conversation moved onto whether Erlang-RED was production ready. For open source tools, production readiness depends on how much you’re willing to support. Sam gives some great examples of the spectrum contained within the term production ready.

Slava asks about the platform to run Erlang RED, does it support mobile? Its desktop based like Node RED. Though Sam does highlight the iPad experience works. Gerit mentioned that dashboard is supported, not just the editor.

The problem Gerrit is solving is saving building an entire client around flow based programming, rather using Erlang instead. This highlighted Gerrit is assuming that the users of Erlang RED are Erlang developers. A niche within a niche as Gerrit mentioned later. Sam and Gerrit discuss the compatibility of Node RED versus Erlang RED.

Gerrit brings up the Supervisor node in Erlang, we discussed this with Vance Shipley’s experiences with Erlang. Code just runs, its fault tolerant. Gerrit hopes the Supervisor node in Erlang RED will be back ported to Node RED. There is the Catch node in Node RED, which manages catchable errors. But the design philosophy is different between Node RED and Erlang.

Gerrit highlights the issue in Node RED that the nodes are not independent, unlike in Erlang. The discussion becomes slightly philosophical on is it a node or function? But this is the crux between Node RED and Erlang RED. Gerrit explains they are processes, and whether its a node or function is purely a matter of definition. They are independent.

Sam asks about how manage consistency of an object. Gerrit highlight in Erlang there are immutable data stores. No need to clone objects unlike javascript where everything is a reference. A change made in a function is made absolutely within that function. It’s in the design pattern / philosophy of flow based programming. To be honest, I was struggling at this point, but this is a critical issue on the potential value of Erlang RED versus Node RED.

Developers

The conversation moves onto the risk of confusion for developers between Node RED and Erlang RED. Given the niche Gerrit is addressing, the confusion from the Erlang community is small in number and reach. While as a source of confusion within the Node community, its potentially a gateway into flow based programming. Not necessarily a fork, rather a diving board into a new programming method. And Gerrit wants confusion for people to understand the difference Erlang Red makes possible with flow based programming.

Gerrit reviews his experiences as the Erlang community engages with Erlang RED and bring in their requirements, such as OTP (Open Telecom Project). Which is neatly summarized as “you do not let things die”. Which is possible with Erlang RED, without the introduction of the supervisor node.

As a simple statement Gerrit’s objective is to bring visual programming to a new community. Sam asked how a supervisor node is associated with the nodes it protects. Gerrit stated, it’s like the Catch node, you link them.

The discussion moves onto how to avoid developer confusion, and the importance of documentation (written and video) how-tos, walk-throughs, and manuals. Which is always challenging at the start of an open source project as a few well-educated users grows into loads of users that did not read the documentation well.

Node RED 4.1 is reporting usage, across its 5550 nodes, new upgrades for the past month was 14k. Which you can take that for what it means. In my experience, upgrade happens when there is no other choice, you do it.

Sam asks an important question, does the underlying language matter to a visual programming tool? The high level answer is no, however there is a but. This leads onto a discussion around the Function node, a core node that allows users to execute custom JavaScript code within a flow.

Sam worked on building the visual programming capabilities of Nexmo / Vonage. He often positioned visual programming as a trade-off between complexity and capability. Coming out of this session its clear we need to reflect and come in for a round 2 focused on specific applications in the telecoms space. Where the applications can help create a focus.