Annotate fields and/or fragments with @live #458

sorenhoyer · 2021-03-04T20:16:43Z

Can't believe it has been nearly 5 years since this video https://www.youtube.com/watch?t=1090&v=ViXL0YQnioU where Lee Byron presents the idea of the @live directive.

{
  feed {
    stories {
      author { name }
      message
      likeCount @live
    }
  }
}

Really cool to follow your progress on live queries, but I've been wondering why you went with the approach of annotating the entire query vs being able to annotate the individual fields or fragments?

Are you planning, at some point, to support @live per field or fragment, or what is the rationale of annotating the whole query?

Keep up the great work!

The text was updated successfully, but these errors were encountered:

n1ru4l · 2021-03-10T21:58:57Z

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.