Try to break the dependency from `@apollo/gateway` on Apollo Server #6057

glasser · 2022-01-26T18:53:00Z

This dependency is a pain because it makes it hard to test prerelease of Apollo Server.

This will include:

Seeing if we can get rid of the Logger type (Investigate whether there exists a 3rd-party equivalent to our Logger type #6056)
Considering keeping/moving the types required at build time to create plugins (and the "gateway" pseudo-plugin) out of @apollo/server (see Combine many packages into a single @apollo/server #6041)
Finding an alternative to the errors exported from apollo-server-error (see also Rethink ApolloError #6053)
Better place to get createSHA from than deep inside apollo-server-core (presumably apollo-utils)
Changing the dependency on apollo-reporting-protobuf to a new name like @apollo/usage-reporting-protobuf

Also these things that are dependencies of packages we are removing but that don't themselves depend on apollo-server-core

Getting rid of apollo-server-env (see Find an alternative to apollo-server-env for fetch API typing #6046)
Getting rid of apollo-server-caching (see Replace implementations of the cache interface with keyv #6045)

The text was updated successfully, but these errors were encountered:

glasser · 2022-04-28T21:26:08Z

Another thing to keep in mind: Gateway's API (specifically the GraphQLDataSource.process function) contains the ability to read from GraphQLRequestContext, but this type is changing in AS4 (if nothing else, the type of its cache field is changing). So we may have to do something fancy in order to have a single @apollo/gateway package version that works with both AS3 and AS4; eg, you might need a separate ApolloGatewayForAS4 (or import { ApolloGateway } from '@apollo/gateway/as4' or something). (Or to do a major version bump on @apollo/gateway and have to maintain two branches in parallel, but we probably don't like that for various reasons, including the desire to keep Gateway and composition major versions in sync with each other.)

…hQLDataSource I'm not exactly sure what the purpose of LocalGraphQLDataSource is, other than that it's a convenient thing to use in this repository's test suite. It is exported from `@apollo/gateway` but does not appear to be documented. It currently uses a function stolen from the heart of Apollo Server. We are working on eliminating the dependency of Gateway on Apollo Server (apollographql/apollo-server#6719, apollographql/apollo-server#6057) so this dependency on something that's not even part of the supported API seems worth looking into. `enablePluginsForSchemaResolvers` does two entirely unrelated things. One is the thing that its name says: it tweaks the schema so that it's possible to instrument execution on a per-field basis; this is used to implement Apollo Server's `willResolveField` plugin hook. The other thing it does is entirely undocumented: it enables an obscure and undocumented `__resolveObject` feature which we are already planning to remove in Apollo Server 4. As mentioned, this class seems to really just be a test helper for this repository, and in fact, the tests did use `__resolveObject` until a few months ago in #1658. So one might guess that the point of this line is just to enable `__resolveObject` in tests and that it can be entirely removed. And in fact, ff45cb7 shows that there used to be a comment here saying exactly that! So this commit removes the use of an undocumented internal function to enable an even less documented feature. The tests pass, so that seems good. Perhaps one could object to this as not fully backwards compatible, because perhaps there are users out there who are using LocalGraphQLDataSource directly and... expect willResolveField plugins to work? But that's not really something you can make work without the rest of Apollo Server anyway. I guess maybe they could actually be expecting `__resolveObject` to work? But at that point we're talking about theoretical people trying to combine two undocumented features (`LocalGraphQLDataSource` and `__resolveObject`). If we discover that those people exist, we can encourage them to just add this line back into their own code themselves. Surely, people who enjoy the thrill of using two undocumented features will be even happier using three undocumented features!

…hQLDataSource (#2007) I'm not exactly sure what the purpose of LocalGraphQLDataSource is, other than that it's a convenient thing to use in this repository's test suite. It is exported from `@apollo/gateway` but does not appear to be documented. It currently uses a function stolen from the heart of Apollo Server. We are working on eliminating the dependency of Gateway on Apollo Server (apollographql/apollo-server#6719, apollographql/apollo-server#6057) so this dependency on something that's not even part of the supported API seems worth looking into. `enablePluginsForSchemaResolvers` does two entirely unrelated things. One is the thing that its name says: it tweaks the schema so that it's possible to instrument execution on a per-field basis; this is used to implement Apollo Server's `willResolveField` plugin hook. The other thing it does is entirely undocumented: it enables an obscure and undocumented `__resolveObject` feature which we are already planning to remove in Apollo Server 4. As mentioned, this class seems to really just be a test helper for this repository, and in fact, the tests did use `__resolveObject` until a few months ago in #1658. So one might guess that the point of this line is just to enable `__resolveObject` in tests and that it can be entirely removed. And in fact, ff45cb7 shows that there used to be a comment here saying exactly that! So this commit removes the use of an undocumented internal function to enable an even less documented feature inside an undocumented class. The tests pass, so that seems good. Perhaps one could object to this as not fully backwards compatible, because perhaps there are users out there who are using LocalGraphQLDataSource directly and... expect willResolveField plugins to work? But that's not really something you can make work without the rest of Apollo Server anyway. I guess maybe they could actually be expecting `__resolveObject` to work? But at that point we're talking about theoretical people trying to combine two undocumented features (`LocalGraphQLDataSource` and `__resolveObject`). If we discover that those people exist, we can encourage them to just add this line back into their own code themselves. Surely, people who enjoy the thrill of using two undocumented features will be even happier using three undocumented features!

…hQLDataSource (#2007) (#2008) I'm not exactly sure what the purpose of LocalGraphQLDataSource is, other than that it's a convenient thing to use in this repository's test suite. It is exported from `@apollo/gateway` but does not appear to be documented. It currently uses a function stolen from the heart of Apollo Server. We are working on eliminating the dependency of Gateway on Apollo Server (apollographql/apollo-server#6719, apollographql/apollo-server#6057) so this dependency on something that's not even part of the supported API seems worth looking into. `enablePluginsForSchemaResolvers` does two entirely unrelated things. One is the thing that its name says: it tweaks the schema so that it's possible to instrument execution on a per-field basis; this is used to implement Apollo Server's `willResolveField` plugin hook. The other thing it does is entirely undocumented: it enables an obscure and undocumented `__resolveObject` feature which we are already planning to remove in Apollo Server 4. As mentioned, this class seems to really just be a test helper for this repository, and in fact, the tests did use `__resolveObject` until a few months ago in #1658. So one might guess that the point of this line is just to enable `__resolveObject` in tests and that it can be entirely removed. And in fact, ff45cb7 shows that there used to be a comment here saying exactly that! So this commit removes the use of an undocumented internal function to enable an even less documented feature inside an undocumented class. The tests pass, so that seems good. Perhaps one could object to this as not fully backwards compatible, because perhaps there are users out there who are using LocalGraphQLDataSource directly and... expect willResolveField plugins to work? But that's not really something you can make work without the rest of Apollo Server anyway. I guess maybe they could actually be expecting `__resolveObject` to work? But at that point we're talking about theoretical people trying to combine two undocumented features (`LocalGraphQLDataSource` and `__resolveObject`). If we discover that those people exist, we can encourage them to just add this line back into their own code themselves. Surely, people who enjoy the thrill of using two undocumented features will be even happier using three undocumented features!

hwillson · 2022-07-28T20:01:21Z

Note that there is related work happening in #6719.

The point of apollo-server-caching is to provide an abstraction over multiple cache backends. Gateway is not using that abstraction; it's just using one particular implementation, which is a wrapper around an old version of lru-cache. As part of apollographql/apollo-server#6057 and apollographql/apollo-server#6719 we want to remove dependencies on Apollo Server from Apollo Gateway. Technically we don't really need to remove this dependency (since apollo-server-caching doesn't depend on anything else in AS) but apollo-server-caching won't be updated any more (in fact, even in AS3 it has already been replaced by `@apollo/utils.keyvaluecache`), so let's do it. While we're at it, we make a few other improvements: - Ever since #440, the queryPlanStore field is always set, so we can remove some conditionals around it. - Instead of using the old lru-cache@6 wrapped by the apollo-server-caching package, we use the newer lru-cache@7 (which improves the algorithm internally and changes the names of methods a bit). - The get and set methods on InMemoryLRUCache were only async because they implement the abstract KeyValueCache interface: the implementations didn't actually do anything async. So we no longer need to await them or include a giant comment about how we're not awaiting them.

This is part of apollographql/apollo-server#6057 (which is itself part of apollographql/apollo-server#6719). We are trying to break the dependency of Gateway on Server so that (among other things) it is easier to have a single version of Gateway that works with both the current AS3 and the upcoming AS4. In AS4, we are removing the ApolloError class and its subclasses. Instead, we will just use GraphQLError directly. See: https://www.apollographql.com/docs/apollo-server/v4/migration#apolloerror https://www.apollographql.com/docs/apollo-server/v4/migration#built-in-error-classes apollographql/apollo-server#6355 apollographql/apollo-server#6705 This commit changes RemoteGraphQLDataSource to throw GraphQLError instead of ApolloError. The `code` extension will still be the same. (The `name` field of the thrown Error will no longer be eg `AuthenticationError`, though; this does not affect the error as serialized in GraphQL.) This is technically slightly backwards-incompatible (eg, the method errorFromResponse is public and now returns GraphQLError instead of the tighter ApolloError) but this doesn't seem likely to affect many users. We can adjust based on feedback if necessary.

…2028) This is part of apollographql/apollo-server#6057 (which is itself part of apollographql/apollo-server#6719). We are trying to break the dependency of Gateway on Server so that (among other things) it is easier to have a single version of Gateway that works with both the current AS3 and the upcoming AS4. In AS4, we are removing the ApolloError class and its subclasses. Instead, we will just use GraphQLError directly. See: https://www.apollographql.com/docs/apollo-server/v4/migration#apolloerror https://www.apollographql.com/docs/apollo-server/v4/migration#built-in-error-classes apollographql/apollo-server#6355 apollographql/apollo-server#6705 This commit changes RemoteGraphQLDataSource to throw GraphQLError instead of ApolloError. The `code` extension will still be the same. (The `name` field of the thrown Error will no longer be eg `AuthenticationError`, though; this does not affect the error as serialized in GraphQL.) This is technically slightly backwards-incompatible (eg, the method errorFromResponse is public and now returns GraphQLError instead of the tighter ApolloError) but this doesn't seem likely to affect many users. We can adjust based on feedback if necessary.

The point of apollo-server-caching is to provide an abstraction over multiple cache backends. Gateway is not using that abstraction; it's just using one particular implementation, which is a wrapper around an old version of lru-cache. As part of apollographql/apollo-server#6057 and apollographql/apollo-server#6719 we want to remove dependencies on Apollo Server from Apollo Gateway. Technically we don't really need to remove this dependency (since apollo-server-caching doesn't depend on anything else in AS) but apollo-server-caching won't be updated any more (in fact, even in AS3 it has already been replaced by `@apollo/utils.keyvaluecache`), so let's do it. While we're at it, we make a few other improvements: - Ever since #440, the queryPlanStore field is always set, so we can remove some conditionals around it. - Instead of using the old lru-cache@6 wrapped by the apollo-server-caching package, we use the newer lru-cache@7 (which improves the algorithm internally and changes the names of methods a bit). - The get and set methods on InMemoryLRUCache were only async because they implement the abstract KeyValueCache interface: the implementations didn't actually do anything async. So we no longer need to await them or include a giant comment about how we're not awaiting them.

…2028) This is part of apollographql/apollo-server#6057 (which is itself part of apollographql/apollo-server#6719). We are trying to break the dependency of Gateway on Server so that (among other things) it is easier to have a single version of Gateway that works with both the current AS3 and the upcoming AS4. In AS4, we are removing the ApolloError class and its subclasses. Instead, we will just use GraphQLError directly. See: https://www.apollographql.com/docs/apollo-server/v4/migration#apolloerror https://www.apollographql.com/docs/apollo-server/v4/migration#built-in-error-classes apollographql/apollo-server#6355 apollographql/apollo-server#6705 This commit changes RemoteGraphQLDataSource to throw GraphQLError instead of ApolloError. The `code` extension will still be the same. (The `name` field of the thrown Error will no longer be eg `AuthenticationError`, though; this does not affect the error as serialized in GraphQL.) This is technically slightly backwards-incompatible (eg, the method errorFromResponse is public and now returns GraphQLError instead of the tighter ApolloError) but this doesn't seem likely to affect many users. We can adjust based on feedback if necessary.

* gateway: remove dependency on apollo-server-caching (#2029) The point of apollo-server-caching is to provide an abstraction over multiple cache backends. Gateway is not using that abstraction; it's just using one particular implementation, which is a wrapper around an old version of lru-cache. As part of apollographql/apollo-server#6057 and apollographql/apollo-server#6719 we want to remove dependencies on Apollo Server from Apollo Gateway. Technically we don't really need to remove this dependency (since apollo-server-caching doesn't depend on anything else in AS) but apollo-server-caching won't be updated any more (in fact, even in AS3 it has already been replaced by `@apollo/utils.keyvaluecache`), so let's do it. While we're at it, we make a few other improvements: - Ever since #440, the queryPlanStore field is always set, so we can remove some conditionals around it. - Instead of using the old lru-cache@6 wrapped by the apollo-server-caching package, we use the newer lru-cache@7 (which improves the algorithm internally and changes the names of methods a bit). - The get and set methods on InMemoryLRUCache were only async because they implement the abstract KeyValueCache interface: the implementations didn't actually do anything async. So we no longer need to await them or include a giant comment about how we're not awaiting them. * gateway RemoteGraphQLDataSource: throw GraphQLError, not ApolloError (#2028) This is part of apollographql/apollo-server#6057 (which is itself part of apollographql/apollo-server#6719). We are trying to break the dependency of Gateway on Server so that (among other things) it is easier to have a single version of Gateway that works with both the current AS3 and the upcoming AS4. In AS4, we are removing the ApolloError class and its subclasses. Instead, we will just use GraphQLError directly. See: https://www.apollographql.com/docs/apollo-server/v4/migration#apolloerror https://www.apollographql.com/docs/apollo-server/v4/migration#built-in-error-classes apollographql/apollo-server#6355 apollographql/apollo-server#6705 This commit changes RemoteGraphQLDataSource to throw GraphQLError instead of ApolloError. The `code` extension will still be the same. (The `name` field of the thrown Error will no longer be eg `AuthenticationError`, though; this does not affect the error as serialized in GraphQL.) This is technically slightly backwards-incompatible (eg, the method errorFromResponse is public and now returns GraphQLError instead of the tighter ApolloError) but this doesn't seem likely to affect many users. We can adjust based on feedback if necessary. * Adjust #2028 for [email protected] compatibility

apollo-server-types is an Apollo Server 3 package that is going away in Apollo Server 4, so we don't want `@apollo/subgraph` to depend on it. This was a build-time-only dependency (it just imported a type and that type isn't used in the generated .d.ts files) but it would still be helpful to minimize dependencies so that AS4 users don't also end up with pieces of AS3 installed. The new package `@apollo/cache-control-types` also has a function that implements the "does it look like it's the right cacheControl object?" itself, and it does not rely on AS3's `declare module` to globally monkeypatch `cacheControl` onto `GraphQLResolveInfo`'s type definition. Part of apollographql/apollo-server#6057

…types (Note: as part of backporting, I put out another version @apollo/[email protected] with apollographql/apollo-utils#173 and will now forward-port the dependency update.) apollo-server-types is an Apollo Server 3 package that is going away in Apollo Server 4, so we don't want `@apollo/subgraph` to depend on it. This was a build-time-only dependency (it just imported a type and that type isn't used in the generated .d.ts files) but it would still be helpful to minimize dependencies so that AS4 users don't also end up with pieces of AS3 installed. The new package `@apollo/cache-control-types` also has a function that implements the "does it look like it's the right cacheControl object?" itself, and it does not rely on AS3's `declare module` to globally monkeypatch `cacheControl` onto `GraphQLResolveInfo`'s type definition. Part of apollographql/apollo-server#6057

…types (#2039) (Note: as part of backporting, I put out another version @apollo/[email protected] with apollographql/apollo-utils#173 and will now forward-port the dependency update.) apollo-server-types is an Apollo Server 3 package that is going away in Apollo Server 4, so we don't want `@apollo/subgraph` to depend on it. This was a build-time-only dependency (it just imported a type and that type isn't used in the generated .d.ts files) but it would still be helpful to minimize dependencies so that AS4 users don't also end up with pieces of AS3 installed. The new package `@apollo/cache-control-types` also has a function that implements the "does it look like it's the right cacheControl object?" itself, and it does not rely on AS3's `declare module` to globally monkeypatch `cacheControl` onto `GraphQLResolveInfo`'s type definition. Part of apollographql/apollo-server#6057

Backport of #2044. This removes the last dependency on Apollo Server from Apollo Gateway. Part of apollographql/apollo-server#6057 and apollographql/apollo-server#6719 The new package `@apollo/server-gateway-interface` (in the apollo-utils repo for now, though it should move to the apollo-server repo once AS4 is fully released) defines types that are pretty close to compatible with the AS3 types previously used here, but don't require a dependency on the entirety of AS3. This new package will be used by AS4 and AS4 will convert its data into the format described by these types. This change is entirely a build-time change (other than a slight change to how a enum is referenced). So the worst case scenario if this differs unintentionally from the original AS3 definitions is that users can apply a bit of `as any` to fix it. Note that we've removed some `<TContext>` from types that it turned out were only ever instantiated with `Record<string, any>` anyway. They are left in in RemoteGraphQLDataSource because users making their own data sources can explicitly specify their context type. The types in `@apollo/server-gateway-interface` are pretty close to the AS3 types (with different names) but there are some slight differences. The cache scope enum is replaced with `any`, as enums are not structurally typed and it is otherwise difficult to type them. `GatewayInterface` now expects `onSchemaLoadOrUpdate` to exist and doesn't mention the old `onSchemaChange`. For now, we leave `apollo-reporting-protobuf` alone, so we don't have a direct dependency on a prerelease.

This removes the last dependency on Apollo Server from Apollo Gateway. Part of apollographql/apollo-server#6057 and apollographql/apollo-server#6719 The new package `@apollo/server-gateway-interface` (in the apollo-utils repo for now, though it should move to the apollo-server repo once AS4 is fully released) defines types that are pretty close to compatible with the AS3 types previously used here, but don't require a dependency on the entirety of AS3. This new package will be used by AS4 and AS4 will convert its data into the format described by these types. This change is entirely a build-time change (other than a slight change to how a enum is referenced). So the worst case scenario if this differs unintentionally from the original AS3 definitions is that users can apply a bit of `as any` to fix it. Note that we've removed some `<TContext>` from types that it turned out were only ever instantiated with `Record<string, any>` anyway. They are left in in RemoteGraphQLDataSource because users making their own data sources can explicitly specify their context type. The types in `@apollo/server-gateway-interface` are pretty close to the AS3 types (with different names) but there are some slight differences. The cache scope enum is replaced with `any`, as enums are not structurally typed and it is otherwise difficult to type them. `GatewayInterface` now expects `onSchemaLoadOrUpdate` to exist and doesn't mention the old `onSchemaChange`. For now, we leave `apollo-reporting-protobuf` alone, so we don't have a direct dependency on a prerelease.

Backport of #2044. Some tweaks for graphql@15 and Node 12 support. This removes the last dependency on Apollo Server from Apollo Gateway. Part of apollographql/apollo-server#6057 and apollographql/apollo-server#6719 The new package `@apollo/server-gateway-interface` (in the apollo-utils repo for now, though it should move to the apollo-server repo once AS4 is fully released) defines types that are pretty close to compatible with the AS3 types previously used here, but don't require a dependency on the entirety of AS3. This new package will be used by AS4 and AS4 will convert its data into the format described by these types. This change is entirely a build-time change (other than a slight change to how a enum is referenced). So the worst case scenario if this differs unintentionally from the original AS3 definitions is that users can apply a bit of `as any` to fix it. Note that we've removed some `<TContext>` from types that it turned out were only ever instantiated with `Record<string, any>` anyway. They are left in in RemoteGraphQLDataSource because users making their own data sources can explicitly specify their context type. The types in `@apollo/server-gateway-interface` are pretty close to the AS3 types (with different names) but there are some slight differences. The cache scope enum is replaced with `any`, as enums are not structurally typed and it is otherwise difficult to type them. `GatewayInterface` now expects `onSchemaLoadOrUpdate` to exist and doesn't mention the old `onSchemaChange`. For now, we leave `apollo-reporting-protobuf` alone, so we don't have a direct dependency on a prerelease.

This removes the last dependency on Apollo Server from Apollo Gateway. Part of apollographql/apollo-server#6057 and apollographql/apollo-server#6719 The new package `@apollo/server-gateway-interface` (in the apollo-utils repo for now, though it should move to the apollo-server repo once AS4 is fully released) defines types that are pretty close to compatible with the AS3 types previously used here, but don't require a dependency on the entirety of AS3. This new package will be used by AS4 and AS4 will convert its data into the format described by these types. This change is entirely a build-time change (other than a slight change to how a enum is referenced). So the worst case scenario if this differs unintentionally from the original AS3 definitions is that users can apply a bit of `as any` to fix it. Note that we've removed some `<TContext>` from types that it turned out were only ever instantiated with `Record<string, any>` anyway. They are left in in RemoteGraphQLDataSource because users making their own data sources can explicitly specify their context type. The types in `@apollo/server-gateway-interface` are pretty close to the AS3 types (with different names) but there are some slight differences. The cache scope enum is replaced with `any`, as enums are not structurally typed and it is otherwise difficult to type them. `GatewayInterface` now expects `onSchemaLoadOrUpdate` to exist and doesn't mention the old `onSchemaChange`. For now, we leave `apollo-reporting-protobuf` alone, so we don't have a direct dependency on a prerelease.

glasser · 2022-08-11T19:45:36Z

This is done!

glasser added this to the Release 4.0 milestone Jan 26, 2022

glasser assigned trevor-scheer Jan 26, 2022

glasser mentioned this issue Feb 3, 2022

Combine many packages into a single @apollo/server #6041

Closed

glasser mentioned this issue Jul 22, 2022

Make it possible to use AS4 with Apollo Gateway #6719

Closed

glasser mentioned this issue Jul 22, 2022

gateway: remove use of internal Apollo Server function from LocalGraphQLDataSource apollographql/federation#2007

Merged

glasser mentioned this issue Jul 22, 2022

[v0] gateway: remove use of internal Apollo Server function from LocalGraphQLDataSource apollographql/federation#2008

Merged

glasser self-assigned this Aug 1, 2022

glasser mentioned this issue Aug 2, 2022

gateway RemoteGraphQLDataSource: throw GraphQLError, not ApolloError apollographql/federation#2028

Merged

glasser mentioned this issue Aug 2, 2022

gateway: remove dependency on apollo-server-caching apollographql/federation#2029

Merged

glasser mentioned this issue Aug 4, 2022

@apollo/subgraph: remove dependency on apollo-server-types apollographql/federation#2037

Merged

glasser mentioned this issue Aug 4, 2022

Backport #2037: @apollo/subgraph: remove dependency on apollo-server-types apollographql/federation#2039

Merged

glasser mentioned this issue Aug 8, 2022

Change dependency on Apollo Server 3 to new type package apollographql/federation#2044

Merged

glasser mentioned this issue Aug 8, 2022

V0: Change dependency on Apollo Server 3 to new type package apollographql/federation#2050

Merged

glasser closed this as completed Aug 11, 2022

gersongams mentioned this issue Nov 17, 2022

Could not resolve "@apollo/usage-reporting-protobuf" #7159

Closed

github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Try to break the dependency from `@apollo/gateway` on Apollo Server #6057

Try to break the dependency from `@apollo/gateway` on Apollo Server #6057

glasser commented Jan 26, 2022 •

edited by trevor-scheer

Loading

glasser commented Apr 28, 2022

hwillson commented Jul 28, 2022

glasser commented Aug 11, 2022

Try to break the dependency from @apollo/gateway on Apollo Server #6057

Try to break the dependency from @apollo/gateway on Apollo Server #6057

Comments

glasser commented Jan 26, 2022 • edited by trevor-scheer Loading

glasser commented Apr 28, 2022

hwillson commented Jul 28, 2022

glasser commented Aug 11, 2022

Try to break the dependency from `@apollo/gateway` on Apollo Server #6057

Try to break the dependency from `@apollo/gateway` on Apollo Server #6057

glasser commented Jan 26, 2022 •

edited by trevor-scheer

Loading