-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix fetch customization, upgrade make-fetch-happen, more concurrency #1805
Conversation
✅ Deploy Preview for apollo-federation-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
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. |
35301c4
to
098e60a
Compare
098e60a
to
865f018
Compare
865f018
to
ede1163
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick skim LGTM (though I helped author this code, so other eyes might be good here)
@@ -1,56 +0,0 @@ | |||
import { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥳
The main runtime change here is similar to #188. That PR had us stop passing |
40bbbde
to
b25c12a
Compare
UplinkFetcher and RemoteGraphQLDataSource both use `make-fetch-happen` to execute HTTP requests and allow you to replace that implementation with any compatible implementation of the web Fetch API. But prior to this PR, this customization often did not work. For example, prior to this PR, the version of `make-fetch-happen` used by default was the outdated v8. If you wanted to use the current v10, you'd think you could just install it in your project and pass its `fetch` function to the appropriate `fetcher` parameter. But surprisingly, this would not work for `RemoteGraphQLDataSource`! The Fetch API is flexible and allows you to specify your request either as plain JSON-style objects or as instances of the `Request` and `Headers` classes defined in the Fetch API spec. `RemoteGraphQLDataSource` used a `Headers` object in its requests. Specifically, it used a `Headers` object imported at runtime from `apollo-server-env`, a package we wrote that combines custom TypeScript types with `node-fetch` for runtime behavior. As it turns out, there's a behavior change in `make-fetch-happen` v9 as to how it tells the difference between using its API with JSON-style arguments or the `Requests`/`Headers` class. In the newer version, `make-fetch-happen` uses an `instanceof` check to see if the provided object is *its* `Headers` class. So when `RemoteGraphQLDataSource` passes in the `node-fetch` `Headers` class, `make-fetch-happens` v9 gets confused (and treats it as an empty JSON-style object instead). The solution we've settled on is to avoid passing non-plain objects to any `fetch` call that we intend to be customizable. We've published a new package, `@apollo/utils.fetcher`, which provides TypeScript definitions for a subset of the Fetch API that does not include the dangerous feature of "passing in `Request` or `Headers` objects". This PR changes both uses of `fetcher` in Gateway to use this new TypeScript type and to invoke it in a more conservative way. (We're making a similar change in the upcoming Apollo Server 4.) This does affect the types passed to some `RemoteGraphQLDataSource` methods, which are designed to be overridden. We feel reasonably sure that this won't have any noticeable impact on subclasses, as the changed types are intended to be very similar to the types they are replacing. Semi-relatedly, we've changed the default fetcher used by `RemoteGraphQLDataSource` to allow arbitrarily many parallel connections to each subgraph rather than only 15. `maxSockets: 15` is the default for `make-fetch-happen` (though not for the underlying `agentkeepalive` or `http.Agent` libraries) and so this limit was unintentionally added to Gateway when we switched from `node-fetch` to `make-fetch-happen`. While this change is a few years old now, it was unintentional and we doubt anyone is relying on this; on the contrary, it is causing real performance problems for production users (#1647). So we are changing the default to unlimited. If for some reason it is important to you that your Gateway only be able to process 15 requests at a time, you can restore the previous behavior: import fetcher from 'make-fetch-happen'; const lowConcurrencyFetcher = fetcher.defaults({ maxSockets: 15 }); const gateway = new ApolloGateway({ buildService({ url }) { return new RemoteGraphQLDataSource({ url, fetcher: lowConcurrencyFetcher, }); }, }); Fixes #1647. Fixes #1287. In more detail, this change consists of: - Switch the TypeScript typings `fetcher` option to `new ApolloGateway` and `new RemoteGraphQLDataSource` from a function type defined in `apollo-server-env` to a new one defined in `@apollo/utils.fetcher`. This function type's return type is compatible with the return type of the old fetcher, but its argument types are restricted to a subset of the Fetch API that is actually used by these classes (and classes in Apollo Server 4). Specifically, they do not allow you to pass `Request` or `Headers` objects. Adjust all calls to pass only plain JSON objects rather than `Request`/`Headers` objects. - In `RemoteGraphQLDataSource`, change the type of the "fetch request" argument to `parseBody` and `didEncounterError` (which are ignored by that class's implementations of the methods but could be examined by a subclass's implementations) from `apollo-server-env`'s `Request` type to `node-fetch`'s. This `Request` object is actually created at runtime by `RemoteGraphQLDataSource` and is always actually a `node-fetch` object, so reflecting that in the API seems to be reasonable. Note that this object is *not* actually sent to the `Fetcher`; it is only sent to these subclass-observable methods. This change makes the TypeScript type used for these parameters match the actual runtime type precisely so it should be a backwards-compatible change. - In `RemoteGraphQLDataSource`, change the type of the "fetch response" argument to `parseBody`, `errorFromResponse`, and `didEncounterError` from `apollo-server-env`'s `Response` type to `@apollo/utils.fetcher`'s `FetcherResponse` type. This interface type was designed to contain all the fields of the `apollo-server-env` type so this should be a backwards-compatible change. - Upgrade `make-fetch-happen` (the default fetcher used to talk to Uplink and to subgraphs) from v8 to v10. Stop preventing Renovate from upgrading it. - Changing the `make-fetch-happen` fetcher used in `RemoteGraphQLDataSource` to not limit the number of concurrent active sockets. (The fetcher used by `UplinkFetcher` keeps its defaults, as that fetcher does not need to make concurrent fetches.) - Remove the exported function `getDefaultFetcher`, as described in the CHANGELOG. None of the customizations we were making were actually still relevant for its use in `UplinkFetcher` so it seemed simpler to just remove the function rather than keep it around purely to allow people to simulate the way that an old version of `UplinkFetcher` fetched things by default. (We can add it back if there's a lot of protest, I suppose, although we'd be unlikely to make it continue to export `make-fetch-happen` v8!) - Replace tests that use Jest mocking of `apollo-server-env` and `make-fetch-happen` with `nock` or explicitly passed-in fetchers. This simplifies the tests and makes them less tied to the particular fetch implementations. (These tests were written before we knew about nock.) Also remove some code in IntrospectAndCompose.test.ts that *disabled* this mocking so that nock would work. - Remove the direct dependency on `apollo-server-env`. (Note that some types defined in `apollo-server-env` are still used indirectly in Gateway, because we still use `apollo-server-types` and types such as `GraphQLRequest` contain types from `apollo-server-env`.) Paired with @trevor-scheer.
b25c12a
to
55517da
Compare
@@ -4,7 +4,9 @@ This CHANGELOG pertains only to Apollo Federation packages in the 2.x range. The | |||
|
|||
## vNEXT | |||
|
|||
- The `fetch` implementation returned by `getDefaultFetcher` no longer performs in-memory caching. This fetcher is currently only used by `@apollo/gateway` to make uncacheable `POST` requests to Uplink, so this is a no-op for Gateway's own behavior, but if you used the function returned `getDefaultFetcher` in your own code to perform `GET` requests against servers that return cache-related response headers, it will no longer cache results. You can use the underlying [`make-fetch-happen`](https://www.npmjs.com/package/make-fetch-happen) package directly to use its cache capabilities instead of using the function returned by `getDefaultFetcher`. [PR #1792](https://github.com/apollographql/federation/pull/1792) | |||
- The `fetch` implementation used by default by `UplinkFetcher` and `RemoteGraphQLDataSource` is now imported from `make-fetch-happen` v10 instead of v8. The fetcher used by `RemoteGraphQLDataSource` no longer limits the number of simultaneous requests per subgraph to 15 by default; instead, there is no limit. (If you want to restore the previous behavior, install `make-fetch-happen`, import `fetcher` from it, and pass `new RemoteGraphQLDataSource({ fetcher: fetcher.defaults(maxSockets: 15)}))` in your `buildService` option.) [PR #1806](https://github.com/apollographql/federation/pull/1806) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops these PR #s are wrong (should be 1805) @glasser
…1805) UplinkFetcher and RemoteGraphQLDataSource both use `make-fetch-happen` to execute HTTP requests and allow you to replace that implementation with any compatible implementation of the web Fetch API. But prior to this PR, this customization often did not work. For example, prior to this PR, the version of `make-fetch-happen` used by default was the outdated v8. If you wanted to use the current v10, you'd think you could just install it in your project and pass its `fetch` function to the appropriate `fetcher` parameter. But surprisingly, this would not work for `RemoteGraphQLDataSource`! The Fetch API is flexible and allows you to specify your request either as plain JSON-style objects or as instances of the `Request` and `Headers` classes defined in the Fetch API spec. `RemoteGraphQLDataSource` used a `Headers` object in its requests. Specifically, it used a `Headers` object imported at runtime from `apollo-server-env`, a package we wrote that combines custom TypeScript types with `node-fetch` for runtime behavior. As it turns out, there's a behavior change in `make-fetch-happen` v9 as to how it tells the difference between using its API with JSON-style arguments or the `Requests`/`Headers` class. In the newer version, `make-fetch-happen` uses an `instanceof` check to see if the provided object is *its* `Headers` class. So when `RemoteGraphQLDataSource` passes in the `node-fetch` `Headers` class, `make-fetch-happens` v9 gets confused (and treats it as an empty JSON-style object instead). The solution we've settled on is to avoid passing non-plain objects to any `fetch` call that we intend to be customizable. We've published a new package, `@apollo/utils.fetcher`, which provides TypeScript definitions for a subset of the Fetch API that does not include the dangerous feature of "passing in `Request` or `Headers` objects". This PR changes both uses of `fetcher` in Gateway to use this new TypeScript type and to invoke it in a more conservative way. (We're making a similar change in the upcoming Apollo Server 4.) This does affect the types passed to some `RemoteGraphQLDataSource` methods, which are designed to be overridden. We feel reasonably sure that this won't have any noticeable impact on subclasses, as the changed types are intended to be very similar to the types they are replacing. Semi-relatedly, we've changed the default fetcher used by `RemoteGraphQLDataSource` to allow arbitrarily many parallel connections to each subgraph rather than only 15. `maxSockets: 15` is the default for `make-fetch-happen` (though not for the underlying `agentkeepalive` or `http.Agent` libraries) and so this limit was unintentionally added to Gateway when we switched from `node-fetch` to `make-fetch-happen`. While this change is a few years old now, it was unintentional and we doubt anyone is relying on this; on the contrary, it is causing real performance problems for production users (#1647). So we are changing the default to unlimited. If for some reason it is important to you that your Gateway only be able to process 15 requests at a time, you can restore the previous behavior: import fetcher from 'make-fetch-happen'; const lowConcurrencyFetcher = fetcher.defaults({ maxSockets: 15 }); const gateway = new ApolloGateway({ buildService({ url }) { return new RemoteGraphQLDataSource({ url, fetcher: lowConcurrencyFetcher, }); }, }); Fixes #1647. Fixes #1287. In more detail, this change consists of: - Switch the TypeScript typings `fetcher` option to `new ApolloGateway` and `new RemoteGraphQLDataSource` from a function type defined in `apollo-server-env` to a new one defined in `@apollo/utils.fetcher`. This function type's return type is compatible with the return type of the old fetcher, but its argument types are restricted to a subset of the Fetch API that is actually used by these classes (and classes in Apollo Server 4). Specifically, they do not allow you to pass `Request` or `Headers` objects. Adjust all calls to pass only plain JSON objects rather than `Request`/`Headers` objects. - In `RemoteGraphQLDataSource`, change the type of the "fetch request" argument to `parseBody` and `didEncounterError` (which are ignored by that class's implementations of the methods but could be examined by a subclass's implementations) from `apollo-server-env`'s `Request` type to `node-fetch`'s. This `Request` object is actually created at runtime by `RemoteGraphQLDataSource` and is always actually a `node-fetch` object, so reflecting that in the API seems to be reasonable. Note that this object is *not* actually sent to the `Fetcher`; it is only sent to these subclass-observable methods. This change makes the TypeScript type used for these parameters match the actual runtime type precisely so it should be a backwards-compatible change. - In `RemoteGraphQLDataSource`, change the type of the "fetch response" argument to `parseBody`, `errorFromResponse`, and `didEncounterError` from `apollo-server-env`'s `Response` type to `@apollo/utils.fetcher`'s `FetcherResponse` type. This interface type was designed to contain all the fields of the `apollo-server-env` type so this should be a backwards-compatible change. - Upgrade `make-fetch-happen` (the default fetcher used to talk to Uplink and to subgraphs) from v8 to v10. Stop preventing Renovate from upgrading it. - Changing the `make-fetch-happen` fetcher used in `RemoteGraphQLDataSource` to not limit the number of concurrent active sockets. (The fetcher used by `UplinkFetcher` keeps its defaults, as that fetcher does not need to make concurrent fetches.) - Remove the exported function `getDefaultFetcher`, as described in the CHANGELOG. None of the customizations we were making were actually still relevant for its use in `UplinkFetcher` so it seemed simpler to just remove the function rather than keep it around purely to allow people to simulate the way that an old version of `UplinkFetcher` fetched things by default. (We can add it back if there's a lot of protest, I suppose, although we'd be unlikely to make it continue to export `make-fetch-happen` v8!) - Replace tests that use Jest mocking of `apollo-server-env` and `make-fetch-happen` with `nock` or explicitly passed-in fetchers. This simplifies the tests and makes them less tied to the particular fetch implementations. (These tests were written before we knew about nock.) Also remove some code in IntrospectAndCompose.test.ts that *disabled* this mocking so that nock would work. - Remove the direct dependency on `apollo-server-env`. (Note that some types defined in `apollo-server-env` are still used indirectly in Gateway, because we still use `apollo-server-types` and types such as `GraphQLRequest` contain types from `apollo-server-env`.) Paired with @trevor-scheer.
…(`version-0.x`) (#1810) * Fix fetch customization, upgrade make-fetch-happen, more concurrency (#1805) UplinkFetcher and RemoteGraphQLDataSource both use `make-fetch-happen` to execute HTTP requests and allow you to replace that implementation with any compatible implementation of the web Fetch API. But prior to this PR, this customization often did not work. For example, prior to this PR, the version of `make-fetch-happen` used by default was the outdated v8. If you wanted to use the current v10, you'd think you could just install it in your project and pass its `fetch` function to the appropriate `fetcher` parameter. But surprisingly, this would not work for `RemoteGraphQLDataSource`! The Fetch API is flexible and allows you to specify your request either as plain JSON-style objects or as instances of the `Request` and `Headers` classes defined in the Fetch API spec. `RemoteGraphQLDataSource` used a `Headers` object in its requests. Specifically, it used a `Headers` object imported at runtime from `apollo-server-env`, a package we wrote that combines custom TypeScript types with `node-fetch` for runtime behavior. As it turns out, there's a behavior change in `make-fetch-happen` v9 as to how it tells the difference between using its API with JSON-style arguments or the `Requests`/`Headers` class. In the newer version, `make-fetch-happen` uses an `instanceof` check to see if the provided object is *its* `Headers` class. So when `RemoteGraphQLDataSource` passes in the `node-fetch` `Headers` class, `make-fetch-happens` v9 gets confused (and treats it as an empty JSON-style object instead). The solution we've settled on is to avoid passing non-plain objects to any `fetch` call that we intend to be customizable. We've published a new package, `@apollo/utils.fetcher`, which provides TypeScript definitions for a subset of the Fetch API that does not include the dangerous feature of "passing in `Request` or `Headers` objects". This PR changes both uses of `fetcher` in Gateway to use this new TypeScript type and to invoke it in a more conservative way. (We're making a similar change in the upcoming Apollo Server 4.) This does affect the types passed to some `RemoteGraphQLDataSource` methods, which are designed to be overridden. We feel reasonably sure that this won't have any noticeable impact on subclasses, as the changed types are intended to be very similar to the types they are replacing. Semi-relatedly, we've changed the default fetcher used by `RemoteGraphQLDataSource` to allow arbitrarily many parallel connections to each subgraph rather than only 15. `maxSockets: 15` is the default for `make-fetch-happen` (though not for the underlying `agentkeepalive` or `http.Agent` libraries) and so this limit was unintentionally added to Gateway when we switched from `node-fetch` to `make-fetch-happen`. While this change is a few years old now, it was unintentional and we doubt anyone is relying on this; on the contrary, it is causing real performance problems for production users (#1647). So we are changing the default to unlimited. If for some reason it is important to you that your Gateway only be able to process 15 requests at a time, you can restore the previous behavior: import fetcher from 'make-fetch-happen'; const lowConcurrencyFetcher = fetcher.defaults({ maxSockets: 15 }); const gateway = new ApolloGateway({ buildService({ url }) { return new RemoteGraphQLDataSource({ url, fetcher: lowConcurrencyFetcher, }); }, }); Fixes #1647. Fixes #1287. In more detail, this change consists of: - Switch the TypeScript typings `fetcher` option to `new ApolloGateway` and `new RemoteGraphQLDataSource` from a function type defined in `apollo-server-env` to a new one defined in `@apollo/utils.fetcher`. This function type's return type is compatible with the return type of the old fetcher, but its argument types are restricted to a subset of the Fetch API that is actually used by these classes (and classes in Apollo Server 4). Specifically, they do not allow you to pass `Request` or `Headers` objects. Adjust all calls to pass only plain JSON objects rather than `Request`/`Headers` objects. - In `RemoteGraphQLDataSource`, change the type of the "fetch request" argument to `parseBody` and `didEncounterError` (which are ignored by that class's implementations of the methods but could be examined by a subclass's implementations) from `apollo-server-env`'s `Request` type to `node-fetch`'s. This `Request` object is actually created at runtime by `RemoteGraphQLDataSource` and is always actually a `node-fetch` object, so reflecting that in the API seems to be reasonable. Note that this object is *not* actually sent to the `Fetcher`; it is only sent to these subclass-observable methods. This change makes the TypeScript type used for these parameters match the actual runtime type precisely so it should be a backwards-compatible change. - In `RemoteGraphQLDataSource`, change the type of the "fetch response" argument to `parseBody`, `errorFromResponse`, and `didEncounterError` from `apollo-server-env`'s `Response` type to `@apollo/utils.fetcher`'s `FetcherResponse` type. This interface type was designed to contain all the fields of the `apollo-server-env` type so this should be a backwards-compatible change. - Upgrade `make-fetch-happen` (the default fetcher used to talk to Uplink and to subgraphs) from v8 to v10. Stop preventing Renovate from upgrading it. - Changing the `make-fetch-happen` fetcher used in `RemoteGraphQLDataSource` to not limit the number of concurrent active sockets. (The fetcher used by `UplinkFetcher` keeps its defaults, as that fetcher does not need to make concurrent fetches.) - Remove the exported function `getDefaultFetcher`, as described in the CHANGELOG. None of the customizations we were making were actually still relevant for its use in `UplinkFetcher` so it seemed simpler to just remove the function rather than keep it around purely to allow people to simulate the way that an old version of `UplinkFetcher` fetched things by default. (We can add it back if there's a lot of protest, I suppose, although we'd be unlikely to make it continue to export `make-fetch-happen` v8!) - Replace tests that use Jest mocking of `apollo-server-env` and `make-fetch-happen` with `nock` or explicitly passed-in fetchers. This simplifies the tests and makes them less tied to the particular fetch implementations. (These tests were written before we knew about nock.) Also remove some code in IntrospectAndCompose.test.ts that *disabled* this mocking so that nock would work. - Remove the direct dependency on `apollo-server-env`. (Note that some types defined in `apollo-server-env` are still used indirectly in Gateway, because we still use `apollo-server-types` and types such as `GraphQLRequest` contain types from `apollo-server-env`.) Paired with @trevor-scheer. * Update PR #s Co-authored-by: David Glasser <[email protected]>
Note that this was inaccurate: we moved to make-fetch-happen for GCS/uplink fetching (which isn't particularly concurrent) years ago but only moved to it in RemoteGraphQLDataSource recently in 2.0.0/0.46.0. |
UplinkFetcher and RemoteGraphQLDataSource both use
make-fetch-happen
to execute HTTP requests and allow you to replace that implementation
with any compatible implementation of the web Fetch API.
But prior to this PR, this customization often did not work. For
example, prior to this PR, the version of
make-fetch-happen
used bydefault was the outdated v8. If you wanted to use the current v10, you'd
think you could just install it in your project and pass its
fetch
function to the appropriate
fetcher
parameter.But surprisingly, this would not work for
RemoteGraphQLDataSource
! TheFetch API is flexible and allows you to specify your request either as
plain JSON-style objects or as instances of the
Request
andHeaders
classes defined in the Fetch API spec.
RemoteGraphQLDataSource
used aHeaders
object in its requests. Specifically, it used aHeaders
object imported at runtime from
apollo-server-env
, a package we wrotethat combines custom TypeScript types with
node-fetch
for runtimebehavior.
As it turns out, there's a behavior change in
make-fetch-happen
v9 asto how it tells the difference between using its API with JSON-style
arguments or the
Requests
/Headers
class. In the newer version,make-fetch-happen
uses aninstanceof
check to see if the providedobject is its
Headers
class. So whenRemoteGraphQLDataSource
passes in the
node-fetch
Headers
class,make-fetch-happens
v9 getsconfused (and treats it as an empty JSON-style object instead).
The solution we've settled on is to avoid passing non-plain objects to
any
fetch
call that we intend to be customizable. We've published anew package,
@apollo/utils.fetcher
, which provides TypeScriptdefinitions for a subset of the Fetch API that does not include the
dangerous feature of "passing in
Request
orHeaders
objects". ThisPR changes both uses of
fetcher
in Gateway to use this new TypeScripttype and to invoke it in a more conservative way. (We're making a
similar change in the upcoming Apollo Server 4.)
This does affect the types passed to some
RemoteGraphQLDataSource
methods, which are designed to be overridden. We feel reasonably sure
that this won't have any noticeable impact on subclasses, as the changed
types are intended to be very similar to the types they are replacing.
Semi-relatedly, we've changed the default fetcher used by
RemoteGraphQLDataSource
to allow arbitrarily many parallel connectionsto each subgraph rather than only 15.
maxSockets: 15
is the defaultfor
make-fetch-happen
(though not for the underlyingagentkeepalive
or
http.Agent
libraries) and so this limit was unintentionally addedto Gateway when we switched from
node-fetch
tomake-fetch-happen
.While this change is a few years old now, it was unintentional and we
doubt anyone is relying on this; on the contrary, it is causing real
performance problems for production users (#1647). So we are changing
the default to unlimited. If for some reason it is important to you that
your Gateway only be able to process 15 requests at a time, you can
restore the previous behavior:
Fixes #1647.
Fixes #1287.
In more detail, this change consists of:
Switch the TypeScript typings
fetcher
option tonew ApolloGateway
and
new RemoteGraphQLDataSource
from a function type defined inapollo-server-env
to a new one defined in@apollo/utils.fetcher
.This function type's return type is compatible with the return type of
the old fetcher, but its argument types are restricted to a subset of
the Fetch API that is actually used by these classes (and classes in
Apollo Server 4). Specifically, they do not allow you to pass
Request
orHeaders
objects. Adjust all calls to pass onlyplain JSON objects rather than
Request
/Headers
objects.In
RemoteGraphQLDataSource
, change the type of the "fetch request"argument to
parseBody
anddidEncounterError
(which are ignored bythat class's implementations of the methods but could be examined by a
subclass's implementations) from
apollo-server-env
'sRequest
typeto
node-fetch
's. ThisRequest
object is actually created atruntime by
RemoteGraphQLDataSource
and is always actually anode-fetch
object, so reflecting that in the API seems to bereasonable. Note that this object is not actually sent to the
Fetcher
; it is only sent to these subclass-observable methods. Thischange makes the TypeScript type used for these parameters match the
actual runtime type precisely so it should be a backwards-compatible
change.
In
RemoteGraphQLDataSource
, change the type of the "fetch response"argument to
parseBody
,errorFromResponse
, anddidEncounterError
from
apollo-server-env
'sResponse
type to@apollo/utils.fetcher
'sFetcherResponse
type. This interface typewas designed to contain all the fields of the
apollo-server-env
typeso this should be a backwards-compatible change.
Upgrade
make-fetch-happen
(the default fetcher used to talk toUplink and to subgraphs) from v8 to v10. Stop preventing Renovate from
upgrading it.
Changing the
make-fetch-happen
fetcher used inRemoteGraphQLDataSource
to not limit the number of concurrent activesockets. (The fetcher used by
UplinkFetcher
keeps its defaults, asthat fetcher does not need to make concurrent fetches.)
Remove the exported function
getDefaultFetcher
, as described in theCHANGELOG. None of the customizations we were making were actually
still relevant for its use in
UplinkFetcher
so it seemed simpler tojust remove the function rather than keep it around purely to allow
people to simulate the way that an old version of
UplinkFetcher
fetched things by default. (We can add it back if there's a lot of
protest, I suppose, although we'd be unlikely to make it continue to
export
make-fetch-happen
v8!)Replace tests that use Jest mocking of
apollo-server-env
andmake-fetch-happen
withnock
or explicitly passed-in fetchers.This simplifies the tests and makes them less tied to the particular
fetch implementations. (These tests were written before we knew about
nock.) Also remove some code in IntrospectAndCompose.test.ts that
disabled this mocking so that nock would work.
Remove the direct dependency on
apollo-server-env
. (Note that sometypes defined in
apollo-server-env
are still used indirectly inGateway, because we still use
apollo-server-types
and types such asGraphQLRequest
contain types fromapollo-server-env
.)Paired with @trevor-scheer.