Using Elixir/Phoenix as a super-charged "process manager"+framework around nodejs processes

Usually people around here want less JavaScript, not more.

The problem is not PM2 it is just a symptom of nodejs/javacript not really being made for serverside work. You have to do all sorts of crazy and complicated things as a consequence of that.

You can certainly build what you are suggesting, but I don’t think it is where Elixir/BEAM shines.

I guess there are quite a few people around here using it in a similar way.

In our case, we use elixir / phoenix to provide a websocket based api for machines, as well as a basic web based UI for various native apps on a RaspberryPi. As long as you can control another process via a proper API, elixirs supervision trees are pretty awesome to manage and control all those dependencies.

I would love a Phoenix-powered React Server Components implementation, which would also be “live” as in LiveViews-live.

I experimented with something like that, by putting a Next.js server behind a Phoenix reverse-proxy. So basically a web request hits Phoenix, I use Ecto to load up the data, then use POST to send that data to Next.js handler, and stream the Next.js-generated response back to the client browser connected to Phoenix. This works and is pretty simple, in fact I was surprised how simple it is. But this is still running a Next.js server with all it’s bugs and issues it has, eventually I decided against actually pushing this forward in any way.

There’s a tiny library which I was going to try, but never did, that integrates LiveView with React: GitHub - fidr/phoenix_live_react: Render React.js components in Phoenix LiveView views · GitHub

As far as I understand, it doesn’t have any server-side rendering of React components, but you can somewhat build React Server Components-like behavior but also somewhat better with it using LiveViews.

The comopnents you mount this way will receive updated props from LiveView when it updates, and can send back events to LiveView.

What would be super cool is that these components could be pre-rendered, possibly using Bun or Node or some other JavaScript implementation and then hydrated. I believe that’s doable with something like you are suggesting.

Also, note that the LIveView state management and change tracking differs significantly in in principles from what React is doing. There are reasons for that, obviously, as avoiding re-rendering everything is somewhat more imporatant when the code sits on the server.

But another thing to try, would be to build something LiveView-like that is, however, using more React-style state management, for conceptual consistency if nothing else. Even if the code would be written in Elixir instead of JavaScript, having similar concepts of Hooks (as in useState) rather than implicit change tracking would be helpful and reduce the learning curve a lot.

Anyway, a lot of ideas, very little time to try them out.

I’d rather let the OS manage the services’ lifecycle and use Unix domain sockets for inter-process communication. I’m always trying to not reinvent the wheel. Make your services behave like proper daemons instead of half-arsing solutions.

I would encourage you to check out LiveState if you’re interested in exploring these ideas. The idea of LiveState is to give you the same state management via light-weight processes in Elixir leveraging Phoenix Channels, but allow you to do simple client side rendering for situations where that is preferable. Many of the examples use custom elements, but its easy to use with React, or even with simple client side templates in html using live-templates. It’s fairly mature at this point, and is actually quite simple as it is a thin veneer over channels for the most part.

Oh, that’s interesting. Could you elaborate on that?

Nice! So supervision trees are what differentiates the BEAM runtime from other runtimes in terms of process management? Does it automatically respawn crash processes, and can it (or some other abstraction) deal with pooling and some kind of auto-scaling?

What I understood from your post is you are looking for goodness of both worlds. Though I have seen some React integrations, the best JS framework integration into Phoenix would be woutdp/live_svelte: Svelte inside Phoenix LiveView with seamless end-to-end reactivity (github.com) -You get server side rendering, mix and match of Live Components and Svelte Components, animations everything.
I just thought if someone will do a port of that to React. That might make the React Component World come alive in the Phoenix.
Ofcourse, many people here would instead dream of a LiveView Component Library that matches the React world!!

Oh, livestate does look interesting! Thanks for pointing it out. So, if I got it right, you’re suggesting still spawning nodejs processes for SSR rendering of React, but then using livestate to render updates that are controlled by Elixir itself?