Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove 'modules', '__resolveObject', and apollo-tooling dep
This removes the dependency on the deprecated `@apollographql/apollo-tooling` package by removing support for two undocumented features that it provides. The `modules` constructor option was the beginning of an attempt to provide guidance about how to structure one's schema into "modules". While there were bigger goals for it, in practice all it allowed you to do is specify your schema as an array of typeDefs/resolvers objects. It used a different schema-making function that is similar to but technically not the same as the `makeExecutableSchema` from graphql-tools. `makeExecutableSchema` lets you specify both `typeDefs` and `resolvers` these days, so you should be able to replace any use of `modules` with new ApolloServer({ typeDefs: modules.map({ typeDefs } => typeDefs, resolvers: modules.map({ resolvers } => resolvers, }) Or of course, you can use the `@apollographql/apollo-tooling` `buildServiceDefinition` yourself and pass it to the `schema` constructor option. The basic idea here is that `schema` is the main option for specifying a (non-gateway) schema and that we provide `typeDefs`/`resolvers` as syntactic sugar for the common case, but we don't need to provide two different kinds of syntactic sugar for specifying typeDefs and resolvers in slightly different data structures which use surprisingly different code to implement it. The other undocumented feature implemented by `@apollographql/apollo-tooling` was the ability to put a `__resolveObject` pseudo-resolver on a type. This was a predecessor to the subgraph `__resolveReference` method which offered a superset of its functionality. Whereas `__resolveReference` is specific to the `Query._entities` field, `__resolveObject` would run everywhere: it would run on that field's return values but also on any other field's return value. Interestingly it was implemented inside the "schema instrumentation" code which also implements the willResolveField plugin hook. In v3.6.0 we stopped running schema instrumentation if you aren't using a willResolveField hook (though admittedly the on-by-default cache control plugin uses that hook) which would break this feature! We don't know of any usage of this feature other than federation tests (which we're updating in apollographql/federation#1658) so for now we will delete it. This would better be done in graphql-js anyway, or perhaps as part of makeExecutableSchema.
- Loading branch information