Fwiw I agree 100%.
Instant just posted more info on their approach. Granted they make a bunch of different tech choices (triple stores, clojure, etc) but there are some similarities and the spirit of their DX is nice.
jam
kingdomcoder
Hey, @bartblast
The underlying architecture I’m proposing does not conflict with these concerns you’ve raised, IMO.
I hundred percent agree. As per the example in my original post, MyApp.Support.Ticket.open(subject) runs the same validation fully on the client when you call it from the action. That’s Hologram’s Elixir-to-JS compilation doing its thing.
Syntactic sugar can take care of this:
MyApp.Support.Ticket.open(subject, sync: true) # Writes locally + dispatches a command under the hood
MyApp.Support.Ticket.open(subject, sync: false) # Writes locally only, no server sync
# This can default to whichever makes sense for Hologram
MyApp.Support.Ticket.open(subject)
The framework creates a simple command underneath and handles command dispatch for sync: true.
I consider the Hologram.Extension.IndexedDb in my original post and the Hologram sync protocol you earlier suggested as syntactic sugar for the simple case where Ticket (the server-side resource + validation) and TicketStore (the client-side store) overlap cleanly and are glued together into Ticket.
I don’t view this as “pushing” to the developer. Once again, almost every common case we anticipate can be layered with syntactic sugar on the underlying architecture, while allowing the developer complete control when they need to look under the hood and handle things in interesting ways. The point is: the underlying architecture is command-sync, and that difference matters when the developer needs to step outside the happy path.
One more thought: handling commands when the app is offline is already a problem Hologram has to solve. What happens right now if a user triggers an action that dispatches a command while disconnected? There’s presumably already a queue or retry mechanism in place (or planned). Command-sync simply formalises and extends that existing pattern into a full offline story.
This is a real concern, but it’s not specific to command-sync. Regardless of the approach, offline-capable apps will always need to deal with schema or code migrations that happen while a user is disconnected. Simple cases can come with pre-packaged Hologram solutions e.g. versioning, where the server knows how to handle or reject stale versions gracefully. More complex cases are genuinely hard, and perhaps the developer should actually think about them, but they’re hard for every offline architecture.
1