Home / Blogs / WebSockets

Sync a shared editor with operations, not snapshots

A snapshot is the recovery path. It is not the steady state.

A shared pad, a code runner, and a video call are three clocks. They hold together when they stay three systems.

Send operations

A full buffer on every keystroke works until the second person types. Each side then overwrites the other with a snapshot that was already stale when it left the browser. Send operations. Let the server be the sequencer for that room.

A socket library can deliver messages from one connection in order. It does not invent a global order across two typists. The server assigns a monotonic sequence. A client that receives an operation whose parent is not the sequence it has applied asks for a snapshot.

Run is a button

Execute what the user submits, not the buffer mid-keystroke. An explicit run action keeps a half-written function from executing and scrolling the session into a stack trace. A slow run must not block the next character, so the runner is not on the editing socket.

Time belongs to the server

A round that trusts the client's clock lasts as long as that clock says. Store startedAt and the limit on the server. The client renders the difference.

const remainingMs = startedAt + limitMs - Date.now();

The client may display that number. It may not decide that the round is over. When the socket drops, a refetch returns the same startedAt. The round does not restart because the socket restarted.

The call is not the pad

Video stays in its own frame with its own reconnect. Call state does not travel through the editing socket. One blip in the call should not clear the editor. The same idea shows up in doorbell events: realtime signals that something happened. It does not become a second source of truth.

Topics WebSocketsJavaScript