Merge pull request #4453 from apollographql/glasser/apollo-config

Make communicating with Apollo's commercial products into ordinary plugins

CHANGELOG.md

@@ -13,6 +13,30 @@ The version headers in this history reflect the versions of Apollo Server itself
 
 ## v2.18.0
 
+- `apollo-server-core`: When Apollo Server is configured with an Apollo API key, the URLs it uses to connect to Apollo's servers have changed. If the environment in which you run your servers requires you to explicitly allow connections by domain, you will need to add the new domain names. Usage reporting previously connected to https://engine-report.apollodata.com/ and now connects to https://usage-reporting.api.apollographql.com/; schema reporting previously connected to https://edge-server-reporting.api.apollographql.com/ and now connects to https://schema-reporting.api.apollographql.com/ . [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- Apollo Server's support for communicating with Apollo’s commercial products has been refactored into three separate plugins exported from `apollo-server-core` (for usage reporting, schema reporting, and inline tracing), configured using the standard `plugins` option. The `engine` option continues to work for backwards compatibility in the 2.x series; support for `engine` will be deprecated in Apollo Server 3.x. Full details are available in [the migration guide](https://www.apollographql.com/docs/apollo-server/migration-engine-plugins/). [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- To consistently support tracing, inline tracing is enabled by default on federated implementing services, even when an Apollo API key is provided.  Previously it was not enabled when an API key was provided. You can disable it with `ApolloServerPluginInlineTraceDisabled`. [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- The `apollo-engine-reporting` npm package has been obsoleted and will no longer receive updates. [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- The `apollo-engine-reporting-protobuf` package has been renamed to `apollo-reporting-protobuf`.  No new versions of the old package will be published. [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- Implementations of `ApolloServer` for serverless frameworks such as Lambda now override the `serverlessFramework()` method to return true.  We have changed our own integrations, but other implementations that extend `ApolloServer` which need this behavior should do the same.  Support for `engine.sendReportsImmediately` will be dropped in Apollo Server 3.x. [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- The `GraphQLServiceContext` type passed to the plugin serverWillStart method now contains `apollo` and `serverlessFramework` values. [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- `apollo-server-core` / `apollo-server-plugin-base`: The request pipeline plugin API now supports a `serverWillStop` lifecycle hook. [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- `apollo-server-core`: Previously, the usage reporting functionality registered one-shot handlers for the `SIGINT` and `SIGTERM` signals, which it used to send one final usage report before re-sending the signal to itself to continue shutdown. These signals handlers were installed by default if you enabled usage or schema reporting, and could be disabled by passing `engine.handleSignals: false`. Now, termination signal handling is the responsibility of Apollo Server as a whole rather than something specific to usage reporting. Apollo Server itself now registers these one-shot signal handlers, which trigger `ApolloServer.stop()`. This allows any plugin that implements the new `serverWillStop` callback to hook into shutdown logic, not just the usage reporting code. Similarly to before, these signal handlers are registered by default but can be disabled by via an option. We've changed the option name to `stopOnTerminationSignals: false` as it is more explicit about the behavior. [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- `apollo-server-core`: The default logger implementation (if you don't specify your own `logger` or specify `debug`) now logs at the INFO level instead of the WARN level. The main effect is on a few built-in plugins which log one INFO message at startup; if a custom plugin logs at the INFO level then those messages will be visible by default as well. [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
+- `apollo-server-core`: Parse and validate any schema passed via `overrideReportedSchema` to the schema reporting plugin, and throw accordingly on unparsable or invalid schemas.
+
+- Using Apollo Server from TypeScript now requires TypeScript 3.8 due to the use of the `import type` and `export type` directives. (If this proves to be a major problem we can revert this choice, but it makes it easier for us to ensure that certain large dependencies are only loaded when needed.) [PR #4453](https://github.com/apollographql/apollo-server/pull/4453)
+
 - Updated `@apollographql/graphql-playground-react` to 1.7.33 to include [an upstream fix](https://github.com/apollographql/graphql-playground/commit/1c102692bfbb717688827204186c15cb92629b3a). [PR #4550](https://github.com/apollographql/apollo-server/pull/4550)
 
 ## v2.17.0

ROADMAP.md

@@ -30,7 +30,7 @@ The next version of Apollo Server is a principled implementation of a production
     * Supports enterprise-scale traffic through integrated caching layers and efficient execution.
 * Production teams have **tools and hooks for confidently running and monitoring their graph** in production.
     * Graph and request lifecycles are well-documented and include detailed observability hooks for teams to set up monitoring.
-    * Apollo Server includes built-in support for Apollo Graph Manager.
+    * Apollo Server includes built-in support for Apollo Studio.
     * A new request pipeline gives teams more control over request lifecycles, including validation, parsing, and error handling.
 
 ## How we get there
@@ -80,7 +80,7 @@ The work to accomplish these goals is grouped into the following work:
 * **First-class support for subscriptions, `@defer`, and `@stream`:**
     * Subscriptions
         * Implement a WebSocket transport using the new transport interface described above.
-        * Support subscriptions in tracing data sent to Apollo Graph Manager.
+        * Support subscriptions in tracing data sent to Apollo Studio.
         * Query planner support.
     * `@defer` and `@stream`
         * Support response streams in the HTTP transport.

docs/gatsby-config.js

@@ -65,12 +65,16 @@ module.exports = {
             'api/apollo-server',
             'api/apollo-federation',
             'api/apollo-gateway',
+            'api/plugin/usage-reporting',
+            'api/plugin/schema-reporting',
+            'api/plugin/inline-trace',
             'api/graphql-tools',
           ],
           Appendices: [
             'proxy-configuration',
             'migration-two-dot',
             'migration-file-uploads',
+            'migration-engine-plugins',
           ],
         },
       },

docs/source/api/apollo-gateway.mdx

@@ -21,7 +21,7 @@ example of using `ApolloGateway`, see [The gateway](/federation/gateway/).
 
   * `serviceList`: `ServiceDefinition[]`
 
-    > **Do not provide this option if you are using [managed configuration](https://www.apollographql.com/docs/graph-manager/federation/#managed-configuration).** If you
+    > **Do not provide this option if you are using [managed configuration](https://www.apollographql.com/docs/studio/managed-federation/overview/).** If you
     > are _not_ using managed configuration, this option is **required**.
 
     An array representing the implementing services that the gateway will use