Hologram has these concepts built into the framework level - cid (component ID), session ID, connection ID, and eventually user/group IDs. I’d like to explore using these for smart message routing - not sure if that’s possible yet, but it could solve problems like manual message filtering by having the framework handle “right message to right component” automatically.
Your performance concern about throwing away messages is what I’d love to eliminate through intelligent targeting based on these identities. Maybe it’s more “targeted messaging” than traditional pub/sub, but could still use pub/sub underneath.
Honestly, I’d much rather use existing packages wherever possible - this project already has a gargantuan scope! The challenge is that Hologram’s client-server transpilation architecture creates some unique constraints.
The pub/sub system will likely need to be baked into the framework’s inner workings, particularly for security reasons. Since Hologram transpiles Elixir code to run on the client, we need tight control over what gets exposed and how messages flow between client and server contexts.
Phoenix.PubSub can be used at a very low level, but we’ll need an orchestration layer on top of it to bridge the gap between traditional handle_info callbacks and Hologram’s action/command paradigm and component system.
This isn’t just about API differences - it’s about maintaining security boundaries while still providing seamless real-time communication across the client-server boundary.
I appreciate the approach that if we can make it work cleanly with existing tools, that’s always preferable to reinventing wheels! But I’m afraid this is just not possible for this case…
That’s a good idea to explore in the future once there’s a local-first data source layer and some usage patterns emerge. It may happen that it is convergent in some way! Though I’d like to keep the base model as simple as possible - focusing on DX and ease of development - and CQRS / Event sourcing add some architectural complexity. But maybe with some other primitives in place, new patterns can emerge from this?
Authorization needs to happen server-side, which creates some challenges.
We may sometimes need to subscribe dynamically (through commands), but I think the most common case would be “static” - components subscribe on server-side initialization through some DSL, and unsubscribe is managed automatically by the framework.
So probably both patterns: declarative subscriptions for the common cases, dynamic/imperative subscriptions through commands when needed.
Hey, just throwing some ideas out there. I’m much newer to Elixir than you guys so I don’t think in elixir and it’s much easier for me to express my ideas using JS, so I hope that you will forgive me my example, but for me ideal API would be some kind of composable ‘sync’ primitive. Let me show how it would look like in JS (syntax and names are a bit inspired by SolidJS, I know that Hologram works more like React, but it’s just to express idea).
const [notifications, setNotifications] = createServerSignal()
const userId = ‘xyz’
// server signal is derived state that persists on the server
const userServerNotifications = createDerivedServerSignal((notifications) => notifications.filter(n => n.userId = userId))
// I would expect that client ‘signals’ would be able to use any server side signals,
// but this should only work ‘one way’ so ofc I don't expect server signals to be able to use client signals
const userClientNotifications = createDerivedClientSignal((notifications) => notifications.filter(n => n.userId = userId))
Then in template we could use both server side signals and client side signals (server side signals could be ‘wrapped’ in client side signal that does nothing transparently and just returns state on the client side). State flows top to bottom.
The difference between userClientNotifications and userServerNotifications here is that for userClientNotifications I’d expect all notifications to be sent to the client and filtered client side.
If hologram could somehow provide something similar - some composable API that allows to sync some state into the client then I think it would be just great. I don’t think integration with some specific solution (like ElectricSQL) would be a good idea. I think that for start using something similar to what I’ve provided could be good start (basically hologram abstracting transport between server and client).
I think that maybe in the beginning each server ‘signal’ could work like ‘liveState’ (at least I believe that’s how it works) so it would just have the object represented as JSON and send diffs applied to it where server → client boundary is crossed.
For me it would allow to build most of the realtime functionality that I’m interested in for now and the idea is declarative and would be great DX.
Now the question is - is that doable in Elixir (I’m not going to be helpful too much here as most of my Elixir code was vibe coded as I’m working on TS fulltime and only get to use Elixir in my free time for now hah).
I was able to integrate PubSub on my hologram project through Phoenix channels, so it is possible currently. I’ll push my code in a few days, I want to blog about it. I made a skribbl.io clone.
Hi @jonas_h, thanks for the kind words and the nudge!
Short version: I’m no longer planning a dedicated PubSub API. The plan is now Local-First sync for data, plus Server-triggered actions for ephemeral events (notifications, presence, typing indicators, etc.).
Reasoning is in this reply from a few months back - short of it: PubSub for data sync forces you to wire up reconciliation by hand, which is exactly what leads to the bugs people keep running into. A declarative local-first layer handles that automatically. I also covered this in my recent ElixirConf talk - I’ll share the recording when it’s up.
Where things stand:
Server-triggered actions are in progress and will ship in v0.9.0. Low-level primitive for ephemeral events, similar in spirit to PubSub - covers most realtime use cases.
Local-First sync is still in the design phase (discussion here). The end goal is a declarative auto-sync store, so most apps won’t need the low-level primitive at all.
What you can do today: the linked reply also covers workarounds - polling-command + Hologram.JS.exec/1, Phoenix Channels alongside Hologram, etc. @ken-kost’s skribbl.io integration is likely along those lines - looking forward to his write-up.
Thanks for your patience, and glad you’re enjoying Hologram!
The challenge is that Hologram’s client-server transpilation architecture creates some unique constraints.
