GraphQL Live Queries with live directive
grafbase.com
GraphQL Live Queries with live directive
1–10 of 12 posts
Re: GraphQL Live Queries with live directive
#2I 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?
Re: GraphQL Live Queries with live directive
#3Huh, 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?
Re: GraphQL Live Queries with live directive
#4I 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.…
I'm still not sure about benefit of GraphQL over welled designed Restful API.
Re: GraphQL Live Queries with live directive
#5I 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.…
Longer thread - Subscriptions RFC: Are Subscriptions and Live Queries the same thing?
Re: GraphQL Live Queries with live directive
#6I 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.…
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.
Re: GraphQL Live Queries with live directive
#7Huh, 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.
Re: GraphQL Live Queries with live directive
#8I 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.…
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 P…
I should add that using regular queries with Apollo, URQL, etc. is perfectly fine. If you're building an app that requires realtime data then `@live` queries can be really useful. The data can update in realtime without refreshing and there's no need for WebSockets!
There are limitations to server-sent events, but `@live` queries is a perfect fit imo.
Re: GraphQL Live Queries with live directive
#9The 'live queries' RFC in the GraphQL spec has been in strawman stage (RFC 0) for a while.
Re: GraphQL Live Queries with live directive
#10The 'live queries' RFC in the GraphQL spec has been in strawman stage (RFC 0) for a while. https://github.com/graphql/graphql-spec/issues/386
There are even more implementations of live queries available by now. e.g. https://github.com/samsarahq/thunder (go) or https://github.com/n1ru4l/graphql-live-query (JavaScript).