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:

1. Server-Triggered Actions - Enable triggering actions from server code outside of commands, such as background jobs (e.g. Oban) or scheduled tasks.
2. 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

The polling is needed because proper JS interop (Time for Hologram <> JavaScript Interop - What Would You Like to See?) hasn’t been implemented yet.

Hope this helps!

Sync is not trivial; there are certain guarantees the database has to be able to make.

In addition to ElectricSQL (for Postgres) there is also @jstimps 's work on EctoFDB Sync, and then there’s my work on Hobbes which is more foundational (implementing a DB from scratch).

I would suggest @bartblast try to come up with a design that is general enough to support any backend, but that may actually be somewhat difficult. For example, Postgres can be incrementalized (ElectricSQL does this with WAL parsing) but FoundationDB on the other hand cannot. This concern leaks into the framework layer because if Hologram runs on the client you want to maintain the view on the client, so it can’t be oblivious.

My hope is that Hobbes can provide an Elixir-native database primitive here (with proper incremental support) so that framework designers like Bart do not have to worry about database correctness stuff (which can get pretty in-the-weeds I’m afraid). I am making good progress on that front. Soon!

I think that no matter what there will be need for some sync/realtime communication primitive not involving DB because otherwise you’d not be able to work with big part of the ecosystem (like Presence) and existing tech.
Even if this primitive would not give as many capabilities as some ‘blessed’ solution (like some nice DB integration) right?
Because otherwise we’d be saving things to DB just to get sync and not persistance. I’ve seen some of your posts and know that very likely You have this thought out better than me so I’ll ask - do you think that with good enough DB solution (maybe something built on top of Hobbes that you’re developing) it would be practical to push everything you want to sync into DB? Presence / cursor positions / realtime stock prices etc etc.
All of those are very simple data (not derived data or some aggregates), so some solution that would just be synchronizing state kept on the server with client would suffice but as you’ve said my intuition is heavily influenced by RDBMS so I might have completely wrong idea about it and maybe DB might be a good place for ephermal data too.