Finally done, this commit makes all nodes to gen_servers and thereby making the introduction of supervisors for flows possible.
Big thanks to all for the good advise and patiences!
The structure of individual nodes is now fairly settled, especially as I’ve implemented quite a few nodes and each had their own requirements. I hope there is now enough functionality to easily implement new nodes and add functionality to Erlang-RED.
At the moment ~20 nodes have been more or less implemented and there are ~60 test flows to ensure that functionality doesn’t break and is compatible to the original Node-RED.
Many thanks again to @mwmiller, for keeping the test version online. In the coming days, I will improve it so that it becomes more interactive and even useful 
I’ve now created an architecture document but - spoiler - it has no diagrams. It is description of two workflows and how they are implemented in Erlang, i.e. deploying a flow from the flow editor and executing a flow - via the flow editor.
As I write in the readme, there is much interconnectedness within the code simply because of the nature of the implementation and types of nodes.
1 Like
Quick update on the project, I bumped into milestone 3 today and it irepresents a solidification of the development process - flow tests have been outsourced, JSONata has been outsourced etc
As some of you know, I added Elixir support, basically anything that compiles to the BEAM should be supported - is my opinion!
There is now a function node that allows for direct execution of Erlang code within a flow. The node even has - rudimentary - syntax highlighting for the code. Monaco - the underlying editor - does not have an impressive Erlang mode unfortunately - but COBOL yes! 
The function node is a bit deceptive since it has the incorrect default code:
fun (Msg) ->
Msg
end.
is wrong, that’s the wrapper placed around code that is put in the function node, e.g. maps:put(fubar, hello, Msg) would be valid Erlang code for the function node.
Msg is a map and contains the details of the message sent to the function node.
As always, there is a live demo available to play around with.
1 Like
So having spent much time trying to get my head around supervisor behaviour and creating some kind of Erlang architecture that works, I wrote a architectural document for how one node type is implemented within that architecture.
What I describe is the function node that allows executing Erlang code within Erlang-Red - basically wrapping Erlang code around a message-passing flow-based paradigm.
Not to spoiler but in the end I came up with this process architecture:
Two features made it that complicated: dealing with supervisors and handling timeouts for a function node. Both now work and I’ll probably stick with that architecture.
I don’t use process links, instead I’m using monitor for one-way linking but that’s all described in the text above!
