Hey @danlucraft, at least in my reading the majority (although not all) of this post boils down to: “It’s different than stateless request response, and your programming language / stack may not support that well”. Specifically:
Problem: The world is dominated by request-response
Problem: Messaging stacks come with pain
Problem: Your socket will last a while; you need to think about time differently.
Problem: This creates a hard programming model
Problem: This is not PHP land
These are all variations on that theme, and that isn’t really a theme that’s all that relevant to Elixir. Elixir has stateful processes built in and a bunch of tooling to help make that ergonomic. In short, Elixir is already different and already presents a different programming model, it is already not PHP.
Problem: Don’t count on stickiness
Phoenix doesn’t.
Problem: Growing pains
Phoenix scales quite well.
Problem: The cattle behind the proxy
This is a legitimate concern, although depending on where you deploy your orchestrators may already have incremental draining. If not, that was just added to Phoenix.
Conclusions
I think overall perhaps the author has in mind a different use of websockets than Phoenix promotes (LiveView). I also think that the author’s critiques blend concerns introduced by the idea of messaging and state with concerns specific to websockets. That is to say, packet loss happens to HTTP requests too, and if you’re using those HTTP requests to transmit messages to a client then you’ll still need to think about idempotency, “at least once” semantics and so forth.
That isn’t to say there aren’t areas that I think could mature more as time goes on. LiveView doesn’t really offer a built in way to do deployments that change the user front end in a breaking way. But on the whole though the process management tooling you get with Elixir / Erlang gives you a lot of tools and certainly a lot of patterns to address this and other isssues.
