What real time actually has to mean
Polling every ten seconds is not real time, it is a slower refresh button. What it took to push every change over one socket — and to survive the gaps.
By The Conexus X team
Collaborative tools like to claim real time when what they mean is a timer. A poll every ten seconds is a refresh button someone else is pressing for you: cheaper to build, and it still shows a colleague's edit ten seconds after they made it — long enough to type over it.
One socket, one identity
Every browser tab holds exactly one connection. That sounds like an implementation detail and is really a product rule: the connection is how presence is decided, so a second socket would be a second identity, and closing one tab would report you offline while the other sat open.
Connecting is also the heartbeat. There is no separate timer beating every sixty seconds to say you are still here — being connected says it.
Patch one row, refetch anything structural
When a change arrives there are two honest responses. If the message is the whole truth about one row — a cell's new value, a rename, a comment count — it is patched straight into the cache and nothing is requested. If the change is structural — a row appearing, moving or disappearing, a column added — that data is marked stale and refetched.
The split matters because structural changes touch ordering, server-computed counts, and values derived from other people's records. Hand-patching those means reproducing the server's arithmetic in the browser and keeping the two identical forever, which is a bet nobody wins.
The part everyone forgets: the gap
Connections drop — a tunnel, a sleeping laptop, a flaky cafe. A client that reconnects has missed everything in between, and there is no replay. So on every reconnect, not only the first, the app treats what is on screen as stale once and refills it.
Pushes are what make it feel instant. Resyncing on reconnect is what makes a missed push survivable.