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).
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 purpose of the `@live` query is that it uses server-sent events to update the client state with any new changes that happen on the server. It's correct that you can use something like Tanstack Query, useSWR, React Apollo, or even fetch to poll the server again but that requires fetching all of the data that was previously fetched to update the client state. Instead with SSE, you get a diff in the format of JSON Patch that you can use to apply any changes to the current state without refetching everything.
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.
Huh, I've been thinking about a very similar service that does not require a dependency on GraphQL — https://poll2hook.com/
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 `@live` directive implementation uses server-sent events to send messages to the client with any changes that happen on the server in the format of https://jsonpatch.com
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.
satvikpendem|3 years ago
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?
smurda|3 years ago
https://github.com/graphql/graphql-spec/issues/284
notrab|3 years ago
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.
revskill|3 years ago
Emigre_|3 years ago
https://github.com/graphql/graphql-spec/issues/386
n1ru4l|3 years ago
vlaaad|3 years ago
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?
notrab|3 years ago
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.
n1ru4l|3 years ago
We experimented with something similar on a customer project where having a long-lived HTTP connection was not possible.