# Source code of node red

**URL:** <https://discourse.nodered.org/t/source-code-of-node-red/97962>\
**Category:** General\
**Created:** [4 July 2025 15:29 UTC](https://discourse.nodered.org/t/source-code-of-node-red/97962 "2025-07-04T15:29:12Z")\
**Posts on this page:** 1\
**Showing post:** 30

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [13 July 2025 07:54 UTC](https://discourse.nodered.org/t/source-code-of-node-red/97962/30 "2025-07-13T07:54:22Z")

</div>

> [@lgrkvst](#):
>
> What made you write it, and what would you say are the main USP's? Performance I get, but how?

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](https://jpaulm.github.io/fbp/index.html) (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.

> [@lgrkvst](#):
>
> Are you using Phoenix

No. [Cowboy](https://github.com/gorenje/erlang-red/blob/main/src/servers/ered_webserver.erl), 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](https://github.com/gorenje/erlang-red-elixir-helpers) (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](https://github.com/gorenje/erlang-red-flow-testsuite) to define the standard behaviour of Node-REDs core nodes - that way other projects and test their implementation with a "standardised" visual test set.

> [@lgrkvst](#):
>
> communication middleware?

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.

> [@lgrkvst](#):
>
> Also, did you ever consider breaking the 1:1 between client and server

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](https://ered.fly.dev/node-red?tstid=dc897f402c53697f#flow/dc897f402c53697f).

> [@lgrkvst](#):
>
> Are you using a per-instance process for contexts and node configurations?

Nodes have a per-process context, flow & global contexts can be simulated by using either [statemachine](https://www.erlang.org/doc/apps/stdlib/gen_statem.html) or [gen\_server](https://www.erlang.org/doc/apps/stdlib/gen_server.html). 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](https://flows.nodered.org/node/@gregoriusrippenstein/node-red-contrib-flowcompare) developers need a structure _visual_ method for comparing flow versions, that's why I created [flowhub](https://flows.nodered.org/node/@gregoriusrippenstein/node-red-contrib-flowhub) developers need a structured _visual_ version control mechanism, stakeholders need diagrams, that's why [flow2UML](https://flows.nodered.org/node/@gregoriusrippenstein/node-red-contrib-flow2uml).

> [@lgrkvst](#):
>
> Do you plan to maintain it?

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](https://discourse.nodered.org/t/mqtt-broker-in-erlang-based-on-node-red-code/98087), 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.

---

_[View the full topic](https://discourse.nodered.org/t/source-code-of-node-red/97962)._