Performance yes but probably not what you think. The performance of developing software in cooperations with non-developers, to improve the communication between "stakeholders" and developers. The ability of a visual solution to provide a holistic overview versus textual based solutions is what fascinates me. The potential to do better than Jira tickets, Scrum meetings and Agile methodology to software development - all being textual centric with static, immutable imaginary to help transport complex and shape-shifting goals.
Additionally Erlang-Red aims to bring the ideas of visual flow based programming (FBP) to a new developer community. One that is fascinating mix of academics and industry for something that is basically passed its prime. Think: Rust & Go here that have taken the place of Erlang in developers imaginations - not to mention Elixir which strips Erlang of all the good bits only to replace them with "ruby-like" constructs that pretend to hide the difficulties of a creating a working Erlang architectures. Elixir has good goals and I think that's fine but Elixir seems to be limited to the application of Erlang to the web - this is something that Erlang-Red does not aim to be.
No. Cowboy, this is an Erlang project because Erlangs key selling points (independent , message communicating processes and immutable data structures) fit incredibly well to the fundamentals of FBP. I am literally amazed that in the ten years of Node-REDs existence, no one else has done this. But I can imagine why.
I also have Elixir integration via a separate library (for markdown and csv) but at its core, Erlang-Red will be Erlang. Some have asked "why not Beam-Red" - because that simply does sound good - beam me up scotty. Plus others can create Beam-Red and Elixir-Red that's why I want to create a body of standard unit tests to define the standard behaviour of Node-REDs core nodes - that way other projects and test their implementation with a "standardised" visual test set.
Communication between nodes is Erlang message passing. There is no need for an extra framework to facilitate that. Cowboy does the entire web stuff and the rest is Pid ! Msg. Message cloning is for free. Events are messages. There are many gen_servers that maintain states and supervisors to restart stuff if things break. I.e. all the good bits of Erlang are utilised.
Done that - I tag the websocket and add it to a cookie. For each combination of node and websocket tag, a separate Erlang process is created (i.e. nodes are represented by proceses). Each message is passed to the right combination of websocket tag and node id ensuring that a end user, who is identified by the websocket, has their own execution space.
It was indeed something I saw right at the start and that I wanted to have - since I didn't want a server farm but only a single server for multiple clients.
Nodes have a per-process context, flow & global contexts can be simulated by using either statemachine or gen_server. And I think I will leave it at that, I don't think I want to implement flow and global contexts because they simply don't fit into the Erlang world.
Addressing a developer community versus a "user"community means that providing the basics and allowing others to experiment is important. Node-RED has a fundamental different approach because the "users" aren't the "developers", i.e., developers create nodes and users, use them. I want Erlang-Red to merge those two - i.e. the users should become developers and developers can extend and experiment with Erlang-Red. It's bit like: Emacs v. Word: users of Word don't extend Word, Emacs users extend and user Emacs.
This idea goes back to my USP: bring visual FBP to a developer community. That's why I originally created flowcompare developers need a structure visual method for comparing flow versions, that's why I created flowhub developers need a structured visual version control mechanism, stakeholders need diagrams, that's why flow2UML.
It's like a child, it's a 7 day a week job, it gets me up early and it requires a lot of attention. But the nice thing is that it doesn't get me out bed in the middle of the night to change nappies or feed it.
But as all good children, eventually it has to be standing on its own two feet and go out into the world, I can't be babysitting it all its life. And so it is with Erlang-Red I will continue on as long as I see a reason to continue. If that goes, then Erlang-Red will gather digital dust.
However, with every new project, I fundamental become more fascinated about how well Erlang and FBP fit. So the experiment will continue for a while yet.
P.S. I worked with Erlang before doing this project. I didn't start from scratch coding Erlang and many of the Erlang concepts were known to me.
