The sync engine pointed straight at the browser
Let a client choose its own tables and filters and one missing check streams every project to whoever asks. Here the browser sends a feed name and nothing else; the query is built on the server.
The foundation under itData foundation
Live updates
A colleague’s change lands on your screen, and only on screens allowed to see it.
Documents, tasks, forms, automations, projects and the progress of long jobs stream to every open screen as they change. You do not press refresh, and nobody writes polling code. Each stream is opened by the server against a fixed table, fixed columns and our own project, so a feed can never reach further than the person watching it.
0
query details accepted from the browser
5 min
before a stream must prove access again
10
named feeds in the server-owned registry
3 of 22 in The foundation under it
The problem this solves
Without a shared foundation, every team rebuilds these edge cases, differently.
The person who left an hour ago
Access was checked once, when the stream opened, and their tab is still receiving updates. Access checked once is access that never expires. Five minutes is the longest that can last here.
The screen that jumps
A slightly stale update lands over a fresh edit, then the real one arrives and the text visibly changes twice. People read that flicker as lost work, and they are not always wrong.
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 the organization and project it believes it is in. All of it is validated before anything else runs.
- 2
The server checks membership
Your session and role are verified, and a requested project is checked against the organization that claims it. A failure returns an error, never rows.
- 3
The server builds the real query
Table, columns and filters come from a server-only registry, and the sync secret is attached server-side. None of it is visible to the page.
- 4
Updates settle in order
Each save returns the PostgreSQL transaction ID it committed under. The screen holds your instant change until that exact transaction arrives.
Interactive example
See it working
This walkthrough demonstrates the implemented backend contract without using an account, credentials, or provider calls.
Interactive example
Follow the steps this actually runs
- 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 asks for a feed by name. Which table, which columns and which filters that name means is decided by a server-only registry.
Access is proven again every five minutes
Streams are cut at five minutes and must re-prove membership to continue. Someone removed from the project loses the feed at the next check, not whenever they close the tab.
Your own edit never flickers
Your change appears at once, then waits for the exact database transaction that saved it before settling. A slightly older update cannot win.
Engineering guarantees
What this does and does not promise
Safety boundary
Growth Kit records are not on the live stream today. Accounts, meetings, decisions, campaigns and finance entries refresh on their next read, not the moment a colleague saves. Ten feeds stream live: documents, forms, automations, projects, organizations, content buckets and items, variables, and process runs and milestones.
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
Used alongside this
These capabilities share contracts and boundaries with this one.
What live updates rests on
The docs describe the same contracts this page demonstrates.