GraphQL Live Queries with live directive

GraphQL Live Queries with live directive(grafbase.com)

22 points by tobase 3 years ago | 11 comments

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?

smurda 3 years ago | |

Longer thread - Subscriptions RFC: Are Subscriptions and Live Queries the same thing?

https://github.com/graphql/graphql-spec/issues/284

notrab 3 years ago | |

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.

notrab 3 years ago | | |

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.

revskill 3 years ago | |

I'm still not sure about benefit of GraphQL over welled designed Restful API.

fbjork 3 years ago | | |

We chose GraphQL at Grafbase for a few reasons:

- 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

Emigre_ 3 years ago |

The '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

n1ru4l 3 years ago | |

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).

vlaaad 3 years ago |

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?

notrab 3 years ago | |

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.

n1ru4l 3 years ago | |

You could also implement live queries using polling and the E-Tag, If-None-Match header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If...).

We experimented with something similar on a customer project where having a long-lived HTTP connection was not possible.