Support subscriptions

[akotlar]

Great library, and mostly fits my design goals. Really like the hash-based cache choice, easiness of having non-singleton configuration, and most of all library size.

I was wondering if you have given any further thought to subscriptions. This is something I would like to have, and am thinking around writing an integration when the time comes. You know the GraphQL ecosystem better than I, and so was wondering if you had any thoughts.

Thanks!

edit: One simple way of doing this would be to rely on prop-mutation-based refetch (send a simple websocket notification with say a hash of the query, mutate a prop, and cause graphql-react to refetch), but that seems mostly wasteful. I want to be able to send a diff, and reconcile with the data already stored in grahpql-react. It's certainly possible to do this completely outside the graphql ecosystem, which is what I have previously implemented (a bit like graphql, in that I send a json object containing the dag representing the diff, and reconcile that dag with the client-stored stale data, by walking the shared portions of these two graphs and updating the leaves on the client store).

[jaydenseric]

A friend looked into subscriptions a while ago: https://github.com/pur3miish/graphql-react-subscription

I haven't needed subscriptions for any of my my own projects, so have not given the problem space due thought yet.

[ca-miked]

+1 !

[oogxdd]

++

[timeshift92]

++

[timeshift92]

Hello everyone, I did a subscription without caching. Does anyone care?

[jaydenseric]

An update…

On a few occasions I dove really deep into GraphQL WebSocket protocols, and was dissatisfied with Apollo's protocol (which has actually changed a few times) but it seems to be the only widely adopted protocol. I got started writing my own WebSocket related packages but ran out of motivation at the point of writing tests.

In the end, for me even in projects using Apollo Client where subscriptions are supported, polling has consistently been a better solution than subscriptions anyway. Somes advantages of polling are that it works without special setup, and it doesn't prevent you from using a serverless deployment for the GraphQL API.

I'll continue exploring subscriptions once there is a robust GraphQL WebSocket protocol endorsed by the GraphQL Foundation, which might be years away unfortunately. I'm in the GraphQL Foundation’s GraphQL over HTTP working group, and even a basic HTTP spec is taking a while to sort out.

[jthegedus]

So there's not just one voice on this, I 100% agree with @jaydenseric here. Polling has always given the benefit I was after, without the significant engineering overhead of managing sockets, correctly managing socket errors and the backend architecture to support sockets and scaling of the infra the message propagation is hosted on.

Simple polling with serverless deployment of the API gateway is by far the least amount of engineering to use GraphQL with close to "realtime" updates.

[jaydenseric]

A React hook for GraphQL subscriptions is now quite feasible:

1. graphql-ws is well maintained, and implements a protocol on track to be standardized by the GraphQL Foundation.
2. The new graphql-react v13 API has a very modular design, allowing custom React hooks to easily access and manipulate the cache.

Although this is not something I will get around to in the short term (unless I need subscriptions for a particular project) I'm happy to offer advice here to anyone that would like to create a custom React hook leveraging the new graphql-react API.

Maybe a GraphQL subscription hook should be designed to be used next to the useLoadGraphQL and useAutoLoad hooks, which would handle the loading for SSR, on mount, etc. as normal and the subscription hook would just update the same cache entry when subscription messages are received, skipping the Loading system in React context that is more useful for request/response type loading promises.