apollographql · glasser · Jul 1, 2025 · Mar 28, 2023 · Apr 17, 2023 · Apr 17, 2023
diff --git a/.changeset/curvy-crabs-play.md b/.changeset/curvy-crabs-play.md
@@ -0,0 +1,8 @@
+---
+'@apollo/server-integration-testsuite': major
+'@apollo/server-plugin-response-cache': major
+'@apollo/server-gateway-interface': major
+'@apollo/server': major
+---
+
+Drop support for Node.JS v14, v16, and v20.
diff --git a/.changeset/five-tips-matter.md b/.changeset/five-tips-matter.md
@@ -0,0 +1,7 @@
+---
+'@apollo/server': major
+---
+
+Remove `precomputedNonce` landing page configuration option
+
+This option was introduced and subsequently deprecated in v4. Removing this configuration in v4 is strictly an improvement to the security of your landing page, and no longer exists in v5.
diff --git a/.changeset/large-lines-burn.md b/.changeset/large-lines-burn.md
@@ -0,0 +1,5 @@
+---
+'@apollo/server': patch
+---
+
+ApolloServerPluginSubscriptionCallback now takes a `fetcher` argument, like the usage and schema reporting plugins. The default value is Node's built-in fetch.
diff --git a/.changeset/orange-plants-change.md b/.changeset/orange-plants-change.md
@@ -0,0 +1,5 @@
+---
+'@apollo/server': major
+---
+
+Remove `status400ForVariableCoercionErrors` configuration option; this regression mitigation is now the default behavior in Apollo Server v5.
diff --git a/.circleci/config.yml b/.circleci/config.yml
@@ -56,17 +56,33 @@ jobs:
       - setup-node
       - run: npm run test:smoke
 
-  Full incremental delivery tests with graphql-js 17 canary:
+  Full incremental delivery tests with graphql 17 alpha 2:
     docker:
     - image: cimg/base:stable
     environment:
       INCREMENTAL_DELIVERY_TESTS_ENABLED: t
+      GRAPHQL_JS_VERSION: 17.0.0-alpha.2
     steps:
       - setup-node:
-          node-version: "18"
+          node-version: "20"
       # Install a prerelease of graphql-js 17 with incremental delivery support.
       # --legacy-peer-deps because nothing expects v17 yet.
-      - run: npm i --legacy-peer-deps [email protected]
+      - run: npm i --legacy-peer-deps "graphql@${GRAPHQL_JS_VERSION}"
+      - run: npm run test:ci
+      - run: npm run test:smoke
+
+  Test with recent graphql-js alpha:
+    docker:
+    - image: cimg/base:stable
+    environment:
+      GRAPHQL_JS_VERSION: 17.0.0-alpha.9
+    steps:
+      - setup-node:
+          node-version: "20"
+      # Install a newer prerelease of graphql-js 17; we do not yet support
+      # its incremental delivery format.
+      # --legacy-peer-deps because nothing expects v17 yet.
+      - run: npm i --legacy-peer-deps "graphql@${GRAPHQL_JS_VERSION}"
       - run: npm run test:ci
       - run: npm run test:smoke
 
@@ -142,18 +158,17 @@ workflows:
           matrix:
             parameters:
               node-version:
-                - "14"
-                - "16"
-                - "18"
                 - "20"
                 - "22"
+                - "24"
       - "Check for FIXM\x45"
       - Prettier
       - ESLint
       - Spell check
       - Codegen check
       - Smoke test built package
-      - Full incremental delivery tests with graphql-js 17 canary
+      - Full incremental delivery tests with graphql 17 alpha 2
+      - Test with recent graphql-js alpha
       - Changesets
   security-scans:
     jobs:

diff --git a/.codesandbox/ci.json b/.codesandbox/ci.json
@@ -9,5 +9,5 @@
     "packages/usage-reporting-protobuf"
   ],
   "sandboxes": ["apollo-server-typescript-3opde","apollo-server"],
-  "node": "18"
+  "node": "20"
 }
diff --git a/.config/mise/config.toml b/.config/mise/config.toml
@@ -3,11 +3,6 @@
 # It's what we use to set up tools in CI.
 
 [tools]
