Annotate fields and/or fragments with @live about graphql-live-query HOT 2 OPEN

I just noticed this issue right now, so my answer is a bit late 😅.

The problem right now is that there is not really a specification that allows sending granular partial patches to the client or re-execution partials of an operation. That’s why I chose that the InMemoryLiveQueryStore does not really interfere with anything related to GraphQL execution. TL;DR: This was the easiest way I could implement it in my spare time without adding too much complexity on top of what’s possible thanks to the defer/stream RFC (execute returns an AsyncIterable).

The defer/stream is almost exclusively implemented on a cache level, which makes it hard to implement in libraries such as relay and would require maintaining a fork, which I don’t really have the time right now. So I chose to just merge the results before forwarding all the data to the cache, which fortunately works with all major clients.

We could something similar for @live for single fields with a middleware you plug into your network layer, similar to what https://github.com/n1ru4l/graphql-live-query/tree/main/packages/graphql-live-query-patch is doing. The overhead that a whole query result is forwarded to the cache instead of simply a patch would still be there.

I currently have only a few ideas on how it could work. E.g. it could be possible to hook into the process by using a subscribe handler that can be specified for a field. Another option would be to construct an ad-hoc Schema where the live field is added to the Root type and an ad-hoc query for the given selection is built and executed. If a Schema is relay conform and has a Query.node field also only invalidated resources query subparts could be re-executed by building an ad-hoc query for that resource.

If @live could be applied anywhere it might become a bit complicated.

{
  users {
    edges {
      node @live { # could possible be 100 types of subscriptions that need to be setup
        ...SomeFragment
      }
    }
  }
}

How would the usage of nested @live behave? Should @live only be allowed on fields that return primitive Scalars and not on fields that return Objects?

There is still a lot of stuff to explore and I would appreciate any help.

In the App in which I am using this rn I don’t really have the need to only have certain parts of the query defined as live as all the data should be as up2date as possible.

here some usage examples:

https://github.com/dungeon-revealer/dungeon-revealer/blob/a552f81bc7520bae900432fc2430eef627ac606f/src/splash-share-image.tsx#L13 (show some modal to each app user, until it is dismissed)

https://github.com/dungeon-revealer/dungeon-revealer/blob/a552f81bc7520bae900432fc2430eef627ac606f/src/dm-area/token-info-aside/token-info-aside.tsx#L49 (keep note viewed by multiple app users in sync)

if you wanna play around with it you can start it as a docker container or download the executable in the github releases.

Keep more data in sync (https://github.com/n1ru4l/character-overlay/blob/e32be7432f5540231c2f62630cbc805867179612/src/CharacterEditorQuery.graphql#L1-L14) (https://github.com/n1ru4l/character-overlay/blob/e32be7432f5540231c2f62630cbc805867179612/src/CharacterQuery.graphql#L1-L6)

see https://character-overlay.n1ru4l.cloud/ for the live app.

from graphql-live-query.

Some thoughts on how I wanna continue shaping graphql-live-query: https://dev.to/n1ru4l/graphql-live-queries-backed-by-the-relay-specification-3mlo

from graphql-live-query.