Design patterns for shared state with many to many streaming

488 views Asked by At

I'm writing an online whiteboard application for fun, where multiple users view the same whiteboard and can draw on it. I'm using websockets (vanilla JS on the frontend, Scala on the backend), and right now am essentially just broadcasting mouse events from one user to the rest of the users, and rendering the image client-side.

However, this results in a transient shared state, whereas I would like to have users be able to hop on at any time and see the preserved shared state. I'm thinking this will probably require having shared rendering code on the backend and the frontend, so that clients render events as they stream but the server can send raw image data when clients associate.

So my question here is: what are some other design patterns I should be aware of for this kind of project? This is a for fun/learning project, so this is an open-ended question, but I'll accept an answer that contains some useful references for this kind of data flow.

1

There are 1 answers

3
jfriend00 On

So my question here is: what are some other design patterns I should be aware of for this kind of project?

You don't have to have rendering code on the server. You can just save all the accumulated events that led to the current whiteboard and send those to a new client and let the new client render the whiteboard for itself as if they were listening when all the events originally happened.

If that's more data than is practical, then you can compress raw events. For example a straight or nearly straight line segment does not need all the intervening mouse positions, it really just needs the first and last position of the segment.