Release 2.11.0

CHANGELOG.md

@@ -5,11 +5,9 @@ The version headers in this history reflect the versions of Apollo Server itself
 - [__CHANGELOG for `@apollo/gateway`__](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-gateway/CHANGELOG.md)
 - [__CHANGELOG for `@apollo/federation`__](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-federation/CHANGELOG.md)
 
-### vNEXT
+### v2.11.0
 
-> The changes noted within this `vNEXT` section have not been released yet.  New PRs and commits which introduce changes should include an entry in this `vNEXT` section as part of their development.  When a release is being prepared, a new header will be (manually) created below and the the appropriate changes within that release will be moved into the new section.
-
-- _Nothing yet! Stay tuned._
+- The range of accepted `peerDepedencies` versions for `graphql` has been widened to include `graphql@^15.0.0-rc.2` so as to accommodate the latest release-candidate of the `graphql@15` package, and an intention to support it when it is finally released on the `latest` npm tag.  While this change will subdue peer dependency warnings for Apollo Server packages, many dependencies from outside of this repository will continue to raise similar warnings until those packages own `peerDependencies` are updated.  It is unlikely that all of those packages will update their ranges prior to the final version of `graphql@15` being released, but if everything is working as expected, the warnings can be safely ignored. [PR #3825](https://github.com/apollographql/apollo-server/pull/3825)
 
 ### v2.10.1
 

docs/source/api/apollo-gateway.mdx

@@ -41,6 +41,18 @@ example of using `ApolloGateway`, see [Implementing a federated graph](/federati
     });
     ```
 
+  * `apq`: `Boolean`
+
+    When enabled the gateway will attempt to use [automated persisted queries (APQ)](https://www.apollographql.com/docs/apollo-server/performance/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 typical APQ behavior, a downstream server
+    must have received and registered a query once before it will be able to
+    serve an APQ request.
+
   * `buildService`: `(service: ServiceDefinition) => GraphQLDataSource`
 
     Define this function to customize your gateway's data transport to some or
@@ -158,24 +170,34 @@ These methods are described in detail below.
     });
     ```
 
-  ### `didReceiveResponse`: `(response: Response, request: Request, context: TContext) => Promise<TResult>`
+  ### `didReceiveResponse`: `(requestContext: {request: GraphQLRequest, response: GraphQLResponse, context: Record<string, any>}) => Promise<GraphQLResponse>`
 
     Override this method to customize the gateway's behavior after completing
-    a fetch to the implementing service. The method takes the original `request`, the implementing service's `response`, and the current `context` as parameters, allowing you to modify any combination of the context and the final result of the fetch.
-
-    This method must return an object that matches the structure of a
-    [`GraphQLExecutionResult`](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-server-types/src/index.ts#L105-L109) (i.e., it
-    should include `data`, `errors`, and/or `extensions` fields).
-
-    ```js{2-9}
+    a fetch to the implementing service. The method receives an object (a
+    [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/2562d096/packages/apollo-server-types/src/index.ts#L61-L92))
+    containing the `request` (a `GraphQLRequest`), the implementing service's
+    `response` (a `GraphQLResponse`), and the current `context` as parameters.
+    This allows modification of the context and the final result of the fetch.
+
+    The `http` property on the `request` and `response` objects will contain
+    additional HTTP-specific properties, like `headers`.
+
+    Any implementation of this method must return an object that matches the
+    structure of a [`GraphQLResponse`](https://github.com/apollographql/apollo-server/blob/2562d096/packages/apollo-server-types/src/index.ts#L43-L48)
+    (i.e., it should include `http`, `data`, `errors`, and/or `extensions`
+    fields).  If no modifications are necessary, simply return the original
+    `response`.
+
+    ```javascript
     class CookieDataSource extends RemoteGraphQLDataSource {
-      didReceiveResponse(response, request, context) {
-        const body = super.didReceiveResponse(response, request, context);
+      didReceiveResponse({ response, request, context }) {
         const cookie = request.http.headers.get('Cookie');
         if (cookie) {
           context.responseCookies.push(cookie);
         }
-        return body;
+
+        // Return the response back, even when unchanged.
+        return response;
       }
     }
     ```

docs/source/federation/implementing.md

@@ -313,14 +313,15 @@ const { ApolloGateway, RemoteGraphQLDataSource } = require('@apollo/gateway');
 
 class DataSourceWithServerId extends RemoteGraphQLDataSource {
   // highlight-start
-  async didReceiveResponse(response, request, context) {
-    const body = await super.didReceiveResponse(response, request, context);
+  async didReceiveResponse({ response, request, context }) {
     // Parse the Server-Id header and add it to the array on context
-    const serverId = response.headers.get('Server-Id');
+    const serverId = response.http.headers.get('Server-Id');
     if (serverId) {
       context.serverIds.push(serverId);
     }
-    return body;
+
+    // Return the response, even when unchanged.
+    return response;
   }
   // highlight-end
 }