Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflect – Multiplayer web app framework with game-style synchronization

rocicorp.dev

Post reply on HN
Print view View original

11–20 of 159 posts

Re: Reflect – Multiplayer web app framework with game-style synchronization

#11

Post by jakelazaroff »

chrisweekly wrote: post #7

Interesting alternative to CRDTs, "Transactional Conflict Resolution". Bookmarked.

It looks very slick, and I'd probably be interested in this if I were building a centralized local-first app. But I think this serves a fundamentally different use case vs. CRDTs. Reflect says "Your mutation code runs server-side and is authoritative" (emphasis theirs).

- If you can have an authoritative server, CRDTs come with unnecessary restrictions and overhead. Reflect presumably gains a lot of efficiency by loosening those constraints.

- Conversely, if you want clients to collaborate without a central server, you can't use a service like Reflect, since there's no server to run your conflict resolution logic.

Re: Reflect – Multiplayer web app framework with game-style synchronization

#13

Post by matlin »

While I do love the simplicity of this approach on the surface. Some of the complexity gets brushed under the rug.

Firstly is rebasing these operations in this style of system takes a bigger hit on performance than I expected in my experience. Sure, managing counters and doing integer math can consistently run at 120FPS but more complex operations can really bog down the system when a lot of users are interacting with it once.

The second challenge is that when operations fail (e.g. for authorization) undoing that operation isn't always straightforward. You either pop the operation and replay ops from a earlier snapshot (which necessitates storing all ops in order), writing an inverse operation manually, or having the server send the entire state back to rebase your unconfirmed ops on which can also end being expensive.

In general, the challenges of this approach are true for all operation-based CRDTs too. State-based approaches are a good deal simpler just tend to over-send data over the network.

Re: Reflect – Multiplayer web app framework with game-style synchronization

#14

Post by aboodman »

jakelazaroff wrote: post #11
chrisweekly wrote: post #7

Interesting alternative to CRDTs, "Transactional Conflict Resolution". Bookmarked.

It looks very slick, and I'd probably be interested in this if I were building a centralized local-first app. But I think this serves a fundamentally different use case vs. CRDTs. Reflect says " Your mutation code runs server-side and is authoritative" (emphasis theirs). - If you can have an authoritative server, CRDTs come with unnecessary restrictions and overhead. Reflect presumably gains a lot of efficiency by lo…

Absolutely – CRDTs have some unique benefits, this among them. I recommended a potential user to CRDTs a few weeks ago.

But most apps people build today do in fact have a central server. And by leveraging that you can get some really nice benefits.

Re: Reflect – Multiplayer web app framework with game-style synchronization

#17

Post by aboodman »

matlin wrote: post #13

While I do love the simplicity of this approach on the surface. Some of the complexity gets brushed under the rug. Firstly is rebasing these operations in this style of system takes a bigger hit on performance than I expected in my experience. Sure, managing counters and doing integer math can consistently run at 120FPS but more complex operations can really bog down the system when a lot of users are interacting wit…

Hey Matlin, it's true that this approach is harder to implement, but that's a one-time cost, and it's one we take on for our users and they don't have to worry about.

Re: Reflect – Multiplayer web app framework with game-style synchronization

#18

Post by jakelazaroff »

aboodman wrote: post #14
jakelazaroff wrote: post #11

Earlier quoted context omitted.

It looks very slick, and I'd probably be interested in this if I were building a centralized local-first app. But I think this serves a fundamentally different use case vs. CRDTs. Reflect says " Your mutation code runs server-side and is authoritative" (emphasis theirs). - If you can have an authoritative server, CRDTs come with unnecessary restrictions and overhead. Reflect presumably gains a lot of efficiency by lo…

Absolutely – CRDTs have some unique benefits, this among them. I recommended a potential user to CRDTs a few weeks ago. But most apps people build today do in fact have a central server. And by leveraging that you can get some really nice benefits.

Yeah, it's interesting to me how from a user's point of view both technologies do something similar, but from an architecture point of view the use cases are mostly disjoint. I totally agree that something like Reflect makes more sense for most apps people build today.

Anyway, congrats on the launch! Reflect looks great. I'm really excited to see the building blocks emerge for local-first software.

Re: Reflect – Multiplayer web app framework with game-style synchronization

#20

Post by aboodman »

pensono wrote: post #16

This 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 we call them "mutators".

Post reply on HN