I’m aware that many features in phoenix and liveview rely on distributed erlang features such as process groups, Mnesia, and ETS.
If I have a simple deployment and don’t have any connectivity between my nodes, how can I expect a LiveView app to behave when multiple instances are deployed and load-balanced?
How does this change in the case that I have session stickiness in the load balancer vs when I don’t? I imagine pubsub between multiple clients would not work as there is no way for them to share messages.
Trying to get an idea of what I might need to setup on the infrastructure side.
Good news! This isn’t really true. Phoenix does rely on :ets but :ets isn’t distributed. It doesn’t use :mnesia at all and the process groups stuff is optional.
This just depends on the phoenix pubsub backend you choose. Phoenix.PubSub — Phoenix.PubSub v2.1.3 If you pick redis and sticky sessions it should all work without erlang distribution.
Correct. If the servers have absolutely no way to communicate they can’t deliver messages to other clients connected on other servers and they won’t know about those servers.
If they share a common DB then you can create PubSub using Oban via Postgres pubsub to deliver messages and notify other nodes which can then notify their connected clients. Oban will make use of distributed Erlang if available but Postgres based pubsub can be used when in an isolated mode (that is, unless you’re using pgbouncer then you won’t get the necessary Postgres events).
Whilst this will be orders of magnitude slower than connected cluster the performance is still quite good for many use cases. A benchmark of 1 million jobs per minute is achievable on a very modest system. That is a single queue on a single node on an Apple M1 Pro laptop. Obviously running server class and multiple queues or multiple nodes can achieve dramatically higher throughput.
There is also some great clustering libraries for Elixir/Erlang, the phoenix dns_cluster package can leverage DNS for node discovery instead of Erlang EPMD.
