Live Queries
The shop manager keeps a dashboard open: the price of The Quiet Ledger and its three latest ratings. She does not care about each individual event; she wants the numbers on screen to always be the current ones. A subscription can be bent into doing this, but the idea she is describing has its own name: a live query.
The rule
Subscriptions say what happened; live queries say what is true now.
A live query is an ordinary query that the server keeps fresh. The client sends it once, gets a normal result straight away, and then gets an updated result whenever any data that the result depends on changes.
Live queries are not part of the GraphQL specification. Several servers and libraries offer them, most often through a directive on the operation:
query ManagerDashboard($id: ID!) @live {
book(id: $id) {
price
reviews(first: 3) { rating }
}
}Compare this with the reviewAdded subscription:
| Subscription | Live query | |
|---|---|---|
| First message | Nothing until an event | The full current result |
| Each update | One event's data | The whole result, as it is now (or a patch to it) |
| Client's job | Merge events into what it has | Just show what arrives |
| Standardised? | Yes | No, server-specific |
The convenience has a price on the server. It must know which records each live query read, notice when any of them change (a price update, a new review), and re-run or patch the query for every client watching. With many clients and busy data, that is a lot of work, which is why many teams approximate live queries with polling, or with a subscription that tells the client to re-fetch.
The shortcut
Ask "does the screen care about each event, or only the latest state?" Each event (a notification, a chat message) → subscription. Only the latest state (a counter, a dashboard) → live query if your server offers one, otherwise polling.
Open
The live query is sent once. The first result shows price 350 and ratings 5, 4, 3.
The trap is expecting every GraphQL server to support @live. Check your server's documentation; the specification only defines subscriptions.
Drills
Answer fast — trust the rule.
What does a live query send when the data it depends on changes?
Is @live defined by the GraphQL specification?
What does the client receive first from a live query, before anything changes?
Which feature is the best fit for a live query rather than a subscription?
Remember
- Subscriptions say what happened; live queries say what is true now.
- Each event matters → subscription; only the latest state → live query or polling.
- Trap: live queries are not in the specification, and they cost the server dependency tracking.