You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make server.start() required for non-serverless frameworks (#5195)
AS v2.22 introduced the method `server.start()` which could be awaited
immediately after `new ApolloServer()` in order to catch startup errors
(for example, errors loading schema from gateway).
This method exists only for non-serverless framework integrations. For
`apollo-server` its semantics are integrated into `server.listen()` and
for serverless frameworks you typically must set up the handler
synchronously.
In AS2 this method was optional. This PR makes the method required. So
instead of the framework integration kicking off a `start` in the
background if you don't do it yourself, it just throws an error telling
you to call start.
Fixes#5050.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -28,6 +28,7 @@ The version headers in this history reflect the versions of Apollo Server itself
28
28
-`apollo-server-lambda`: The handler returned by `createHandler` can now only be called as an async function returning a `Promise` (it no longer optionally accepts a callback as the third argument). All current Lambda Node runtimes support this invocation mode (so `exports.handler = server.createHandler()` will keep working without any changes), but if you've written your own handler which calls the handler returned by `createHandler` with a callback, you'll need to handle its `Promise` return value instead.
29
29
- The `tracing` option to `new ApolloServer` has been removed, and the `apollo-server-tracing` package has been deprecated and is no longer being published. This package implemented an inefficient JSON format for execution traces returned on the `tracing` GraphQL response extension; it was only consumed by the deprecated `engineproxy` and Playground. If you really need this format, the old version of `apollo-server-tracing` should still work (`new ApolloServer({plugins: [require('apollo-server-tracing').plugin()]})`).
30
30
- The `cacheControl` option to `new ApolloServer` has been removed. The functionality provided by `cacheControl: true` or `cacheControl: {stripFormattedExtensions: false}` (which included a `cacheControl` extension in the GraphQL response, for use by the deprecated `engineproxy`) has been entirely removed. The default behavior of Apollo Server continues to be calculating an overall cache policy and setting the `Cache-Control` HTTP header, but this is now implemented directly inside `apollo-server-core` rather than a separate `apollo-cache-control` package (this package has been deprecated and is no longer being published). Tweaking cache control settings like `defaultMaxAge` is now done via the newly exported `ApolloServerPluginCacheControl` plugin rather than as a top-level constructor option. This follows the same pattern as the other built-in plugins like usage reporting. The `CacheHint` and `CacheScope` types are now exported from `apollo-server-types`.
31
+
- When using a non-serverless framework integration (Express, Fastify, Hapi, Koa, Micro, or Cloudflare), you now *must*`await server.start()` before attaching the server to your framework. (This method was introduced in v2.22 but was optional before Apollo Server 3.) This does not apply to the batteries-included `apollo-server` or to serverless framework integrations.
31
32
- Top-level exports have changed. E.g.,
32
33
33
34
- We no longer re-export the entirety of `graphql-tools` (including `makeExecutableSchema`) from all Apollo Server packages. If you'd like to continue using them, install [`graphql-tools`](https://www.graphql-tools.com/) or one of its sub-packages yourself.
Copy file name to clipboardExpand all lines: docs/source/api/apollo-server.md
+2-6Lines changed: 2 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -659,19 +659,15 @@ The async `start` method instructs Apollo Server to prepare to handle incoming o
659
659
660
660
Always call `await server.start()`*before* calling `server.applyMiddleware` and starting your HTTP server. This allows you to react to Apollo Server startup failures by crashing your process instead of starting to serve traffic.
661
661
662
+
This method was optional in Apollo Server 2 but is required in Apollo Server 3.
663
+
662
664
##### Triggered actions
663
665
664
666
The `start` method triggers the following actions:
665
667
666
668
1. If your server is a [federated gateway](https://www.apollographql.com/docs/federation/managed-federation/overview/), it attempts to fetch its schema. If the fetch fails, `start` throws an error.
667
669
2. Your server calls all of the [`serverWillStart` handlers](../integrations/plugins/#serverwillstart) of your installed plugins. If any of these handlers throw an error, `start` throws an error.
668
670
669
-
##### Backward compatibility
670
-
671
-
To ensure backward compatibility, calling `await server.start()` is optional. If you don't call it yourself, your integration package invokes it when you call `server.applyMiddleware`. Incoming GraphQL operations wait to execute until Apollo Server has started, and those operations fail if startup fails (a redacted error message is sent to the GraphQL client).
672
-
673
-
We recommend calling `await server.start()` yourself, so that your web server doesn't start accepting GraphQL requests until Apollo Server is ready to process them.
674
-
675
671
#### `applyMiddleware`
676
672
677
673
Connects Apollo Server to the HTTP framework of a Node.js middleware library, such as hapi or express.
0 commit comments