apollographql
Use IResolvers instead of GraphQLResolverMap
Switch buildSubgraphSchema to use IResolvers rather than GraphQLResolverMap. Since IResolvers is a superset, this is a backward compatible change.
Fixes #2283
Deploy Preview for apollo-federation-docs canceled.
| Name | Link |
|---|---|
| Latest commit | 43b059cf476176f02fb3158174b8caf4cbaefdbd |
| Latest deploy log | https://app.netlify.com/sites/apollo-federation-docs/deploys/63853e49bc412f0008fd3f4a |
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request is automatically built and testable in CodeSandbox.
To see build info of the built libraries, click here or the icon next to each commit SHA.
![codesandbox-ci[bot] avatar](https://avatars.githubusercontent.com/in/38409?v=4 "Published by a pub.dev verified publisher"){kind=small}
Note to reviewers. We could in theory keep both definitions (i.e. resolvers?: IResolvers | GraphQLResolverMap<any>, but I don't necessarily see the benefit.
Just want to chip in on the business case side of things here as the person (or one of) who flagged up this issue. I work on the GraphQL Library at Neo4j, a product which accepts simple type definitions representing entities as input, and outputs a schema definition for a fully-fledged GraphQL API which you could build an application against.
We are of the view that we shouldn't be opinionated in what we provide to our users, so we return a DocumentNode for type definitions and IResolvers for resolvers, as these are the industry adopted standards for these entities. Our users can then plug these into Apollo Server, but also have the freedom to use a different GraphQL server such as Yoga if they so wish. Due to the type signature of buildSubgraphServer, if they are using TypeScript then they will get compilation errors.
In my opinion, the current API for buildSubgraphSchema is very geared towards users who are directly defining their type definitions and resolvers, and presents a challenge to library authors who are looking to produce subgraph compatible schema definitions, which will slow adoption amongst these products.
Totally appreciate (and empathise with the challenges of) everything in your comment, just wanted to provide a bit of context! One issue I imagine you will run into is that IResolvers accepts subscribe functions for Subscriptions, which I believe has no impact in the world of Federation. Could it be an acceptable starting point to parse incoming resolvers and console.warn of any entries which will be ignored by buildSubgraphSchema?