-# This actually uses the copy of npm that comes with Node to install the version
-# of npm that we want. Since we test on ancient versions of Node like v14, we
-# want to use a slightly more modern npm. Listing it before "node" means we'll
-# actually use it instead of the version that comes with node.
-"npm:npm" = "9.9.4"
 node = "22.17.0"
 
 [env]

diff --git a/.eslintignore b/.eslintignore
diff --git a/.eslintrc.cjs b/.eslintrc.cjs
diff --git a/CHANGELOG_historical.md b/CHANGELOG_historical.md
@@ -575,7 +575,7 @@ Certain undersupported and underused Apollo Server features have been removed in
 - `apollo-engine-reporting`: Fix regression introduced by [#3614](https://github.com/apollographql/apollo-server/pull/3614) which caused `PersistedQueryNotFoundError`, `PersistedQueryNotSupportedError` and `InvalidGraphQLRequestError` errors to be triggered before the `requestDidStart` handler triggered `treeBuilder`'s `startTiming` method. This fix preserves the existing behavior by special-casing these specific errors.  [#3638](https://github.com/apollographql/apollo-server/pull/3638) fixes [#3627](https://github.com/apollographql/apollo-server/issues/3627)
 - `apollo-server-cloud-functions`: Transmit CORS headers on `OPTIONS` request. [#3557](https://github.com/apollographql/apollo-server/pull/3557)
 - `apollo-server-caching`: De-compose options interface for `KeyValueCache.prototype.set` to accommodate better TSDoc annotations for its properties (e.g. to specify that `ttl` is defined in _seconds_). [#3619](https://github.com/apollographql/apollo-server/pull/3619)
-- `apollo-server-core`, `apollo-server-caching`: Introduce a `ttl` property, specified in seconds, on the options for automated persisted queries (APQ) which applies specific TTL settings to the cache `set`s during APQ registration.  Previously, all APQ cache records were set to 300 seconds.  Additionally, this adds support (to the underlying `apollo-server-caching` mechanisms) for a time-to-live (TTL) value of `null` which, when supported by the cache implementation, skips the assignment of a TTL value altogether.  This allows the cache's controller to determine when eviction happens (e.g. cache forever, and purge least recently used when the cache is full), which may be desireable for network cache stores (e.g. Memcached, Redis). [#3623](https://github.com/apollographql/apollo-server/pull/3623)
+- `apollo-server-core`, `apollo-server-caching`: Introduce a `ttl` property, specified in seconds, on the options for automated persisted queries (APQ) which applies specific TTL settings to the cache `set`s during APQ registration.  Previously, all APQ cache records were set to 300 seconds.  Additionally, this adds support (to the underlying `apollo-server-caching` mechanisms) for a time-to-live (TTL) value of `null` which, when supported by the cache implementation, skips the assignment of a TTL value altogether.  This allows the cache's controller to determine when eviction happens (e.g. cache forever, and purge least recently used when the cache is full), which may be desirable for network cache stores (e.g. Memcached, Redis). [#3623](https://github.com/apollographql/apollo-server/pull/3623)
 - `apollo-server-core`: Upgrade TS to 3.7.3 [#3618](https://github.com/apollographql/apollo-server/pull/3618)
 
 ## v2.9.14

@@ -1,7 +1,7 @@
 switcher:
   heading: 'Apollo Server'
   versions:
-    - label: v4
+    - label: v4–v5
       latest: true
       href: ./
     - label: v3
@@ -13,10 +13,12 @@ items:
     href: '.'
   - label: Get started
     href: './getting-started'
-  - label: New in v4
+  - label: New in v4 and v5
     children:
-      - label: Migrating to Apollo Server 4
+      - label: Migrating from Apollo Server 4
         href: './migration'
+      - label: Migrating from Apollo Server 3
+        href: './migration-from-v3'
       - label: Previous versions
         href: './previous-versions'
       - label: Changelog

@@ -506,9 +506,9 @@
 </td>
 <td>
 
-**Set this option to `true`.** It mitigates a regression introduced in Apollo Server v4 where the server returns a 200 status code (instead of 400) when a client query provides invalid variables. [Learn more.](../migration/#known-regressions)
+> Note: Apollo Server v5 defaults this option to `true`. This option is deprecated in v5 and will be ignored in a future major version.
 
-Apollo Server v5 will _always_ behave as if this option is `true` (and will ignore any provided value).
+**Apollo Server v4 users should set this option to `true` (or better yet, upgrade to v5).** It mitigates a regression introduced in Apollo Server v4 where the server returns a 200 status code (instead of 400) when a client query provides invalid variables.
 
 </td>
 </tr>
@@ -651,7 +651,7 @@
 
 The `response` object returned from `executeOperation` is a `GraphQLResponse`, which has `body` and `http` fields.
 
-Apollo Server 4 supports incremental delivery directives such as `@defer` and `@stream` (when combined with an appropriate version of `graphql-js`), and so the structure of `response.body` can represent either a single result or multiple results. `response.body.kind` is either `'single'` or `'incremental'`. If it is `'single'`, then incremental delivery has not been used, and `response.body.singleResult` is an object with `data`, `errors`, and `extensions` fields. If it is `'incremental'`, then `response.body.initialResult` is the initial result of the operation, and `response.body.subsequentResults` is an async iterator that will yield subsequent results. (The precise structure of `initialResult` and `subsequentResults` is defined by `graphql-js` and may change between the current pre-release of `graphql-js` v17 and its final release; if you write code that processes these values before `graphql-js` v17 has been released you may have to adapt it when the API is finalized.)
+Apollo Server 4 and 5 support incremental delivery directives such as `@defer` and `@stream` when combined with pre-release version `17.0.0-alpha.2` of `graphql-js`, and so the structure of `response.body` can represent either a single result or multiple results. `response.body.kind` is either `'single'` or `'incremental'`. If it is `'single'`, then incremental delivery has not been used, and `response.body.singleResult` is an object with `data`, `errors`, and `extensions` fields. If it is `'incremental'`, then `response.body.initialResult` is the initial result of the operation, and `response.body.subsequentResults` is an async iterator that will yield subsequent results. (The precise structure of `initialResult` and `subsequentResults` is defined by `graphql-js` and may change between the current pre-release of `graphql-js` v17 and its final release; if you write code that processes these values before `graphql-js` v17 has been released you may have to adapt it when the API is finalized. Apollo Server currently only supports `17.0.0-alpha.2`, not newer alphas which use a different format.)
 
 The `http` field contains an optional numeric `status` code and a `headers` map specifying any HTTP status code and headers that should be set.
 

@@ -5,7 +5,7 @@ api_reference: true
 
 import TopLevelAwait from "../shared/top-level-await.mdx"
 
-This API reference documents Apollo Server 4's [Express](https://expressjs.com/) integration, the `expressMiddleware` function.
+This API reference documents Apollo Server's [Express](https://expressjs.com/) integration, the `expressMiddleware` function.
 
 Apollo Server integrates with these Express versions through official integrations:
 - [**Express v4**](https://www.npmjs.com/package/@as-integrations/express4): Install with `npm install @as-integrations/express4`
@@ -15,7 +15,7 @@ You must also install Express itself. Both packages export a function named `exp
 
 <Note>
 
-The Express v4 integration is also bundled in `@apollo/server` at `@apollo/server/express4`. While you can use this bundled version now, we recommend installing the separate package. Express v5 requires the separate package, and future Apollo Server versions will remove the bundled integration.
+In Apollo Server 4, you can also import the Express v4 integration from `@apollo/server/express` without installing a second package. This does not support Express v5, and it was removed in Apollo Server 5. We recommend installing the separate package to make upgrading Apollo Server and Express easier.
 
 </Note>
 

@@ -5,7 +5,7 @@
 
 ## Using the plugin
 
-> 📣 **New in Apollo Server 4**: error details are not included in traces by default. For more details, see [Error Handling](../../data/errors/#masking-and-logging-errors).
+> 📣 **New since Apollo Server 4**: error details are not included in traces by default. For more details, see [Error Handling](../../data/errors/#masking-and-logging-errors).
 
 This article documents the options for the `ApolloServerPluginInlineTrace` plugin, which you can import from `@apollo/server/plugin/inlineTrace`.
 

@@ -55,7 +55,7 @@
 
 ## Default non-production landing page
 
-In non-production environments, Apollo Server 4's landing page is an embedded version of [Apollo Sandbox](/graphos/explorer/sandbox) (served at `http://localhost:4000` by default):
+In non-production environments, Apollo Server's landing page is an embedded version of [Apollo Sandbox](/graphos/explorer/sandbox) (served at `http://localhost:4000` by default):
 
 <img class="screenshot" src="../../images/sandbox.jpeg" alt="Apollo Sandbox" />
 
@@ -636,7 +636,7 @@
 
 ## GraphQL Playground landing page
 
-By default, Apollo Server 2 provided a GraphQL Playground landing page. For migration purposes, we've published the [`@apollo/server-plugin-landing-page-graphql-playground`](https://www.npmjs.com/package/@apollo/server-plugin-landing-page-graphql-playground) package, a GraphQL Playground plugin compatible with Apollo Server 4. However, we aren't supporting this plugin with documentation or security updates since the GraphQL Playground project is officially [retired](https://github.com/graphql/graphql-playground/issues/1143) and we do not recommend its continued use. Instead, we recommend migrating to the actively maintained [Apollo Sandbox](/graphos/explorer/sandbox) (the default landing page in Apollo Server 4) at your earliest convenience.
+By default, Apollo Server 2 provided a GraphQL Playground landing page. For migration purposes, we've published the [`@apollo/server-plugin-landing-page-graphql-playground`](https://www.npmjs.com/package/@apollo/server-plugin-landing-page-graphql-playground) package, a GraphQL Playground plugin compatible with Apollo Server. However, we aren't supporting this plugin with documentation or security updates since the GraphQL Playground project is officially [retired](https://github.com/graphql/graphql-playground/issues/1143) and we do not recommend its continued use. Instead, we recommend migrating to the actively maintained [Apollo Sandbox](/graphos/explorer/sandbox) (the default landing page in Apollo Server) at your earliest convenience.
 
 ## Disabling the landing page
 

@@ -6,8 +6,6 @@ minVersion: 4.9.0
 
 This document covers the usage of the subscription callback plugin for use in Apollo Federation with GraphOS Router. For more information about the protocol itself, see the [subscription callback protocol](/router/executing-operations/subscription-callback-protocol).
 
-> ⚠️ **Note**: The subscription callback protocol is currently in [preview](/resources/product-launch-stages#preview). Breaking changes might be introduced during the preview period.
-
 ## Using the plugin
 
 This article documents the options for the `ApolloServerPluginSubscriptionCallback` plugin, which you can import from `@apollo/server/plugin/subscriptionCallback`.

@@ -3,16 +3,19 @@
 api_reference: true
 ---
 
-> Sending metrics from Apollo Server to GraphOS requires an [Enterprise plan](https://www.apollographql.com/pricing).
-> If your organization doesn't have an Enterprise plan, you can test out this functionality by signing up for a free [GraphOS trial](https://studio.apollographql.com/signup?referrer=docs-content).
+<PlanRequired plans={["Free", "Developer", "Standard", "Enterprise"]}>
+
+While Insights are available on all GraphOS plans, metrics retention varies by [plan](https://www.apollographql.com/pricing?referrer=docs-content).
+
+</PlanRequired>
 
 Apollo Server's built-in usage reporting plugin gathers data on how your clients use the operations and fields in your GraphQL schema. The plugin also handles pushing this usage data to [GraphOS](/graphos/), as described in [Metrics and logging](../../monitoring/metrics/).
 
 This plugin is designed to be used in an Apollo Gateway or in a monolithic server; it is not designed to be used from a subgraph. In a supergraph running Apollo Federation, the Apollo Gateway or GraphOS Router will send usage reports to Apollo's cloud. Subgraphs don't need to also send usage reports to Apollo's cloud; instead, they send it to the Router via [inline traces](./inline-trace/) and the Router combines execution information across all subgraphs and sends summarized reports to the cloud.
 
 ## Default installation
 
-> 📣 **New in Apollo Server 4**: error details are not included in traces by default. For more details, see [Error Handling](../../data/errors/#masking-and-logging-errors).
+> 📣 **New since Apollo Server 4**: error details are not included in traces by default. For more details, see [Error Handling](../../data/errors/#masking-and-logging-errors).
 
 Apollo Server automatically installs and enables this plugin with default settings if you [provide a graph API key and a graph ref to Apollo Server](../../monitoring/metrics/#sending-metrics-to-graphos) and your server is not a federated subgraph. You usually do this by setting the `APOLLO_KEY` and `APOLLO_GRAPH_REF` (or `APOLLO_GRAPH_ID` and `APOLLO_GRAPH_VARIANT`) environment variables. No other action is required.