Live data from Hacker News

Reflect – Multiplayer web app framework with game-style synchronization

rocicorp.dev

91–100 of 159 posts

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

#91
post #2

Hey hacker news! I'm one of the people behind this, happy to answer any questions.

What is the maximum number of users that can be concurrently in a room?

There's no max enforced. Right now, it will fall apart pretty quick around 25-50, depending on how much work is going on.

For the GA, we plan to implement a scheme that will allow the room to support up to ~100 concurrent active users (actually doing things) and thousands just watching.

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

#92
post #82

What’s the transport for this? Websockets? I have a hard time imagining 120 messages for 100 clients over websocket in a CF Durable Object, but maybe I’m just completely misimagining.

It's websockets, and yes we do make use of Durable Objects. But we do extensive batching and buffering on top of the raw platform. You can't literally send 120 messages / second to and from 100 concurrent clients. Actually the math tops out at about 8 :).

Can you explain what are the limitations in Durable Objects?

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

#93
post #84

Can this be used to let multiple people edit a very large image concurrently?

Depends what you mean by very large. Reflect can store up to about 50MB/room. For a PNG, that's "fairly large" I guess. We plan to increase this limit in the future.

You'd have to split up the image into chunks of about 1KB each, this would be fairly easy to do by pixels. It would be a fun project to try.

See https://hello.reflect.net/rooms#data-model for more information.

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

#94

Earlier quoted context omitted.

You don’t even need to involve deletes; if all of these happen “simultaneously”: - client A appends “a” to list L - client B appends “b” to list L - client C appends “c” to list L the server will arbitrarily apply the appends in some order, and then send the result back to the clients. But, each of the clients has applied its append locally and is showing those results until it gets different information from the ser…

You modified the operations, I specifically chose a scenario where User C (in my example) introduces an undecidable situation. Appends are trivial to solve. >If your answer is like "we just send them the whole array again", this breaks the transactional model (x2). You also did that, whoops.

True. I was thinking of a simpler criticism that, if it held, would also make Reflect less useful. aboodman replied in the sibling that (of course) they thought of that, so my criticism doesn't apply.

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

#95

Earlier quoted context omitted.

Also just as an FYI we do have this running live at https://reflect.net and https://hello.reflect.net/examples at 120 FPS. We are targeting 100 concurrent users at 120 FPS. Not completely there, but it is certainly achievable, and we will scale back framerate when we need to.

So are you using fps management just for scaling purposes or also as a way of ensuring fairness? The reason I ask is because games like Forza have had to resort to setting all online players' frame rates to be the same regardless of their machine's capabilities due to the way the in-game physics work. PC players on high end hardware would consistently get better lap times than Xbox users because of it. Maybe this is…

Huh! That's interesting. I don't think this applies to the type of collaborative apps (ie figma) we are targeting, but it's fascinating to know. Thanks!

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

#96
post #64

How does one handle an upgrade to mutators? If a client is running old code then the operation will differ to the server. Obvious answer would be to version them independently: `increment_v1`, `increment_v2`, but wondering if there is a better answer?

At the moment there is no better answer than do not remove your old mutators until you know there are no more clients out there that might have pending changes.

Right now that window is pretty small because we haven't turned on persistence yet.

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

#97

Earlier quoted context omitted.

Whoops, you're right, Is the solution to that, a) [1] or b) [1, ] ? >Notably, the server has to sequence actions somehow [...] Yes, that's my whole point, you have to fallback to something like LLW, and then it's over for the transactional model :P. Edit: Btw, I'm not trying to be the snarky, pessimistic dude. This kind of models are really interesting and I love working with them. I am just trying to illustrate how…

No, the server is going to process the actions in a single queue. So again, it's whatever action arrives first.

Then it's LLW and you're no longer playing this game.

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

#98
Looks great for a hobby project.

Has anyone done the cost + risk assessment of building a for-profit product on top of this? Would love to know, as I am working on a web IDE with collaboration. There’s also the matter of obscuring client data from 3rd and even 1st party.

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

#99
post #90

This looks great! I'm curious what the recommended use cases are for something like this. Is it worth adding the additional complexity for complex crud-y saas? I know Linear is built on this local-first model but from seeing their presentations on the challenges they've had scaling it, I'm left wondering if it makes sense for something like a full-featured CRM with hundreds of tables. Is Reflect/Replicache suited for…

We have an old demo of our Linear clone using Replicache at https://repliear.herokuapp.com/

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

#100

Earlier quoted context omitted.

No, the server is going to process the actions in a single queue. So again, it's whatever action arrives first.

Then it's LLW and you're no longer playing this game.

I don't know what LLW means, but you seem fixated on the acronym. It's just first come, first serve transaction ordering from the world I come from.
Post reply on HN