The changes noted within this
vNEXTsection have not been released yet. New PRs and commits which introduce changes should include an entry in thisvNEXTsection as part of their development. When a release is being prepared, a new header will be (manually) created below and the appropriate changes within that release will be moved into the new section.
- FIX: Collapse nested required fields into a single body in the query plan. Before, some nested fields' selection sets were getting split, causing some of their subfields to be dropped when executing the query. This fix collapses the split selection sets into one. #4064
-
NEW: Provide the ability to pass a custom
fetcherduringRemoteGraphQLDataSourceconstruction to be used when executing operations against downstream services. Providing a customfetchermay be necessary to accommodate more advanced needs, e.g., configuring custom TLS certificates for internal services. PR #4149The
fetcherspecified should be a compliant implementor of the Fetch API standard. This addition compliments, though is still orthognonal to, similar behavior originally introduced in #3783, which allowed customization of the implementation used to fetch gateway configuration and federated SDL from services in managed and unmanaged modes, but didn't affect the communication that takes place during operation execution.For now, the default
fetcherwill remain the same (node-fetch) implementation. A future major-version bump will update it to be consistent with other feature-rich implementations of the Fetch API which are used elsewhere in the Apollo Server stack where we usemake-fetch-happen. In all likelihood,ApolloGatewaywill pass its ownfetcherto theRemoteGraphQLDataSourceduring service initialization.
- BREAKING: Use a content delivery network for managed configuration, fetch storage secrets and composition configuration from different domains: https://storage-secrets.api.apollographql.com and https://federation.api.apollographql.com. Please mind any firewall for outgoing traffic. #4080
- FIX: Correctly handle unions with nested conditions that have no
possibleTypes#4071 - FIX: Normalize root operation types when reporting to Apollo Graph Manager. Federation always uses the default names
Query,Mutation, andSubscriptionfor root operation types even if downstream services choose different names; now we properly normalize traces received from downstream services in the same way. #4100
- BREAKING: Drop support for Node.js 8 and Node.js 10. This is being done primarily for performance gains which stand to be seen by transpiling to a newer ECMAScript target. For more details, see the related PR. #4031
- Performance: Cache stringified representations of downstream query bodies within the query plan to address performance cost incurred by repeatedly
printing the sameDocumentNodes with thegraphqlprinter. This improvement is more pronounced on larger documents. PR #4018 - Deprecation: Deprecated the
ENGINE_API_KEYenvironment variable in favor of its new name,APOLLO_KEY. The new name mirrors the name used within Apollo Graph Manager. Aside from the rename, the functionality remains otherwise identical. Continued use ofENGINE_API_KEYwill result in deprecation warnings being printed to the server console. Support forENGINE_API_KEYwill be removed in a future, major update. #3923 - Deprecation: Deprecated the
APOLLO_SCHEMA_TAGenvironment variable in favor of its new name,APOLLO_GRAPH_VARIANT. The new name mirrors the name used within Apollo Graph Manager. Aside from the rename, the functionality remains otherwise identical. Use of the now-deprecated name will result in a deprecation warning being printed to the server console. Support will be removed entirely in a future, major update. To avoid misconfiguration, runtime errors will be thrown if the new and deprecated versions are both set. #3855 - Add inadvertently excluded
apollo-server-errorsruntime dependency. #3927
- FIX: Resolve condition which surfaced in
0.14.0which prevented loading the configuration using managed federation. PR #3979
- Several previously unhandled Promise rejection errors stemming from, e.g. connectivity, failures when communicating with Apollo Graph Manager within asynchronous code are now handled. PR #3811
- Provide a more helpful error message when encountering expected errors. PR #3811
- General improvements and clarity to error messages and logging. PR #3811
- Warn of a possible misconfiguration when local service configuration is provided (via
serviceListorlocalServiceList) and a remote Apollo Graph Manager configuration is subsequently found as well. PR #3868 - During composition, the unavailability of a downstream service in unmanaged federation mode will no longer result in a partially composed schema which merely lacks the types provided by the downed service. This prevents unexpected validation errors for clients querying a graph which lacks types which were merely unavailable during the initial composition but were intended to be part of the graph. PR #3867
- Support providing a custom logger implementation (e.g.
winston,bunyan, etc.) to capture gateway-sourced console output. This allows the use of existing, production logging facilities or the possibiltiy to use advanced structure in logging, such as console output which is encapsulated in JSON. The same PR that introduces this support also introduces aloggerproperty to theGraphQLRequestContextthat is exposed toGraphQLDataSources and Apollo Server plugins, making it possible to attach additional properties (as supported by the logger implementation) to specific requests, if desired, by leveraging custom implementations in those components respectively. When not provided, these will still output toconsole. PR #3894 - Drop use of
loglevel-debug. This removes the very long date and time prefix in front of each log line and also the support for theDEBUG=apollo-gateway:environment variable. Both of these were uncommonly necessary or seldom used (with the environment variable also being undocumented). The existing behavior can be preserved by providing aloggerthat usesloglevel-debug, if desired, and more details can be found in the PR. PR #3896 - Fix Typescript generic typing for datasource contexts #3865 This is a fix for the
TContexttypings of the gateway's exposedGraphQLDataSourceimplementations. In their current form, they don't work as intended, or in any manner that's useful for typing thecontextproperty throughout the class methods. This introduces a type argumentTContextto the class itself (which defaults toRecord<string, any>for existing implementations) and removes the non-operational type arguments on the class methods themselves. - Implement retry logic for requests to GCS PR #3836 Note: coupled with this change is a small alteration in how the gateway polls GCS for updates in managed mode. Previously, the tick was on a specific interval. Now, every tick starts after the round of fetches to GCS completes. For more details, see the linked PR.
- Gateway issues health checks to downstream services via
serviceHealthCheckconfiguration option. Note: expected behavior differs between managed and unmanaged federation. See PR for new test cases and documentation. #3930
- BREAKING: The behavior and signature of
RemoteGraphQLDataSource'sdidReceiveResponsemethod has been changed. No changes are necessary unless your implementation has overridden the default behavior of this method by either extending the class and overriding the method or by providingdidReceiveResponseas a parameter to theRemoteGraphQLDataSource's constructor options. Implementations which have provided their owndidReceiveResponseusing either of these methods should view the PR linked here for details on what has changed. PR #3743 - NEW: Setting the
apqoption totrueon theRemoteGraphQLDataSourcewill enable the use of automated persisted queries (APQ) when sending queries to downstream services. Depending on the complexity of queries sent to downstream services, this technique can greatly reduce the size of the payloads being transmitted over the network. Downstream implementing services must also support APQ functionality to participate in this feature (Apollo Server does by default unless it has been explicitly disabled). As with normal APQ behavior, a downstream server must have received and registered a query once before it will be able to serve an APQ request. #3744 - NEW: Experimental feature: compress downstream requests via generated fragments #3791 This feature enables the gateway to generate fragments for queries to downstream services in order to minimize bytes over the wire and parse time. This can be enabled via the gateway config by setting
experimental_autoFragmentization: true. It is currently disabled by default. - Introduce
make-fetch-happenpackage. RemovecachedFetcherin favor of the caching implementation provided by this package. #3783
- Update to include fixes from
@apollo/federation.
- Reduce interface expansion for types contained to a single service #3582
- Instantiate one
CachedFetcherper gateway instance. This resolves a condition where multiple federated gateways would utilize the same cache store could result in anExpected undefined to be a GraphQLSchemaerror. #3704 - Gateway: minimize downstream request size #3737
- experimental: Allow configuration of the query plan store by introducing an
experimental_approximateQueryPlanStoreMiBproperty to theApolloGatewayconstructor options which overrides the default cache size of 30MiB. #3755
- Fix onSchemaChange callbacks for unmanaged configs #3605
- Gateway over-merging fields of unioned types #3581
- Begin supporting executable directives in federation #3464
- Fix Gateway / Playground Query Plan view #3418
- Gateway schema change listener bug + refactor #3411 introduces a change to the
experimental_didUpdateCompositionhook andexperimental_pollIntervalconfiguration behavior.- Previously, the
experimental_didUpdateCompositionhook wouldn't be reliably called unless theexperimental_pollIntervalwas set. If it was called, it was sporadic and didn't necessarily mark the timing of an actual composition update. After this change, the hook is called on a successful composition update. - The
experimental_pollIntervalconfiguration option now affects both the GCS polling interval when gateway is configured for managed federation, as well as the polling interval of services. The former being newly introduced behavior.
- Previously, the
- Gateway cached DataSource bug #3412 introduces a fix for managed federation users where
DataSources wouldn't update correctly if a service's url changed. This bug was introduced with heavier DataSource caching in #3388. By inspecting theurlas well,DataSources will now update correctly when a composition update occurs. - Gateway - don't log updates on startup #3421 Fine tune gateway startup logging - on load, instead of logging an "update", log the service id, variant, and mode in which gateway is running.
- Add export for experimental observability functions types. #3371
- Fix double instantiation of DataSources #3388
- Fix debug query plan logging #3376
- Add
contextobject toGraphQLDataSource.didReceiveResponsearguments #3360
- Make service definition cache local to ApolloGateway object #3191
- Fix value type behavior within composition and execution #3182
- Validate variables at the gateway level #3213
- Optimize buildQueryPlan when two FetchGroups are on the same service #3135
- Construct and use RemoteGraphQLDataSource to issue introspection query to Federated Services #3120
- Add experimental observability functions #3110
- Handle
null@requires selections correctly during execution #3138
- Proxy errors from downstream services #3019
- Handle schema defaultVariables correctly within downstream fetches #2963
- Fix
@requiresbug preventing array and null values. PR #2928
- Relax constraints of root operation type names in validation #2783
- Resolve an issue with _proto_ pollution in deepMerge() #2779