Hi @bartblast I am super excited to use Hologram and started building my application in Hologram.
For pages that I dont need realtime updates, I am able to use Holograms but for ones that need realtime updates i am unable to use hologram am I missing something here.
Is there support for Realtime serverside updates like LiveView Updates, Phoenix Sync and support for Live Data Streams from Server side like in LiveView ?
Use-case for live chat applications and live dashboards update.
If the support isnt there yet what would you suggest for such usecases ?
PhoenixSync is built on top of ElectricSQL, which parses the Postgres WAL and streams subsets out to clients. You can use the Electric client directly to stream updates. I don’t know Hologram’s APIs well but I believe there is some way to push those updates down to the client. Then you can materialize the view yourself client-side.
There are also some (me) working on databases that natively support partitioned WAL streaming, so that will be an option someday!
Hi @krezicoder!
Great to hear you’re building with Hologram!
You’re not missing anything - currently, data from the server can only be sent in response to commands. Server-initiated updates aren’t supported yet, but there are two features on the roadmap that directly address your use cases:
Server-Triggered Actions - Enable triggering actions from server code outside of commands, such as background jobs (e.g. Oban) or scheduled tasks.
Local-First Support - Implement local-first architecture with offline-capable local database, auto-sync, and conflict resolution for resilient applications.
Initially I planned to provide a PubSub API, but after deep exploration and Time to Implement Pub/Sub in Hologram - Looking for Your Input!, I shifted toward a local-first auto-sync approach - along the lines that @garrison advocated in that thread. The key insight: using PubSub for data sync forces you to manually wire up message passing and maintain synchronization yourself. This leads to bugs and tangled imperative synchronization code. A local-first layer gives you declarative, automatic sync - data just appears in your components when it changes, no manual routing needed. You want top-down data flow from a central source of truth, not component-to-component messaging.
We’d still have Server-Triggered Actions for ephemeral events (notifications, typing indicators) where they make sense - playing a role similar to cast (fire-and-forget, no delivery guarantee).
The local-first space is enormous and I’ve been analyzing it for some time, hence the silence on this topic.
What you can do today
With some creativity, you can support your use cases now with a combination of these:
Polling command - a command that periodically checks for updates from the server using the delayed param
Phoenix Channel alongside Hologram - store channel events in a global JS object, then read from it via Hologram.JS.exec/1 in a polling action
Hologram.JS.exec/1 for general but basic JS interop
I’m all for syncing but what if you’re not using ElectricSQL (f.e. because you don’t have Postgres).
I’m looking into hologram for ‘kanban’ like board where each task is separate Genserver.
Initially I’ve had this written with Postgres+Electric+Phoenix+Separate FE, but after giving it some thought I’ve dropped PG in favor of SQlite (because I’ll usually be running it locally anyway) so that means I’ve lost access to PhoenixSync and its’ niceties.
Generally polling won’t be good enough for this usecase in a long run so it would be nice to have some recommended solution that wouldn’t necessarily tie you into syncing (I guess in my particular case I wouldn’t care if Phoenix Sync had SQlite backend ;-
EDIT. depending on how this ‘sync’ layer would be implemented, if we could plug into it ourselves somehow (so I can write code responsible for ‘syncing’ Genserver) that would work for me too.
