I love GraphQL, it makes generating types for any language very easy, with one schema, and you don't have to worry about the shape of the response on either the server or the client due to such types. If you don't need multiple clients and are using TypeScript, you could use trpc though (and with Rust I also know of rspc).<p>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?
The 'live queries' RFC in the GraphQL spec has been in strawman stage (RFC 0) for a while.<p><a href="https://github.com/graphql/graphql-spec/issues/386">https://github.com/graphql/graphql-spec/issues/386</a>
Huh, I've been thinking about a very similar service that does not require a dependency on GraphQL — <a href="https://poll2hook.com/" rel="nofollow">https://poll2hook.com/</a><p>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?