Thanks for the thoughtful response! I really appreciate the detailed API suggestions.
I definitely think about this in a similar way - actions and commands could be pubsub message handlers. This feels like a natural extension of the existing patterns.
I like the idea of something similar to put_pubsub/delete_pubsub approach, and I think there should be a possibility to subscribe/unsubscribe dynamically. But shouldn’t there be some component/page level DSL for that, so that the subscribing and unsubscribing is handled automatically (declaratively instead of imperatively)? I’m thinking about lifecycle management - it would be nice if developers didn’t have to manually track and clean up subscriptions in most cases.
Yeah, absolutely. Pages are basically a special case of components, so this will be available in any page or stateful component (one that has a cid). No reason to artificially restrict this capability.
I can agree with that approach for general pub/sub. Though I think we need a way to send targeted messages - e.g., when a background job is finished and needs to notify a specific user session or component. Using pub/sub semantics for that would be too much overhead/boilerplate. I’d like better semantics for that use case - maybe something more direct than the broadcast model.
I would strongly caution against getting caught up at the wrong level of abstraction here. You should be thinking about how to provide users with declarative APIs for managing any type of resource, not just PubSub subscriptions. If you have the former the latter becomes a natural extension.
Look at how React evolved from lifecycle callbacks to hooks with cleanup functions. This article provides a more detailed take on the topic (see the “Strange Effects” section in particular). Note that the author has in his own work adopted this paradigm to interface with graphics APIs (which are some of the worst APIs ever written).
The first rule with macros (and therefore DSL) is to not use them unless they are really needed. If we are going to let developer do this by hand (which is important in complex cases like tabbed pages) then there is really no need to duplicate the feature and introduce new DSL. Said macro would need to have some unique feature or use case.
It’s also important to mention that depending on case people may want to start pub/sub on both server and/or client and send data from server to client or from client to server. I believe in games (validated messages coming from trusted source) it may be important i.e. pub/sub logic may be happening on server while game logic (like drawing) would happen on client).
I fully agree with that. We definitely need some low-level API for sending commands and actions especially if we talk about background processes. Pub/sub may use such low-level API too.
You nailed it here on the dynamic subscription. I recently had that use case: initially subscribe to a specific livestream, dynamically subscribe/unsubscribe to live chat messages when the livestream starts/stops.
I love this. If the state is available, a declarative solution can work. I can imagine something like:
Yup, those clauses would handle most of use cases if not all (assuming that all communication goes through actions and commands).
Nope, it needs to be a quoted expression which evaluates to boolean. This is important since such quoted expression needs to be unquoted somewhere and Hologram does not uses custom def or action and command DSL which means there would be lots of extra work, breaking changes and decrease of flexibility since it’s not easy in Elixir to override same function multiple times, so it could potentially break any existing def overrides.
How do you deal with params and client/server states in DSL?
How to avoid confusion with module attributes?
Developers already use at character (@) in templates and they are just used to it, but DSL is completely different topic. Many DSL supporting using module attributes and this would be extremely confusing. It would be the most commonly known gotcha in Hologram.
Doing that without DSL becomes simple and much more clear solution, so many people would have all rights to say that using DSL is rather a bad practice. That’s exactly why I said that without a really good reason we shouldn’t force it.
I understand the appeal of the “safe” approach, but copying Phoenix’s pubsub patterns mainly for familiarity is a dead end IMO. Whatever we ship becomes something I need to maintain long-term, and building on borrowed design decisions that don’t fit Hologram’s architecture creates technical debt from day one.
The migration story isn’t really about API similarity anyway. Pub/sub has a small surface area - you subscribe to topics, handle incoming messages, and maybe do some authorization. The specific function names matter less than getting the core patterns right. Whether someone calls Phoenix.PubSub.subscribe/2 or put_pubsub/3, they’re still just expressing “listen to this topic and run this code when messages arrive.”
I’d rather spend the extra design time upfront to create something that fits naturally with Hologram’s component model and action/command patterns. The migrations will be straightforward regardless since the conceptual mapping is simple.
You’re absolutely right that it starts with my vision - I do have ideas about where I want Hologram to go. But it would be a big mistake for me not to listen to feedback from others along the way. If I only built for my own specific vision, I’d end up creating a framework tailored to just one version of myself and my particular use cases.
I’ve got limitations - including ones I’m not even aware of - and my perspective is naturally limited to what I’ve been exposed to. The experiences you’ve shared and your perspective on these trade-offs are genuinely helpful as I think through this. Because of that, I really value you sharing your vision and perspective, even though I don’t agree with some of them. But I’m definitely open to changing my mind!
I don’t think it’s entirely accurate that Phoenix PubSub “sends all messages to all nodes in order to get them to the right user.” Phoenix PubSub maintains awareness of which nodes have active subscriptions to which topics. When you broadcast to a topic, the message is only sent to nodes that have at least one process subscribed to that topic - not to all nodes in the cluster. Each node maintains a local registry of which processes are subscribed to which topics, and nodes communicate subscription information to each other so they know the topology of who’s interested in what.
In Hologram’s case, this could work well since Hologram clients (with their unique connection IDs) could act as nodes in this distributed system - each maintaining their own subscription state and participating in the routing topology.
You raise a valid point about complex routing requirements like “subset of cursors to subset of users.” But that feels more like an argument for having richer topic semantics rather than abandoning the pub/sub model entirely. Topics could be hierarchical, pattern-based, or support more sophisticated matching - similar to how message brokers like RabbitMQ handle complex routing.
Interesting idea… but I wonder if it’s essentially solving the same fundamental problems that Phoenix PubSub already handles:
Discovery: How do you find the right GenServer? (topic-based routing)
Distribution: What if the GenServer is on a different node? (distributed registry)
Failure handling: What if the GenServer crashes? (automatic cleanup)
Scalability: What if you have thousands of rooms? (efficient ETS-based lookups)
Phoenix PubSub provides battle-tested solutions for exactly these challenges. The GenServer approach would need to reimplement much of this infrastructure.
I think we might be looking at different layers here. As I mentioned earlier in the thread, pub/sub is a messaging primitive - useful for the cases where its semantics make sense (ephemeral events, notifications, real-time updates where eventual consistency is acceptable). It’s not meant to be the foundation for all data synchronization, just a tool in the toolkit.
Your database-centric approach makes perfect sense for stateful, consistent data. But I still see value in having both patterns available, with clear guidance on when to use which.
You’re right that this optimization is possible. I don’t know the Phoenix PubSub internals but it makes sense that they would use it.
But I think you’re overestimating how helpful this actually is. Imagine you have 100 nodes and 1000 rooms, where each room has 100 users. Users are load-balanced across nodes, randomly.
Because the assignment of users to nodes is unaware of the assignment of users to rooms, the average number of nodes exchanging messages for each room will be quite large. This is just topologically wrong.
This matters in a high-performance context. Things like voice/video chat, game servers, really complicated multiplayer apps like Figma, etc. Remember, for even moderately complex stuff my answer was “use Phoenix Sync”!
I would be very interested in a counter-example here. An app in a category like those above which fans messages out across nodes in this way. I am unable to come up with anything.
And in the limit they would use turing-complete code for routing. There is a certain point at which I would argue this just isn’t PubSub anymore. But if you want to call that “thing” PubSub then I am fine with that “thing”!
We are a bit in the weeds here but what I am really trying to say is:
PubSub is not a very good messaging primitive. A much better messaging primitive is: messages!
And BTW this was my other question. Phoenix PubSub does already provide PubSub, so why does Hologram need to re-implement it again?
I think in general an application framework should be focused on providing general solutions so that users can integrate with something like PubSub if they want to. It sounds like you instead want to provide an opinionated PubSub implementation as a core Hologram feature, and that’s what I don’t really like because I don’t think PubSub is all that great!
I think if you do want to provide something opinionated and tightly integrated the IVM stuff as discussed earlier is a better path. But it is of course more work (often true of things which are better).
