From 379bef245c5c50771b1f0013d2f67568f26e691f Mon Sep 17 00:00:00 2001 From: David Glasser Date: Thu, 25 Mar 2021 15:28:53 -0700 Subject: [PATCH] Add docs and changelog --- CHANGELOG.md | 1 + packages/apollo-server-core/src/ApolloServer.ts | 14 ++++++++++++++ 2 files changed, 15 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index b9d4d30f067..9fe3e11a24c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -12,6 +12,7 @@ The version headers in this history reflect the versions of Apollo Server itself > 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. With few exceptions, the format of the entry should follow convention (i.e., prefix with package name, use markdown `backtick formatting` for package names and code, suffix with a link to the change-set à la `[PR #YYY](https://link/pull/YYY)`, etc.). 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. - Improve startup error handling by ensuring that your server has loaded its schema and executed its `serverWillStart` handlers successfully before starting an HTTP server. If you're using the `apollo-server` package, no code changes are necessary. If you're using an integration such as `apollo-server-express` that is not a "serverless framework", you can insert [`await server.start()`](https://www.apollographql.com/docs/apollo-server/api/apollo-server/#start) between `server = new ApolloServer()` and `server.applyMiddleware`. (If you don't call `server.start()` yourself, your server will still work, but the previous behavior of starting a web server that may fail to load its schema still applies.) The serverless framework integrations (Lambda, Azure Functions, and Cloud Functions) do not support this functionality. While the protected method `willStart` still exists for backwards compatibility, you should replace calls to it with `start` or the new protected method `ensureStarting`. [PR #4981](https://github.com/apollographql/apollo-server/pull/4981) +- `apollo-server-core`: Add optional argument to `ApolloServer.executeOperation` allowing the caller to manually specify an argument to the `config` function analogous to that provided by integration packages. [PR #4166](https://github.com/apollographql/apollo-server/pull/4166) [Issue #2886](https://github.com/apollographql/apollo-server/issues/2886) ## v2.21.2 diff --git a/packages/apollo-server-core/src/ApolloServer.ts b/packages/apollo-server-core/src/ApolloServer.ts index a5c5887b923..e96f277c169 100644 --- a/packages/apollo-server-core/src/ApolloServer.ts +++ b/packages/apollo-server-core/src/ApolloServer.ts @@ -1256,6 +1256,20 @@ export class ApolloServerBase { }; } + /** + * This method is primarily meant for testing: it allows you to execute a + * GraphQL operation via the request pipeline without going through without + * going through the HTTP layer. Note that this means that any handling you do + * in your server at the HTTP level will not affect this call! + * + * If you pass a second argument to this method and your ApolloServer's + * `context` is a function, that argument will be passed directly to your + * `context` function. It is your responsibility to make it as close as needed + * by your `context` function to the integration-specific argument that your + * integration passes to `context` (eg, for `apollo-server-express`, the + * `{req: express.Request, res: express.Response }` object) and to keep it + * updated as you upgrade Apollo Server. + */ public async executeOperation(request: GraphQLRequest, integrationContextArgument?: Record) { const options = await this.graphQLServerOptions(integrationContextArgument);