apollographql · abernix · Apr 7, 2020 · Feb 10, 2020 · Feb 11, 2020 · Mar 3, 2020
diff --git a/.circleci/config.yml b/.circleci/config.yml
@@ -37,10 +37,10 @@ jobs:
   # at https://hub.docker.com/r/circleci/node/.
 
   # NODE: Note certain tests are currently being skipped for Node.js 6.
-  NodeJS 6:
-    executor: { name: oss/node, tag: '6' }
-    steps:
-      - common_test_steps
+  # NodeJS 6:
+  #   executor: { name: oss/node, tag: '6' }
+  #   steps:
+  #     - common_test_steps
 
   NodeJS 8:
     executor: { name: oss/node, tag: '8' }
@@ -92,8 +92,8 @@ workflows:
   version: 2
   Build:
     jobs:
-      - NodeJS 6:
-          <<: *common_non_publish_filters
+      # - NodeJS 6:
+      #     <<: *common_non_publish_filters
       - NodeJS 8:
           <<: *common_non_publish_filters
       - NodeJS 10:
@@ -104,15 +104,15 @@ workflows:
           name: Package tarballs
           <<: *common_non_publish_filters
           requires:
-            - NodeJS 6
+            # - NodeJS 6
             - NodeJS 8
             - NodeJS 10
             - NodeJS 12
       - oss/dry_run:
           name: Dry-run
           <<: *common_publish_filters
           requires:
-            - NodeJS 6
+            # - NodeJS 6
             - NodeJS 8
             - NodeJS 10
             - NodeJS 12

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -5,6 +5,15 @@ 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)
 
