Any idea how this compares to Supabase's Realtime & Presence libraries?
Reflect – Multiplayer web app framework with game-style synchronization
31–40 of 159 posts
Re: Reflect – Multiplayer web app framework with game-style synchronization
#32Very allagmatic. Instead of storing & transferring structures transfer operations.
Iw as wondering what kind of checkingpoint or snapshotting there might be. Such that one doesn't have to "replay-the-world" if something goes awry (localstack persistence did/l (does?) this, storing state by just recording/replaying API calls). It sort of seems like having a globally accepted state is enough & makes sense, but it still seems like work to rollback & do again, still seems to require snapshotting.
Something like this feels like a 100% fit for having immutable data structures. Where you can snapshot the world very very quickly/at low cost.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#33This technique is pretty similar to Operational Transformations, except that it requires an authority for serialization and must re-apply any state which is out of sync.
It's not the same thing. OT works by having a discrete set of operations that are known to the system so that they can be reordered properly server-side. Reflect is based on Server Reconciliation: https://www.gabrielgambetta.com/client-side-prediction-serve... . The critical difference is that Reflect doesn't need to know the operations up front. That is what allows developers to provide their own operations, or as w…
Well hello there!
Re: Reflect – Multiplayer web app framework with game-style synchronization
#34People might remember this showing up once or twice before as Replicache. Reflect adds a fully managed, incredibly fast sync server. The local-first/realtime space is getting busy these days. Replicache/Reflect is well worth checking out for the beautifully simple data model / coding model. I'm very happy with it. One plus point compared to CRDTs is that you get to decide how you want to deal with conflicts yourself,…
> One plus point compared to CRDTs is that you get to decide how you want to deal with conflicts yourself, with simple, sequential code. I'm not up to date with the latest in CRDT-land but I believe it can be complicated to add application specific conflict resolution if the built-in rules don't fit your needs.
I agree wholeheartedly — we took the same approach for PowerSync with a server reconciliation architecture [1] over CRDTs, which is also mentioned elsewhere in the comments here. For applications that have a central server, I think the simplicity of this kind of architecture is very appealing.
Props to Aaron for bringing awareness to and evangelizing server reconciliation.
[1] https://www.gabrielgambetta.com/client-side-prediction-serve...
Re: Reflect – Multiplayer web app framework with game-style synchronization
#35If you want true concurrency, in an elegant format, with a lot of the common problems abstracted away -- use Erlang. They solved this 30 years ago.
Someone should bring those logics to js and java then. Ehm, please.
Someone has!
https://github.com/untu/comedy
However to the below point, Bolt ons are never as good as baked ins. This is especially true for concurrency.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#36Looks great, congrats on launching. Is this in a similar vein to https://partykit.io/ ?
Yes they are in the same space. The key difference is in how opinionated each is.
PartyKit is extremely unopinionated. It's essentially lightweight javascript server, that launches fast and autoscales (I don't say this as as a bad thing, it's a useful primitive). Most people seem to run yjs in PartyKit, but you can also run automerge or even Replicache – my company's other project.
Reflect is entirely focused on providing the best possible multiplayer experience. We make a lot of choices up and down the stack to tightly integrate everything so that multiplayer just works and you can focus on building your app.
That's the plan anyway :).
Re: Reflect – Multiplayer web app framework with game-style synchronization
#37I need a simple explanation like i am 6 years old because i have a mind of a 6 years old.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#38Hey hacker news! I'm one of the people behind this, happy to answer any questions.
What does this mean for Replicache development, is the client-side codebase mostly shared and can expect continued updates, or more likely to replace the primary focus for you?
Re: Reflect – Multiplayer web app framework with game-style synchronization
#39Hey hacker news! I'm one of the people behind this, happy to answer any questions.
Congrats! I've been watching this space for a while, having built a couple multiplayer sync systems in the past in private codebases, including a "redux-pubsub" library with rebasing and server canonicity that is (IIUC?) TCR-like. There's a lot to like about this model, and I find the linked article quite clear - thank you for writing and releasing this!
1. You wrote "For example, schema validation and migrations just sort of fall out of the design for free." - very curious to read about what you've found to work well for migrations! I feel like there's a lot of nice stuff you can build here (tracking schema version as part of the doc, pushing migration functions into clients, and then clients can live-update) but I never got the chance to build that.
2. Do you have a recommendation for use-cases that involve substantial shared text editing in a TCR system? I'd usually default to Yjs and Tiptap/Prosemirror here (and am watching Automerge Prosemirror with interest). The best idea I've come up with is running two data stores in parallel: a CRDT doc that is a flat key/value identifying a set of text docs keyed by UUID, and a TCR doc representing the data, which occasionally mentions CRDT text UUIDs.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#40Any idea how this compares to Supabase's Realtime & Presence libraries? https://supabase.com/docs/guides/realtime
We'll post something soon comparing all of the options (in our opinion). But as I understand it:
- Supabase Broadcast: one client sends every other client a one-time message
- Supabase Presence: one client tells all other clients that its own state has changed. This is similar to above, except that server keeps track of all the last-state for each client so that new members of the channel can get up to date.
- Supabase Realtime: server tells all clients when server state changes (so you will not get optimistic client-side changes this way)