Merge branch 'abernix/add-willResolveField-and-didResolveField' into …

…abernix/migrate-cache-control-to-plugin-api

CHANGELOG.md

@@ -7,10 +7,20 @@ The version headers in this history reflect the versions of Apollo Server itself
 
 ### vNEXT
 
-> 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.
+> 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 appropriate changes within that release will be moved into the new section.
 
+- _Nothing yet! Stay tuned!_
+
+### v2.13.0
+
+> [See complete versioning details.](https://github.com/apollographql/apollo-server/commit/e37384a49b2bf474eed0de3e9f4a1bebaeee64c7)
+
+- Allow passing a `WebSocket.Server` to `ApolloServer.installSubscriptionHandlers`. [PR #2314](https://github.com/apollographql/apollo-server/pull/2314)
 - `apollo-server-lambda`: Support file uploads on AWS Lambda [Issue #1419](https://github.com/apollographql/apollo-server/issues/1419) [Issue #1703](https://github.com/apollographql/apollo-server/issues/1703) [PR #3926](https://github.com/apollographql/apollo-server/pull/3926)
-- **breaking** `apollo-engine-reporting-protobuf`: Drop legacy fields that were never used by `apollo-engine-reporting`. Added new fields `StatsContext` to allow `apollo-server` to send summary stats instead of full traces, and renamed `FullTracesReport` to `Report` and `Traces` to `TracesAndStats` since reports now can include stats as well as traces.
+- `apollo-engine-reporting`: Fix inadvertant conditional formatting which prevented automated persisted query (APQ) hits and misses from being reported to Apollo Graph Manager. [PR #3986](https://github.com/apollographql/apollo-server/pull/3986)
+- `apollo-engine-reporting`: Deprecate the `ENGINE_API_KEY` environment variable in favor of its new name, `APOLLO_KEY`.  Continued use of `ENGINE_API_KEY` will result in deprecation warnings and support for it will be removed in a future major version. [#3923](https://github.com/apollographql/apollo-server/pull/3923)
+- `apollo-engine-reporting`: Deprecated the `APOLLO_SCHEMA_TAG` environment variable in favor of its new name, `APOLLO_GRAPH_VARIANT`.  Similarly, within the `engine` configuration object, the `schemaTag` property has been renamed `graphVariant`.  The functionality remains otherwise unchanged, but their new names mirror the name used within Apollo Graph Manager.  Continued use of the now-deprecated names will result in deprecation warnings and support will be dropped completely in the next "major" update.  To avoid misconfiguration, a runtime error will be thrown if _both_ new and deprecated names are set. [PR #3855](https://github.com/apollographql/apollo-server/pull/3855)
+- `apollo-engine-reporting-protobuf`: __(This is a breaking change only if you directly depend on `apollo-engine-reporting-protobuf`.)__ Drop legacy fields that were never used by `apollo-engine-reporting`. Added new fields `StatsContext` to allow `apollo-server` to send summary stats instead of full traces, and renamed `FullTracesReport` to `Report` and `Traces` to `TracesAndStats` since reports now can include stats as well as traces.
 
 ### v2.12.0
 

docs/package.json

@@ -6,8 +6,8 @@
     "serve": "gatsby serve"
   },
   "dependencies": {
-    "gatsby": "2.20.17",
-    "gatsby-theme-apollo-docs": "4.1.4",
+    "gatsby": "2.21.9",
+    "gatsby-theme-apollo-docs": "4.2.2",
     "react": "16.13.1",
     "react-dom": "16.13.1"
   }

docs/source/api/graphql-tools.md

@@ -223,7 +223,7 @@ const resolvers = {
 
 ### context: { [key: string]: any }
 
-GraphQL context that is going to be past to subschema execution or subsciption call.
+GraphQL context that is going to be passed to subschema execution or subscription call.
 
 ### info: GraphQLResolveInfo
 

docs/source/data/file-uploads.md

@@ -34,7 +34,7 @@ const resolvers = {
     singleUpload: (parent, args) => {
       return args.file.then(file => {
         //Contents of Upload scalar: https://github.com/jaydenseric/graphql-upload#class-graphqlupload
-        //file.stream is a node stream that contains the contents of the uploaded file
+        //file.createReadStream() is a readable node stream that contains the contents of the uploaded file
         //node stream api: https://nodejs.org/api/stream.html
         return file;
       });

docs/source/data/resolvers.mdx

@@ -262,7 +262,7 @@ const typeDefs = gql`
   # A book has a title and author
   type Book {
     title: String!
-    author: [Author!]
+    author: Author!
   }
 
   # An author has a name

docs/source/data/subscriptions.md

@@ -234,6 +234,10 @@ const server = new ApolloServer(
 
 ## `PubSub` Implementations
 
+> **Please note**: By default `graphql-subscriptions` exports an in-memory (`EventEmitter`) event system to re-run subscriptions. This is not suitable for running in a serious production app, because there is no way to share subscriptions and publishes across many running servers.
+>
+> We recommend using one of the external `PubSub` implementations listed below for production environments.
+
 The Apollo Server implementation of `PubSub` can be replaced by another implementations of [PubSubEngine interface](https://github.com/apollographql/graphql-subscriptions/blob/master/src/pubsub-engine.ts). The community has created the following integrations:
 
 - [Redis](https://github.com/davidyaha/graphql-redis-subscriptions)
@@ -245,4 +249,4 @@ The Apollo Server implementation of `PubSub` can be replaced by another implemen
 - [Google Cloud Firestore](https://github.com/MrBoolean/graphql-firestore-subscriptions)
 - [Add your implementation...](https://github.com/apollographql/apollo-server/pull/new/master)
 
-You can implement a `PubSub` of your own, using the exported `PubSubEngine` interface from `apollo-server` or another integration. If you want to set up a GraphQL server using the `graphql-subscriptions` package, follow [this guide](https://www.apollographql.com/docs/graphql-subscriptions/).
+You can implement a `PubSub` of your own, using the exported `PubSubEngine` interface from `apollo-server` or another integration. If you want to set up a GraphQL server using the `graphql-subscriptions` package (not recommended for production), follow [this guide](https://www.apollographql.com/docs/graphql-subscriptions/).

docs/source/deployment/azure-functions.md

@@ -37,7 +37,7 @@ Http Functions:
         graphql: http://localhost:7071/api/graphql
 ```
 
-Go to [http://localhost:7071/api/apollo-example?name=Apollo](http://localhost:7071/api/apollo-example?name=Apollo) and verify if the text with the content: **Hello Apollo** is appearing at your browser.
+Go to [http://localhost:7071/api/graphql?name=Apollo](http://localhost:7071/api/apollo-example?name=Apollo) and verify if the text with the content: **Hello Apollo** is appearing at your browser.
 
 If you would like to remove the `api` from the url structure, set the prefix in your `host.json` file like below:
 

docs/source/federation/implementing-services.mdx

@@ -221,7 +221,7 @@ Also make sure to read about the [gateway's support for custom directives](./gat
 
 ## Securing implementing services
 
-Because of the power and flexibility of Apollo Federation's `_entities` field, your implementing services should **not** be directly accessible by clients. Instead, only your [gateway](./gateway/) should have access to your implementing serivces. Clients then communicate with the gateway:
+Because of the power and flexibility of Apollo Federation's `_entities` field, your implementing services should **not** be directly accessible by clients. Instead, only your [gateway](./gateway/) should have access to your implementing services. Clients then communicate with the gateway:
 
 <FederationArchitecture />
 

docs/source/federation/introduction.mdx

@@ -37,6 +37,10 @@ Apollo Server provides libraries for acting both as an implementing service and
 
 > Apollo Federation does not currently support [GraphQL subscription operations](https://www.apollographql.com/docs/react/data/subscriptions/).
 
+The following presentation by [Mandi Wise](https://twitter.com/mandiwise) further describes the architecture of Apollo Federation and walks through implementing a federated graph:
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/v_1bn2sHdk4?start=81" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+
 ## Core principles
 
 ### Incremental adoption

docs/source/federation/metrics.md

@@ -20,7 +20,7 @@ Ensure that all dependencies on `apollo-server` are at version `2.7.0` or higher
 
 These options will cause the Apollo gateway to collect tracing information from the underlying federated services and pass them on, along with the query plan, to the Apollo metrics ingress. Currently, only Apollo Server supports detailed metrics insights as an implementing service, but we would love to work with you to implement the protocol in other languages!
 
-> NOTE: By default, metrics will be reported to the `current` variant. To change the variant for reporting, set the `ENGINE_GRAPH_VARIANT` environment variable.
+> NOTE: By default, metrics will be reported to the `current` variant. To change the variant for reporting, set the `APOLLO_GRAPH_VARIANT` environment variable.
 
 ## How tracing data is exposed from a federated service
 
@@ -30,7 +30,7 @@ The Apollo gateway looks to the `extensions` field of all service responses for
 
 ## How traces are constructed and aggregated
 
-The Apollo gateway constructs traces in the shape of the [query plan](https://www.apollographql.com/docs/apollo-server/federation/implementing/#inspecting-query-plans), embedding an individual `Trace` for each fetch that is performed in the query plan. This indicates the sub-query traces as well as which order they were fetched from the underlying services. The field-level statistics that the Apollo Platform aggregates from these traces are collected over the fields over which the operation was executed **in the federated services**. In other words, field stats are collected based on the operations the query planner makes rather than the operations that the clients make. On the other hand, operation-level statistics are aggregated over the operations exected **by the client**, which means that even if query-planning changes, statistics will still be corresponded to the same client-delivered operation.
+The Apollo gateway constructs traces in the shape of the [query plan](https://www.apollographql.com/docs/apollo-server/federation/implementing/#inspecting-query-plans), embedding an individual `Trace` for each fetch that is performed in the query plan. This indicates the sub-query traces as well as which order they were fetched from the underlying services. The field-level statistics that the Apollo Platform aggregates from these traces are collected over the fields over which the operation was executed **in the federated services**. In other words, field stats are collected based on the operations the query planner makes rather than the operations that the clients make. On the other hand, operation-level statistics are aggregated over the operations executed **by the client**, which means that even if query-planning changes, statistics will still be corresponded to the same client-delivered operation.
 
 ## How errors work
 

docs/source/federation/other-servers.md

@@ -5,15 +5,18 @@ sidebar_title: Third-party support
 
 The following is a list of known open source GraphQL server libraries that have built-in support for Apollo Federation.
 
-| Language    | Framework    | Library                                                                          |
-| ----------- | ------------ | -------------------------------------------------------------------------------- |
-| Go          | gqlgen       | [gqlgen](https://github.com/99designs/gqlgen/tree/master/plugin/federation)      |
-| Java        | graphql-java | [federation-jvm](https://github.com/apollographql/federation-jvm)                |
-| Kotlin      | graphql-java | [graphql-kotlin](https://github.com/ExpediaGroup/graphql-kotlin)                 |
-| PHP         | graphql-php  | [php-graphql-federation](https://github.com/pascaldevink/php-graphql-federation) |
-| PHP         | wp-graphql   | [wp-graphql-federation](https://github.com/wp-graphql/wp-graphql-federation)     |
-| Python      | ariadne      | [ariadne](https://github.com/mirumee/ariadne)                                    |
-| Python      | graphene     | [graphene-federation](https://github.com/preply/graphene-federation)             |
-| Ruby        | graphql-ruby | [apollo-federation-ruby](https://github.com/Gusto/apollo-federation-ruby)        |
+| Language    | Framework     | Library                                                                          |
+| ----------- | ------------- | -------------------------------------------------------------------------------- |
+| Go          | gqlgen        | [gqlgen](https://github.com/99designs/gqlgen/tree/master/plugin/federation)      |
+| Java        | graphql-java  | [federation-jvm](https://github.com/apollographql/federation-jvm)                |
+| Java        | graphql-java  | [graphql-java-federation](https://github.com/rkudryashov/graphql-java-federation)|
+| Kotlin      | graphql-java  | [graphql-kotlin](https://github.com/ExpediaGroup/graphql-kotlin)                 |
+| PHP         | graphql-php   | [php-graphql-federation](https://github.com/pascaldevink/php-graphql-federation) |
+| PHP         | wp-graphql    | [wp-graphql-federation](https://github.com/wp-graphql/wp-graphql-federation)     |
+| Python      | ariadne       | [ariadne](https://github.com/mirumee/ariadne)                                    |
+| Python      | graphene      | [graphene-federation](https://github.com/preply/graphene-federation)             |
+| Scala       | caliban       | [caliban](https://github.com/ghostdogpr/caliban)                                 |
+| Ruby        | graphql-ruby  | [apollo-federation-ruby](https://github.com/Gusto/apollo-federation-ruby)        |
+| Rust        | async-graphql | [async-graphql](https://github.com/async-graphql/async-graphql)                  |
 
 Do you maintain a library that implements Apollo Federation that isn't listed here? Please [submit a PR](https://github.com/apollographql/apollo-server/tree/master/docs/source/federation/other-servers.md) to be added to the list!

docs/source/integrations/middleware.md

@@ -42,4 +42,6 @@ app.listen({ port: 4000 }, () =>
 In the above example, the `app` parameter you provide to `applyMiddleware`
 is your middleware's top-level representation of your application. In Express applications, for example, this variable is commonly named `app`.
 
+By passing the existing `app` into `applyMiddleware`, Apollo Server can internally configure various middleware (including body parsing, the GraphQL Playground frontend, CORS support, etc.) without needing to separately apply those to the `app` with middleware mechanisms like Express.js' `app.use`.
+
 > **Note:** When integrating with hapi, call `applyMiddleware` with `await`.

docs/source/integrations/plugins.md

@@ -99,7 +99,7 @@ const myPlugin = {
 
       parsingDidStart(requestContext) {
         console.log('Parsing started!');
-      }
+      },
 
       validationDidStart(requestContext) {
         console.log('Validation started!');