+### v2.12.0
+
+- `apollo-server-core`: Support providing a custom logger implementation (e.g. [`winston`](https://npm.im/winston), [`bunyan`](https://npm.im/bunyan), etc.) to capture server console messages.  Though there has historically been limited output from Apollo Server, some messages are important to capture in the larger context of production logging facilities or can benefit from using more advanced structure, like JSON-based logging.  This also introduces a `logger` property to the `GraphQLRequestContext` that is exposed to plugins, making it possible for plugins to leverage the same server-level logger, and allowing implementors to create request-specific log contexts, if desired.  When not provided, these will still output to `console`. [PR #3894](https://github.com/apollographql/apollo-server/pull/3894)
+- `apollo-server-core`: When operating in gateway mode using the `gateway` property of the Apollo Server constructor options, the failure to initialize a schema during initial start-up, e.g. connectivity problems, will no longer result in the federated executor from being assigned when the schema eventually becomes available.  This precludes a state where the gateway may never become available to serve federated requests, even when failure conditions are no longer present. [PR #3811](https://github.com/apollographql/apollo-server/pull/3811)
+- `apollo-server-core`: Prevent a condition which prefixed an error message on each request when the initial gateway initialization resulted in a Promise-rejection which was memoized and re-prepended with `Invalid options provided to ApolloServer:` on each request. [PR #3811](https://github.com/apollographql/apollo-server/pull/3811)
+- `apollo-server-express`: Disable the automatic inclusion of the `x-powered-by: express` header. [PR #3821](https://github.com/apollographql/apollo-server/pull/3821)
+- `apollo-engine-reporting`: Avoid creating new arrays when building trace trees. [PR #3479](https://github.com/apollographql/apollo-server/pull/3479)
+- `apollo-server-core`: Bump `graphql` `peerDependencies` range to include `^15.0.0`. [PR #3944](https://github.com/apollographql/apollo-server/pull/3944)
+
 ### v2.11.0
 
 - 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)

diff --git a/docs/source/api/apollo-gateway.mdx b/docs/source/api/apollo-gateway.mdx
@@ -99,13 +99,19 @@ example of using `ApolloGateway`, see [The gateway](/federation/gateway/).
     });
     ```
 
+  * `logger`: `Logger`
+
+    A logging implementation to be used in place of `console`.  The implementation must provide the methods which satisfy the requirements of [the `Logger` interface](https://github.com/apollographql/apollo-server/blob/80a12d89ea1ae9a0892f4a81d9213eddf95ca965/packages/apollo-server-types/src/index.ts#L114-L121) (i.e. it must provide `debug`, `info`, `warn` and `error` methods).  When a custom logger is provided, it will receive all levels of logging and it is up to the logger itself to determine how it wishes to handle each level.  When a custom logger is _not_ provided, Gateway will default to outputting `warn` and `error` levels unless `debug: true` is specified,  in which case it will output all log levels (i.e. `debug` through `error`).
+
+    Additionally, this `logger` will be made available on the `GraphQLRequestContext` and available to plugins.  This allows a plugin to, e.g., augment the logger on a per-request basis within the `requestDidStart` life-cycle hook.
+
   * `debug`: `Boolean`
 
     If `true`, the gateway logs startup messages, along with the query plan for
     each incoming request. The default value is `false`.
-    
+
   * `fetcher`: `typeof fetch`
-  
+
     When specified, overrides the default
     [Fetch API](https://fetch.spec.whatwg.org/#fetch-api) implementation
     which is used when communicating with downstream services.  By default,
@@ -115,7 +121,7 @@ example of using `ApolloGateway`, see [The gateway](/federation/gateway/).
     `fetcher: require('node-fetch')`) or different [default options for
     `make-fetch-happen`](https://www.npmjs.com/package/make-fetch-happen#extra-options)
     can be defined entirely. E.g.:
-    
+
     ```javascript
     const gateway = new ApolloGateway({
       /* ... */
@@ -128,6 +134,14 @@ example of using `ApolloGateway`, see [The gateway](/federation/gateway/).
     });
     ```
 
+  * `serviceHealthCheck`: `boolean`
+
+    When set to true, the gateway will issue a small query (`{ __typename }`) to
+    its downstream services on load and on schema update. On load, the gateway
+    will throw an error if any of the requests fail. On schema update, the
+    gateway will not roll over to the new schema or service configuration if any
+    of the requests fail, but it will try again at the next poll interval.
+
   * `experimental_approximateQueryPlanStoreMiB`: `number`
 
     > **This property is experimental.**  It may be removed or change at any time, even within a patch release.
@@ -150,6 +164,20 @@ const server = new ApolloServer({
 });
 ```
 
+### `serviceHealthCheck`
+
+Calling this function on the gateway will issue a small query (`{ __typename }`)
+to each downstream service to ensure they are all responsive. This function
+`throw`s on failure and returns a `Promise` to be `await`ed.
+
+#### Parameters
+
+* `serviceMap`: `DataSourceMap`
+
+  A map of data sources can optionally be provided to this function in order to
+  modify where the health checks will be issued. By default, the gateway will
+  use the existing `this.serviceMap` for issuing the health check requests.
+
 ## `RemoteGraphQLDataSource`
 
 A `RemoteGraphQLDataSource` object represents a connection between your

diff --git a/docs/source/api/apollo-server.md b/docs/source/api/apollo-server.md
@@ -68,6 +68,12 @@ new ApolloServer({
     | AWS Lambda | <code>{<br/>&nbsp;&nbsp;event: [`APIGatewayProxyEvent`](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/50adc95acf873e714256074311353232fcc1b5ed/types/aws-lambda/index.d.ts#L78-L92),<br/>&nbsp;&nbsp;context: [`LambdaContext`](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/50adc95acf873e714256074311353232fcc1b5ed/types/aws-lambda/index.d.ts#L510-L534)<br/>}</code> |
     | Micro | <code>{ req: [`MicroRequest`](https://github.com/apollographql/apollo-server/blob/c356bcf3f2864b8d2fcca0add455071e0606ef46/packages/apollo-server-micro/src/types.ts#L3-L5), res: [`ServerResponse`](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/50adc95acf873e714256074311353232fcc1b5ed/types/node/v10/http.d.ts#L145-L158) }</code> |
 
+  * `logger`: `Logger`
+
+    A logging implementation to be used in place of `console`.  The implementation must provide the methods which satisfy the requirements of [the `Logger` interface](https://github.com/apollographql/apollo-server/blob/80a12d89ea1ae9a0892f4a81d9213eddf95ca965/packages/apollo-server-types/src/index.ts#L114-L121) (i.e. it must provide `debug`, `info`, `warn` and `error` methods).  When a custom logger is provided, it will receive all levels of logging and it is up to the logger itself to determine how it wishes to handle each level.  When a custom logger is _not_ provided, Apollo Server will default to outputting `warn` and `error` levels unless `debug: true` is specified,  in which case it will output all log levels (i.e. `debug` through `error`).
+
+    Additionally, this `logger` will be made available on the `GraphQLRequestContext` and available to plugins.  This allows a plugin to, e.g., augment the logger on a per-request basis within the `requestDidStart` life-cycle hook.
+
   * `rootValue`: <`Any`> | <`Function`>
 
     A value or function called with the parsed `Document`, creating the root value passed to the graphql executor. The function is useful if you wish to provide a different root value based on the query operation type.
@@ -337,6 +343,10 @@ addMockFunctionsToSchema({
   a service. You can also specify an API key with the `ENGINE_API_KEY`
   environment variable, although the `apiKey` option takes precedence.
 
+* `logger`: `Logger`
+
+  By default, this will inherit from the `logger` provided to `ApolloServer` which defaults to `console` when not provided.  If specified within the `EngineReportingOptions` it can be used to send engine reporting to a separate logger.  If provided, the implementation must provide the methods which satisfy the requirements of [the `Logger` interface](https://github.com/apollographql/apollo-server/blob/80a12d89ea1ae9a0892f4a81d9213eddf95ca965/packages/apollo-server-types/src/index.ts#L114-L121) (i.e. it must provide `debug`, `info`, `warn` and `error` methods).
+
 *  `calculateSignature`: (ast: DocumentNode, operationName: string) => string
 
    Specify the function for creating a signature for a query.

diff --git a/docs/source/integrations/plugins.md b/docs/source/integrations/plugins.md
@@ -269,6 +269,15 @@ const server = new ApolloServer({
 
 The `requestDidStart` event fires whenever Apollo Server begins fulfilling a GraphQL request.
 
+```typescript
+requestDidStart?(
+  requestContext: WithRequired<
+    GraphQLRequestContext<TContext>,
+    'request' | 'context' | 'logger'
+  >
+): GraphQLRequestListener<TContext> | void;
+```
+
 This function can optionally return an object that includes functions for responding
 to request lifecycle events that might follow `requestDidStart`.
 
@@ -318,7 +327,7 @@ does not occur.
 parsingDidStart?(
   requestContext: WithRequired<
     GraphQLRequestContext<TContext>,
-    'metrics' | 'source'
+    'metrics' | 'source' | 'logger'
   >,
 ): (err?: Error) => void | void;
 ```
@@ -338,7 +347,7 @@ available at this stage, because parsing must succeed for validation to occur.
 validationDidStart?(
   requestContext: WithRequired<
     GraphQLRequestContext<TContext>,
-    'metrics' | 'source' | 'document'
+    'metrics' | 'source' | 'document' | 'logger'
   >,
 ): (err?: ReadonlyArray<Error>) => void | void;
 ```
@@ -355,7 +364,7 @@ both the `operationName` string and `operation` AST are available.
 didResolveOperation?(
   requestContext: WithRequired<
     GraphQLRequestContext<TContext>,
-    'metrics' | 'source' | 'document' | 'operationName' | 'operation'
+    'metrics' | 'source' | 'document' | 'operationName' | 'operation' | 'logger'
   >,
 ): ValueOrPromise<void>;
 ```
@@ -371,7 +380,7 @@ are invoked in series, and the first non-null response is used.
 responseForOperation?(
   requestContext: WithRequired<
     GraphQLRequestContext<TContext>,
-    'metrics' | 'source' | 'document' | 'operationName' | 'operation'
+    'metrics' | 'source' | 'document' | 'operationName' | 'operation' | 'logger'
   >,
 ): ValueOrPromise<GraphQLResponse | null>;
 ```
@@ -385,7 +394,7 @@ GraphQL operation specified by a request's `document` AST.
 executionDidStart?(
   requestContext: WithRequired<
     GraphQLRequestContext<TContext>,
-    'metrics' | 'source' | 'document' | 'operationName' | 'operation'
+    'metrics' | 'source' | 'document' | 'operationName' | 'operation' | 'logger'
   >,
 ): (err?: Error) => void | void;
 ```
@@ -399,7 +408,7 @@ parsing, validating, or executing a GraphQL operation.
 didEncounterErrors?(
   requestContext: WithRequired<
     GraphQLRequestContext<TContext>,
-    'metrics' | 'source' | 'errors'
+    'metrics' | 'source' | 'errors' | 'logger'
   >,
 ): ValueOrPromise<void>;
 ```
@@ -414,7 +423,7 @@ if the GraphQL operation encounters one or more errors.
 willSendResponse?(
   requestContext: WithRequired<
     GraphQLRequestContext<TContext>,
-    'metrics' | 'response'
+    'metrics' | 'response' | 'logger'
   >,
 ): ValueOrPromise<void>;
 ```