feat: make library compatible with newest graphql version

[n1ru4l]

No description provided.

[D1plo1d]

I'm going to leave this one open for the time being until I have a chance to upgrade my graphql version in https://github.com/tegapp/teg

[willstott101]

Is there any chance you'd consider maintaining two branches? Assuming it's not possible to make the library backwards compatible with older GQL?

[D1plo1d]

@willstott101 I would recommend checking out the new graphql-live-queries library @n1ru4l is working on instead. It appears to support newer releases of GraphQL: https://github.com/n1ru4l/graphql-live-queries

[willstott101]

Thanks for the pointer @D1plo1d if you don't mind, I have a few questions.

We quite big fans of the fact that live-query-able data has it's own space in the GraphQL API in your model. That library doesn't have that. Also it looks like deltas are WIP, not to mention the approach is already starting to invent ad-hoc GQL compression: n1ru4l/graphql-live-query#7

Is there any reason you think n1ru4l's library has better patterns than your type Subscription { live { query, patch } } schema design, or is it purely the development status that makes you suggest it?

Thanks!

[n1ru4l]

I also wanted to add my two cents here :) I think fundamentally both libraries try to solve similar issues, which are live queries. When I first picked it up, I quickly hit limitations such as: interfaces and unions not working as expected, having to write your own cache updater (for relay or apollo) and also not being compatible with recent GraphQL versions.

This library supports immutability, where mine simply relies on operation/query/resource invalidation (for now, in the future I wanna have support for stuff like AsyncIterators where a resolver can publish values over time).

My goal was to build a library that could be plugged in easily with an existing schema and minimal effort. Also I wanted to outsource the socket.io communication layer.

Socket.io is not a must for my library. You can still create your own protocol and potentially even use subscriptions through AST transformation if you wanted, as all you need to do is feed the live query store a query operation with a live fragment definition. The published results could then be feed back to the async iterator of your subscription.

I introduced a new non-standard protocol, because it was easier to grasp on my mental model, where this library re-uses the subscription standard and builds upon it by adding new types etc. that the library client must be aware of and know how to handle Of course the complexity here could also hidden by abstractions similar to my live query client library.

I hope I could give you some insights, there a certainly more motivations behind it such as wanting to build something from scratch in order to learn more about graphql internals, but in the end both solutions will hopefully result in having live queries in the spec to some extend. My library was definetly inspiref by this one!

[D1plo1d]

@willstott101 just to summarize my biggest motivation here is definitely that @n1ru4l is actively maintaining a codebase - that makes a world of difference for 3rd party libraries that I use.

My https://tegapp.io useage of live subscriptions has been increasingly migrating to rust lately so this live subscriptions is unfortunately on track to get abandoned and re-implemented as a Rust crate soon(ish). I'm a single person startup here and strapped for time as I am there just aren't the resources to maintain something that isn't a core part of my project.

Also, I should add that this codebase is basically a giant prototype that worked well enough that it got put into production. There's very little polish. @n1ru4l 's comment about immutability is spot on - it's easy to use this with my in-memory, immutable IOT backend but not really very ergonomic for anything else.

But your absolutely right that we've differed on the priority of patches. In my work conserving bandwidth was a major concern so that json patch feature felt very important to have.

I don't know if there's anything in the spec's about this but I'd be curious if there was some standards for how people are sending @defer partial update that could be reused for partial @live updates.

@n1ru4l slight tangent but since we have you here I'd love to see an @live directive implementation that is 100% compatible with existing clients.

With that @live directives could be used in public APIs where we as the API creators don't have to mandate a specific graphql client libraries to be used.

My next work on this will probably be in rust but if I find a way to build an apollo client-compatible rust @live implementation I'm going to absolutely aim to share what I find. I'd love to see multiple languages supporting the same existing client compatible @live Interface.

[n1ru4l]

@D1plo1d https://github.com/samsarahq/thunder has first-class live query support implemented through resolver invalidation. Have not checked it out yet.

graphql-js AsyncIterator support will land soon, however, it will not support live queries and is only meant for "short-living" updates aka streaming a list to the client (via @stream).

[D1plo1d]

Thunder looks cool. I don't think their doing this but what I'm thinking now is that I can reuse the path property already implemented for @defer in apollo-client to send @live patches:

{
  "path": ["newsFeed", "stories", 1, "comments"],
  "data": [
    {
      "text": "..."
    }
  ]
}

Source: https://www.apollographql.com/docs/react/v2.4/features/defer-support/

[willstott101]

@defer looks like a decent pattern. However I'd think more of the json patch operations (remove, copy, move) should be supported to cover efficient live queries.

[D1plo1d]

@willstott101 yeah good point, another issue I realize now with the @defer pattern is that it's only 1 path per payload. So if you want to update a bunch of things it needs to be multiple payloads / not atomic.

[n1ru4l]

@willstott101 We could try pushing this a bit more forward by coming up with something more flexible. The protocol could be implemented on the network layer of apollo client/relay/.

Again the drawback is that it is not specification compliant. But unless we do not expose it to third-party API consumers it should be fine. In the next step, we might push stuff even more forward and come up with an RFC for sending incremental data changes over GraphQL with JSON patch. Then it could become a standard in those libraries and the cache could be built more efficiently around that.

[D1plo1d]

In the next step, we might push stuff even more forward and come up with an RFC for sending incremental data changes over GraphQL with JSON patch. Then it could become a standard in those libraries and the cache could be built more efficiently around that.

@n1ru4l If I can be any help on this give me a shout. As an initial strawman sending payloads of { patch: [...] } seems conceptually straight forward although I'm sure the devil is in the details :)

[n1ru4l]

I will ping you once I built a reference prototype. It is currently on my personal project backlog 😁.

[n1ru4l]

So got some work done here: n1ru4l/graphql-live-query#243

Would love to hear some of your feedback! The idea here is that a live query has an isLive: true property in the execution result. Then this middleware can just be applied to identify live queries and send patches over the wire. On the client side the same technique will be used for applying the patches.