This article is interesting, however it seems `@live` isn't part of the official specification. Also, you can use something like TanStack Query to synchronize server state, which works with GraphQL as well as regular REST, or you can use a GraphQL client directly like Apollo or urql, which also does the same syncing, so I'm not sure for what purpose this directive serves exactly. Maybe it's for languages that don't have a good server side syncing library?
There are many implementations of Live Queries (some that just use polling under the hood) but we really like the concept of using JSON Patch with SSE.
There are limitations to server-sent events, but `@live` queries is a perfect fit imo.
- The client can ask for the data it needs, which also improves performance by reducing bandwidth
- Aggregating data from multiple data sources with a single request
- Widely adopted and loved by frontend and mobile developers
You can define a query on any API, be it GraphQL or REST, and a jq query to extract events, and you are good to go. I wonder if this @live directive is implemented with polling?
This means users don't need to poll to fetch all the data again but only get the data that changes. Poll2Hook looks great though, certainly a great solution if the service you're using doesn't have something native built-in.
We experimented with something similar on a customer project where having a long-lived HTTP connection was not possible.
