Hey Elixir friends, funny how getting a feature down to a simple one-line call takes two weeks of design work. Sharing what that looked like for Hologram realtime. One slice of the new realtime API - the call for "push an action to every client in a room": put_broadcast(server, {:room, 42}, "page", :append_message, message: msg) The full API is a handful of similarly tight functions for broadcast, subscribe, and unsubscribe. The diagram below is what it takes to set up the SSE connection underneath - and it's just one of six workflows in the design doc. I originally thought the realtime layer would be a thin server-to-client action push and nothing more. But a bare push API would have forced every app to roll its own membership tables or presence layer the moment they wanted something as ordinary as a chat room. That defeats the point of using a framework. Hologram Local-First (on the roadmap) will eventually own most pub/sub use cases - durable, ordered, DB-backed state. But channel-style fan-out has a permanent niche even after Local-First lands: typing indicators, real-time cursors, forced sign-outs - anything ephemeral or non-DB-backed. A pattern I keep running into building this framework: the simpler the public API, the more the framework has to absorb underneath. Most of that work is invisible to the people who'll eventually use it, which is exactly how it should be - but it's also why design like this takes longer than people expect. Anyone else here hit this trade-off building developer-facing tools?