Release 2.5.0 #2482
Merged
Release 2.5.0 #2482
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implements a full query cache for Apollo Server in the new package `apollo-server-plugin-response-cache`. This has similar functionality to the caching feature of the deprecated Engine proxy.
Supporting this required:
- GraphQLRequestContext new fields:
- overallCachePolicy
- documentText
- metrics
- New plugin hook responseForOperation.
- new GraphQLExtension hook didResolveOperation, identical to the same hook in
the Plugin API. Change apollo-engine-reporting to use this hook instead of
executionDidStart, because executionDidStart doesn't run if the cache
short-circuits execution.
- apollo-engine-reporting: report whether the request was a cache hit. Also use
the new requestContext.metrics object to report persisted query hit/register
instead of specific extension options (though those extension options still
work).
- cacheControl constructor option semantic change: include the cacheControl
GraphQL extension in the output with `cacheControl: true` and `cacheControl:
{stripFormattedExtensions: false}` (as before), but not for `cacheControl:
{otherOptions: ...}`.
- apollo-cache-control@0.6.0-alpha.0 - apollo-datasource-rest@0.4.0-alpha.0 - apollo-datasource@0.4.0-alpha.0 - apollo-engine-reporting-protobuf@0.3.0-alpha.0 - apollo-engine-reporting@1.1.0-alpha.0 - apollo-server-azure-functions@2.5.0-alpha.0 - apollo-server-cache-memcached@0.4.0-alpha.0 - apollo-server-cache-redis@0.4.0-alpha.0 - apollo-server-caching@0.4.0-alpha.0 - apollo-server-cloud-functions@2.5.0-alpha.0 - apollo-server-cloudflare@2.5.0-alpha.0 - apollo-server-core@2.5.0-alpha.0 - apollo-server-env@2.3.0-alpha.0 - apollo-server-express@2.5.0-alpha.0 - apollo-server-fastify@2.5.0-alpha.0 - apollo-server-hapi@2.5.0-alpha.0 - apollo-server-integration-testsuite@2.5.0-alpha.0 - apollo-server-koa@2.5.0-alpha.0 - apollo-server-lambda@2.5.0-alpha.0 - apollo-server-micro@2.5.0-alpha.0 - apollo-server-plugin-base@0.4.0-alpha.0 - apollo-server-plugin-response-cache@0.1.0-alpha.0 - apollo-server-testing@2.5.0-alpha.0 - apollo-server@2.5.0-alpha.0 - apollo-tracing@0.6.0-alpha.0 - graphql-extensions@0.6.0-alpha.0
We don't want to have apollo-server-plugin-base directly depend on specific versions of other packages to keep things flexible, which is why apollo-server-env was just a devDependency, but this meant that TypeScript consumers of the published alpha packages could end up breaking because the import of apollo-server-env could be resolved to an older version of the package without the newly added types. I'm not sure if this reversion is the right long term answer vs making the apollo-server-env dependency non-dev, but this will let the alpha process for 2.5.0 move forward for now.
- apollo-engine-reporting@1.1.0-alpha.1 - apollo-server-azure-functions@2.5.0-alpha.1 - apollo-server-cloud-functions@2.5.0-alpha.1 - apollo-server-cloudflare@2.5.0-alpha.1 - apollo-server-core@2.5.0-alpha.1 - apollo-server-express@2.5.0-alpha.1 - apollo-server-fastify@2.5.0-alpha.1 - apollo-server-hapi@2.5.0-alpha.1 - apollo-server-integration-testsuite@2.5.0-alpha.1 - apollo-server-koa@2.5.0-alpha.1 - apollo-server-lambda@2.5.0-alpha.1 - apollo-server-micro@2.5.0-alpha.1 - apollo-server-plugin-base@0.4.0-alpha.1 - apollo-server-plugin-response-cache@0.1.0-alpha.1 - apollo-server-testing@2.5.0-alpha.1 - apollo-server@2.5.0-alpha.1 - graphql-extensions@0.6.0-alpha.1
|
I undid part of #2415 so that apollo-server-plugin-base doesn't rely (for TypeScript users) on apollo-server-env without having it as a non-dev dependency. |
This pr solves a minor issue. When the apollo server express app is part (or it is used) inside other express apps the endpoint used to mount the playground is in correct. 
GraphQL errors should bethrow new AuthenticationError and throw new ForbiddenError <!-- Thanks for filing a pull request on GraphQL Server! Please look at the following checklist to ensure that your PR can be accepted quickly: --> TODO: * [ ] Update CHANGELOG.md with your change (include reference to issue & this PR) * [ ] Make sure all of the significant new logic is covered by tests * [ ] Rebase your changes on master so that they can be merged easily * [ ] Make sure all tests and linter rules pass
- apollo-cache-control@0.6.0-alpha.1 - apollo-datasource-rest@0.4.0-alpha.1 - apollo-datasource@0.4.0-alpha.1 - apollo-engine-reporting@1.1.0-alpha.2 - apollo-server-azure-functions@2.5.0-alpha.2 - apollo-server-cache-memcached@0.4.0-alpha.1 - apollo-server-cache-redis@0.4.0-alpha.1 - apollo-server-caching@0.4.0-alpha.1 - apollo-server-cloud-functions@2.5.0-alpha.2 - apollo-server-cloudflare@2.5.0-alpha.2 - apollo-server-core@2.5.0-alpha.2 - apollo-server-express@2.5.0-alpha.2 - apollo-server-fastify@2.5.0-alpha.2 - apollo-server-hapi@2.5.0-alpha.2 - apollo-server-integration-testsuite@2.5.0-alpha.2 - apollo-server-koa@2.5.0-alpha.2 - apollo-server-lambda@2.5.0-alpha.2 - apollo-server-micro@2.5.0-alpha.2 - apollo-server-plugin-base@0.4.0-alpha.2 - apollo-server-plugin-response-cache@0.1.0-alpha.2 - apollo-server-testing@2.5.0-alpha.2 - apollo-server@2.5.0-alpha.2 - apollo-tracing@0.6.0-alpha.1 - graphql-extensions@0.6.0-alpha.2
* add no-cache headers to PersistedQuery error responses * fix defaultHeaders typo * remove try/catch on hasPersistedQueryError replace with Array.isArray check * Add CHANGELOG.md for #2446.
- apollo-cache-control@0.6.0-alpha.2 - apollo-datasource-rest@0.4.0-alpha.2 - apollo-engine-reporting@1.1.0-alpha.3 - apollo-server-azure-functions@2.5.0-alpha.3 - apollo-server-cloud-functions@2.5.0-alpha.3 - apollo-server-cloudflare@2.5.0-alpha.3 - apollo-server-core@2.5.0-alpha.3 - apollo-server-errors@2.2.2-alpha.0 - apollo-server-express@2.5.0-alpha.3 - apollo-server-fastify@2.5.0-alpha.3 - apollo-server-hapi@2.5.0-alpha.3 - apollo-server-integration-testsuite@2.5.0-alpha.3 - apollo-server-koa@2.5.0-alpha.3 - apollo-server-lambda@2.5.0-alpha.3 - apollo-server-micro@2.5.0-alpha.3 - apollo-server-plugin-base@0.4.0-alpha.3 - apollo-server-plugin-response-cache@0.1.0-alpha.3 - apollo-server-testing@2.5.0-alpha.3 - apollo-server@2.5.0-alpha.3 - apollo-tracing@0.6.0-alpha.2 - graphql-extensions@0.6.0-alpha.3
<!-- Thanks for filing a pull request on GraphQL Server! Please look at the following checklist to ensure that your PR can be accepted quickly: --> TODO: * [x] Update CHANGELOG.md with your change (include reference to issue & this PR) * [x] Make sure all of the significant new logic is covered by tests * [x] Rebase your changes on master so that they can be merged easily * [ ] Make sure all tests and linter rules pass
- apollo-engine-reporting@1.1.0-alpha.4 - apollo-server-azure-functions@2.5.0-alpha.4 - apollo-server-cloud-functions@2.5.0-alpha.4 - apollo-server-cloudflare@2.5.0-alpha.4 - apollo-server-core@2.5.0-alpha.4 - apollo-server-express@2.5.0-alpha.4 - apollo-server-fastify@2.5.0-alpha.4 - apollo-server-hapi@2.5.0-alpha.4 - apollo-server-integration-testsuite@2.5.0-alpha.4 - apollo-server-koa@2.5.0-alpha.4 - apollo-server-lambda@2.5.0-alpha.4 - apollo-server-micro@2.5.0-alpha.4 - apollo-server-plugin-base@0.4.0-alpha.4 - apollo-server-testing@2.5.0-alpha.4 - apollo-server@2.5.0-alpha.4 - graphql-extensions@0.6.0-alpha.4
* fix: Set `operationName` via `executionDidStart` and `willResolveField`. The full-query caching feature implemented in #2437 originally took the additional steps of also changing the `apollo-engine-reporting` module to utilize the new request pipeline available in Apollo Server as of #1795. While that would have been nice, there was still some uncertainty about some of the life-cycle hooks that would be necesssary to make that happen and it wasn't worth blocking the implementation of full-query caching on those stalled decisions. Therefore, the changes to utilize new functionality in the request pipeline, including what would have been a simplification of the way that `apollo-engine-reporting` would have obtained the `operationName` (something that is available via the API of the request-pipeline hooks), were backed out and will land separately in a future PR. The portion regarding `operationName` was inadvertently not backed out and instead was left leveraging a life-cycle hook which was not available to the `graphql-extensions` API: `didResolveOperation`. This means that the code was not setting `operationName` in the way it needed to and therefore `operationName` was always being left undefined (as is sometimes permitted!) with this new `apollo-engine-reporting`. This commit puts the functionality back to that which is required for the `graphql-extensions` implementation, and the commit before this (8a43341) acts as a regression test (it should pass, as of this commit, and fail before it). * Add a regression test for `operationName` not being defined. This should fail and then be fixed with an upcoming commit.
- apollo-engine-reporting@1.1.0-alpha.5 - apollo-server-azure-functions@2.5.0-alpha.5 - apollo-server-cloud-functions@2.5.0-alpha.5 - apollo-server-cloudflare@2.5.0-alpha.5 - apollo-server-core@2.5.0-alpha.5 - apollo-server-express@2.5.0-alpha.5 - apollo-server-fastify@2.5.0-alpha.5 - apollo-server-hapi@2.5.0-alpha.5 - apollo-server-integration-testsuite@2.5.0-alpha.5 - apollo-server-koa@2.5.0-alpha.5 - apollo-server-lambda@2.5.0-alpha.5 - apollo-server-micro@2.5.0-alpha.5 - apollo-server-plugin-base@0.4.0-alpha.5 - apollo-server-plugin-response-cache@0.1.0-alpha.5 - apollo-server-testing@2.5.0-alpha.5 - apollo-server@2.5.0-alpha.5 - apollo-tracing@0.6.0-alpha.5 - graphql-extensions@0.6.0-alpha.5
* Add pluggable executor to request pipeline * Export request pipeline API types from `apollo-server-core` * Change `errors` in `GraphQLResponse` to formatted errors This adjusts the request pipeline to format errors before calling `willSendResponse`, and adds a `didEncounterErrors` hook to give the Engine reporting extension access to the raw errors. * Introduce `GraphQLExecutionResult` type * fix merge conflicts
- apollo-cache-control@0.6.0-alpha.3 - apollo-datasource-rest@0.4.0-alpha.3 - apollo-engine-reporting@1.1.0-alpha.6 - apollo-server-azure-functions@2.5.0-alpha.6 - apollo-server-cloud-functions@2.5.0-alpha.6 - apollo-server-cloudflare@2.5.0-alpha.6 - apollo-server-core@2.5.0-alpha.6 - apollo-server-errors@2.2.2-alpha.1 - apollo-server-express@2.5.0-alpha.6 - apollo-server-fastify@2.5.0-alpha.6 - apollo-server-hapi@2.5.0-alpha.6 - apollo-server-integration-testsuite@2.5.0-alpha.6 - apollo-server-koa@2.5.0-alpha.6 - apollo-server-lambda@2.5.0-alpha.6 - apollo-server-micro@2.5.0-alpha.6 - apollo-server-plugin-base@0.4.0-alpha.6 - apollo-server-plugin-response-cache@0.1.0-alpha.6 - apollo-server-testing@2.5.0-alpha.6 - apollo-server@2.5.0-alpha.6 - apollo-tracing@0.6.0-alpha.6 - graphql-extensions@0.6.0-alpha.6
4 tasks
This shouldn't be here!
- apollo-cache-control@0.6.0-alpha.7 - apollo-engine-reporting@1.1.0-alpha.7 - apollo-server-azure-functions@2.5.0-alpha.7 - apollo-server-cloud-functions@2.5.0-alpha.7 - apollo-server-cloudflare@2.5.0-alpha.7 - apollo-server-core@2.5.0-alpha.7 - apollo-server-express@2.5.0-alpha.7 - apollo-server-fastify@2.5.0-alpha.7 - apollo-server-hapi@2.5.0-alpha.7 - apollo-server-integration-testsuite@2.5.0-alpha.7 - apollo-server-koa@2.5.0-alpha.7 - apollo-server-lambda@2.5.0-alpha.7 - apollo-server-micro@2.5.0-alpha.7 - apollo-server-plugin-base@0.4.0-alpha.7 - apollo-server-plugin-response-cache@0.1.0-alpha.7 - apollo-server-testing@2.5.0-alpha.7 - apollo-server@2.5.0-alpha.7 - apollo-tracing@0.6.0-alpha.7 - graphql-extensions@0.6.0-alpha.7
…s for reporting. (#2618) * Add errorFilter option * update changelog * Rename errorFilter to filterErrors, return GraphQLError or null * Add back `maskErrorDetails` type to maintain support. ...though it's currently not functional as of this commit. * Introduce additional tests for `filterErrors` and `maskErrorDetails`. Even though `maskErrorDetails` is going away, it seems important to continue to test it along with the new functionality introduced by `filterErrors`. Note: These tests highlight some failures in the current `filterErrors` logic which need to be addressed in follow-up commits. * Finish up new `filterErrors` functionality, sans renaming to a new name. The intention is to rename the `filterErrors` function to `rewriteError` in a follow-up commit, but this maintains the previous name during the re-implementation phase. * Add a test that ensures that the `stack` is not transmitted. The new implementation of `rewriteError` (previously `formatErrors` and prior to that `maskErrorDetails`, do nothing to ensure that the `stack` property (i.e. `Error.prototype.stack`) is regenerated using the new combination of `${err.name}: ${err.message`, suffixed with the rest of `Error.captureStackTrace`. That's okay, but we should at least guard against that and make sure that no future code starts to add the `stack` property, without properly redacting it within `rewriteError` internals. That redaction is _slightly_ less than performant (string manipulation), so it didn't seem worth the effort, since we don't actually send it anywhere. * Rename new `filterErrors` function to a more accurate `rewriteError`. While the new `filterErrors` functionality did allow complete filtering of errors prior to reporting them to Apollo Engine, it also provides the ability to change the error entirely. This more thorough functionality deserves a name which more accurately defines its functionality. The use-defined `rewriteError` function (defined within the `engine` configuration on the `ApolloServer` constructor options) can still be used to "filter" an error from going to Engine by re-writing the error to `null` To accomplish this nullification of an error, an explicit `null` can be returned from the `rewriteError` function rather than the normal practice of returning a `GraphQLError` (in a presumably modified form). * Adjust the line lengths of some comments. Because prettier doesn't do it! * Add CHANGELOG.md for `rewriteError`. * Update deprecated to use rewriteError * Update rewriteError in docs - Deprecate `formatError` in docs in favor of `rewriteError` - lint-fix * Remove now-unnecessary guard which checks for `errors`. This is no longer necessary after the changes in @jbaxleyiii's #2574 (and @martijnwalraven's #2416), which changed the error reporting to be captured via the newly introduced `didEncounterErrors`, rather than in `willResolveField` where it used to happen. Yay! * Remove long-skipped test that was never close to working. I don't think this is providing much value at this point and it's been skipped for over a year. It appears that the test was intended to test `reportErrorFunction`, though the description claims that it's trying to test something else entirely. Regardless, the testing of traces is actually handled elsewhere now, so this is good to remove. * Fix test structure after merge. * Partially Revert "Update rewriteError in docs" This partially reverts commit 21b8b86, which inadvertently changed `formatError`, which is a top-level function which can be used to adjust the response to the client, which is intrinsically different than the new `rewriteError` which modifies the shape of the error in the tracing data which is sent to the Apollo Platform. * Update the API section with more clarity. * Update docs for rewriteError. (#2585) * (docs) Add information on `rewriteError` to the `errors.md`. This adds additional clarity fro the new functionality provided in #1639. * Fix syntax error and use `String.prototype.startsWith` rather `St.pr.match`. Regular expressions are just not as approachable! * Update errors example. The previous example here wasn't a wonderful example since it was suggesting a pattern which is unnecessary when `NODE_ENV=production`, where stack traces are automatically hidden. * Update errors.md * Update errors.md * Update CHANGELOG.md Co-authored-by: GerA <lpgera@gmail.com>
#2437. While #2437 did introduce the documentation and the appropriate configuration for it, it did so while we were still utilizing Hexo for our docs, and the configuration changes necessary for our docs' Gatsby-ification didn't happen. This puts the configuration in place for Gatsby and merges into the 2.5.0 release branch. Ref: https://github.com/apollographql/apollo-server/pull/2437/files#diff-b09bbff3e688a10b35f7de810d65c28e
- apollo-datasource-rest@0.4.0-rc.0 - apollo-engine-reporting@1.1.0-rc.0 - apollo-server-azure-functions@2.5.0-rc.0 - apollo-server-cloud-functions@2.5.0-rc.0 - apollo-server-cloudflare@2.5.0-rc.0 - apollo-server-core@2.5.0-rc.0 - apollo-server-express@2.5.0-rc.0 - apollo-server-fastify@2.5.0-rc.0 - apollo-server-hapi@2.5.0-rc.0 - apollo-server-integration-testsuite@2.5.0-rc.0 - apollo-server-koa@2.5.0-rc.0 - apollo-server-lambda@2.5.0-rc.0 - apollo-server-micro@2.5.0-rc.0 - apollo-server-plugin-base@0.4.0-rc.0 - apollo-server-testing@2.5.0-rc.0 - apollo-server@2.5.0-rc.0 - graphql-extensions@0.6.0-rc.0
|
I believe the Apollo Server 2.5.0 release is nearly ready! 🙌 In terms of new features, of particular note are:
I've just published a release-candidate on the Feedback and testing very much appreciated! |
4 tasks
Breaks down the bug-fixes from the new features and adjusts the formatting.
- apollo-cache-control@0.6.0 - apollo-datasource-rest@0.4.0 - apollo-datasource@0.4.0 - apollo-engine-reporting-protobuf@0.3.0 - apollo-engine-reporting@1.1.0 - apollo-server-azure-functions@2.5.0 - apollo-server-cache-memcached@0.4.0 - apollo-server-cache-redis@0.4.0 - apollo-server-caching@0.4.0 - apollo-server-cloud-functions@2.5.0 - apollo-server-cloudflare@2.5.0 - apollo-server-core@2.5.0 - apollo-server-env@2.3.0 - apollo-server-errors@2.3.0 - apollo-server-express@2.5.0 - apollo-server-fastify@2.5.0 - apollo-server-hapi@2.5.0 - apollo-server-integration-testsuite@2.5.0 - apollo-server-koa@2.5.0 - apollo-server-lambda@2.5.0 - apollo-server-micro@2.5.0 - apollo-server-plugin-base@0.4.0 - apollo-server-plugin-response-cache@0.1.0 - apollo-server-testing@2.5.0 - apollo-server@2.5.0 - apollo-tracing@0.6.0 - graphql-extensions@0.6.0
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Much in the same way as the 2.4.0 PR (#2215) was for the 2.5.0 release, this is a PR tracking a
release-x.y.zbranch for an upcoming semver minor release of Apollo Server: v2.5.0 (i.e.release-2.5.0).The intention here is to keep the
masterbranch a bit more flexible while landing things which have been decidedly put into a release on this more specific release branch. PRs for 2.5.0 features can be targeted toward thisrelease-2.5.0branch (and thus appear in this PR's history), in addition to being merged into themasterbranch and providing the ability to backport fixes on the 2.4.x line from there.The first PR intended to land here is #2437
Check the appropriate milestone for more details on what's slated for 2.5.0.
Follow-up work
ValueOrPromise/WithRequiredtypes fromapollo-server-env. #2417 and Extract TypeScript utility types toapollo-server-env#2415, as noted by @glasser in Extract TypeScript utility types toapollo-server-env#2415 (comment)