Deprecation of local resolvers makes adopting GQL more difficult

Apologies if this has been raised elsewhere, but I spent quite some time searching and couldn’t find anything coming at this with quite the same angle I want to use.

I want to argue that deprecating both apollo-link-state and local resolvers from core simultaneously does serious damage to the powerful legacy API adoption story that Apollo and GQL has thus far been able to boast. By “legacy API adoption story” I mean the ability to start using Apollo without incurring tech debt in the client prior to a GQL server becoming available. This is such a valuable story because it empowers front end devs, who are often the main advocates for GQL, to start to demonstrate value to the entire cross-functional team without having immediate dependencies on back-end buy-in.

Noticing that local resolvers had been built into core in 2.5, I decided the time was right to adopt Apollo client as our primary state management solution. In part I was spurred on by this excellent blog post about successful adoption at Trello. I built our solution on a v3 RC. When v3 officially came out it was quite a shock to see the deprecation of the local resolvers feature, so soon after its promotion into core.

The reason I find local resolvers such a powerful and preferential solution is that it allows me to build my client (almost entirely) agnostic of where the graphql service exists. Today, it happens to be in the browser alongside the UI code consuming it, but at some point in the future we will have a real service running across the wire. When that point comes I expect to need to make almost no changes to my client in order to consume it (removing some @client directives and adding the GQL service URL should be about it). Compare this with the disruption that would be caused if the client had originally been written to use the rest link (as pointed out in the above blog post) or the new type policies strategy being advocated.

(The potential to use most of the resolver code in a real node GQL service is also significant but incidental here.)

On type policies - I can kind of see how they could be used to get basically equivalent behavior, based on the suggestion here https://github.com/apollographql/apollo-client/issues/6852#issuecomment-674984235, but it’s less clear to me how this would look at scale. That is, what are the patterns to follow to migrate a local resolver GQL service solution over to a new type policies solution? I appreciate that there is another issue open tracking outstanding documentation https://github.com/apollographql/apollo-client/issues/6711 - I do hope someone will write a blog post or doc chapter to illustrate this soon.

I’ll finish with a few options that occur to me for ways forward, for consideration. The aim is to provide developers such as myself who have adopted Apollo on the client prior to the availability of a GQL server to continue to do so using version 3 and beyond without incurring technical debt in the client.

• Do not deprecate both local resolvers from core and apollo-link-state.
• Sufficiently reduce the size of the gql execution layer so that schema link becomes a viable alternative
• Publish some kind of migration guide/best practice doc that shows that my fears about converting my local resolver implementation over to a type policies one are unfounded 😉

Thanks for all of your time, work and thoughts.

[benjamn]

Thanks everyone for the constructive and insightful discussion! Sorry to keep you waiting.

Here’s a recent comment of mine giving a sketch of the useFragment API we’re considering. The initial implementation looks very much like what @jayy-lmao shared above. In short, we’re sold on useFragment for AC4. Hope that’s good news.

The other good news, more directly relevant to the discussion here: https://github.com/apollographql/apollo-client/issues/8189#issuecomment-857199932

I hope this counts as picking option 3 from the list in https://github.com/apollographql/apollo-client/issues/7072#issuecomment-791058694, and then skipping the petitioning part. You already did that, above! I see no reason we can’t continue supporting an @apollo/client/link/local-resolvers link package, similar in spirit to apollo-link-state. It just doesn’t need to be baked into the ApolloClient core code.

keeping the frontend agnostic about its datasource was the only leverage i had

@nweajoseph This will still be true if we release local resolvers back into the link chain in AC4. In fact, since the link chain represents a network abstraction for Apollo Client, I honestly think a link is the best place to implement local resolvers that mock server data or fetch it from different sources. One way or another, that usage of local resolvers will always be possible, rest assured!

[MarMun]

The reason I find local resolvers such a powerful and preferential solution is that it allows me to build my client (almost entirely) agnostic of where the graphql service exists.

I agree. My current (and still shaky) understanding of the new paradigm (ReactiveVar / TypePolicies) makes me bleed data access layer knowledge (in my case: apollo client) into the presentation layer.

Namely: My presentation layer needs to know if data is local or remote because the way to issue a mutation is different (gql-mutation vs function call).