Introducing Phoenix Sync - James Arthur | ElixirConf EU 2025 | ElixirConf EU 2025

Great talk!

For the agent sync, LLM demo at the end, I wonder about the implementation; Is LLM stream being saved multiple times per second to DB, and then streamed to clients? Or is there some other buffering happening?

Nice talk, thanks to James Arthur and his team for heavily contributing to the community and opening it with a real open source license to use!

I am still fresh in the Elixir / Phoenix Realm and bring some experience from other realms with me. So, apologize to mixing up some principles in the following.

I have a couple questions to this, because I was learning Elixir and Phoenix with the believe in that many of modern software development problems were already solved, avoided, or are easy to solve with the framework at hand, leading to less dependent, failure-tolerant, compact and fast code.

The problem James Arthur mentions with the current way of Phoenix LiveView seems that it needs a good handling of PubSub messages under the hood. Coming also from ROS (Robot Operating System), similar issues exist and were resolved by handling every module in ROS as a client itself which can publish and subscribe to certain topics. You have to do that consistently to keep such a system in sync. To formulate it slightly provocative: the issue is that it’s not something that an existing system is easy to move towards to or what is the exact issue with this?
If so, Phoenix.Sync is a convenience out of the box making that possible without doing the hard work, right?

The second issue - where my ROS analogy breaks - is that you cannot control when the client connects to your server, therefore you need a constant stream of the “shape” instead of updates of the “shapes”. That’s understood, but I thought this is also already solved in Phoenix because on mount, the full stream of the particular part gets sent and any message may contain any update of that.

So what’s the problem this additional dependency is trying to solve?

Again, I don’t criticize Phoenix.Sync, but I want to know why I should use this dependency and handle it in the future. Drawing metaphors and asking why’s is my technique to understand it deeply and fully.

One possible answer might be, that – coming from the perspective of the Waterpark talk by Bryan Hunter – a main limitation of todays architecture might be the design of tree-based orchestration with central knots. The team of Waterpark made the other extreme by introducing a routing system through voting which gives every knot the responsibility of a distinct, equally spaced subset of the full datastore.

“Shapes” – at least looking to the definition written in the docs – look a bit like in between by sending (or “fanning”) partition replicas of the datastore to the user clients by in the same time keeping the centralized storage as the source of it, possibly enabling offline or partial-online operability.

Do I understand it correctly?
Also, still the question: which problems does it solve?

Can you be a bit more concrete in which section of the talk the concerns you refer to are mentioned?