The sync engine that streams everything
Point browsers straight at a sync service and clients get to pick their own tables and filters. One missing check, and every customer's rows stream out to whoever asks.
Sleep at nightData foundation
Live updates
Screens update by themselves, and each user only sees their own data.
Changes show up on every open screen in real time. No refresh button, no polling code to write. And every live stream is checked on the server first, so users only ever see their own company's data.
0
query details accepted from the browser
5 min
before every stream must re-prove access
1
checked path for every live feed
3 of 6 in Sleep at night
The problem this solves
Without a shared foundation, every team rebuilds these edge cases — differently.
The removed user who still sees data
Access was checked once, when the stream opened. That person was removed an hour ago. Their tab is still receiving live updates. Access checked once is access that never expires.
The UI that jumps around
A slightly stale update lands over a fresh edit, then the real one arrives and the screen visibly jumps. Your users read that flicker as data loss.
How it works
The mechanism end to end, as implemented in the repository.
- 1
The browser asks by name
The client requests a named feed along with its company and project IDs. Everything gets validated before anything else runs.
- 2
The server checks membership
Login and role are verified, and project feeds are checked against the right company. Failures return errors, never data.
- 3
The server builds the real query
Tables, columns, and filters come from a server-only registry. The sync secret never leaves the server.
- 4
Updates settle in order
Each save returns its database transaction ID. The screen holds its instant change until that exact transaction arrives, so nothing stale wins.
Interactive example
See it working
This walkthrough demonstrates the implemented backend contract without using an account, credentials, or provider calls.
Interactive example
Follow the implemented lifecycle
- Optimistic updateCurrent
- Authenticated writeWaiting
- Authorized ShapeWaiting
- Receipt matchedWaiting
Step 1 of 4: Optimistic update
Deterministic sample data only. No account, provider, or network connection is used by the interaction.
Highlights
Why it matters
The server picks what streams
The browser can only ask for a feed by name. Which tables, columns, and filters it gets is decided on the server.
Access gets re-checked
Live streams expire every five minutes and must re-prove access. Removed users lose their feed at the next check, not never.
No flicker, no jumps
The screen updates instantly, then quietly confirms with the server. Stale data never overwrites a fresh edit.
Engineering guarantees
What this does and does not promise
Safety boundary
This bounds what a live stream can reach. It doesn't audit what your own feed definitions choose to expose, and full checks against a running stack are still a separate release step.
Implementation evidence
The boundary above is code, not a claim. These files carry the contract:
src/routes/api/electric.tssrc/realtime/server-proxy.tssrc/realtime/registry.server.ts
Questions
Frequently asked questions
Related capabilities
These capabilities share contracts and boundaries with this one.
Build on the live updates foundation
The docs describe the same contracts this page demonstrates.