Support for defer/stream

Raising this issue with goal of gathering feedback about Apollo “re-adopting” the defer/stream capability. There has been huge momentum in recent months around this. graphiql now supports defer/stream out of the box and houses a sample implementation for this. We are also seeing leaps being made over in the spec https://github.com/graphql/graphql-spec/pull/742 So its only a matter of time before this will become an expected feature.

I know that this is scheduled for 3.5; but wondering If this is something that I can help contribute back across the line? I gave this is a fair crack over at apollo-link-multipart using meros so have had some experience in adding it. But believe adding this into the core would enable greater adoption.

Links~

• grpahiql support: https://github.com/graphql/graphiql/pull/1770
• https://github.com/graphql/graphql-spec/blob/main/rfcs/DeferStream.md
• https://github.com/graphql/graphql-over-http/blob/main/rfcs/IncrementalDelivery.md
• Sample server implementation: https://github.com/contrawork/graphql-helix
• transport handler: https://github.com/maraisr/meros

[benjamn]

@maraisr Sorry for leaving you hanging for so long here!

As long as the incoming data payloads get written into the InMemoryCache, all queries and fragments that are watching the cache will be notified automatically of the new data. This could either mean writing the entire result multiple times, with incremental patches applied, or somehow writing only the data that have changed. The latter approach might be more efficient, but trickier. I would prefer for it to work without relying on the label, but I see how label could help.

I think we will end up introducing a new NetworkStatus.partial enum value to indicate that a query result is still missing some deferred parts. The NetworkStatus concept is something that exists in ApolloClient outside of ApolloLink, so I don’t think we can terminate everything within ApolloLink.

While I hope that answers at least some of your questions, and I very much appreciate you sharing your branch as a proof of concept, I have to warn you that we (the core team) will probably have an easier time navigating the internals of Apollo Client than you (our fault, not yours), so it might make sense to hold off on a full PR, to protect your personal time. We will look for a ways to use meros (thanks for that), and I will definitely be reaching out to you for your review, when we have something ready for review/testing.

Scheduling-wise, this is a priority for the v3.5 release (I got it moved up from v3.6), so I hope you won’t be waiting long. Thanks again for going above and beyond to get the ball rolling on this project.

[hwillson]

Let’s re-open this for tracking (we’re aiming to have this in @apollo/client@3.5).