fix: updated documentstore to use schema hash #7433
Conversation
👷 Deploy request for apollo-server-docs pending review.Visit the deploys page to approve it
|
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit df47598:
|
|
@KGAdamCook in principle I think this change is reasonable. I'd be remiss not to steer you away from what you're interested in doing though. The |
|
Thanks for your reply @trevor-scheer , so there is no actual benefit to having the |
|
Maybe a benefit for a new instance with a query it hasn't seen before (it would be JSON parsing the AST from your distributed redis cache instead of parsing/validating). After that query is seen/cached in memory though, the distributed cache is a performance hit every time since it has to deserialize on every request. Does that make sense? |
|
Yeah that does make sense. In our particular use case we are hosting Apollo Server on AWS Lambda, so we see a large amount of new servers each day. It almost seems like to me it would benefit greatly from having the cache default to memory if it exists, otherwise also check if it exists in Redis. Then only pulling from memory on subsequent queries. |
Co-authored-by: Trevor Scheer <[email protected]>
|
@KGAdamCook sorry there's usually a comment from our bot to request the CLA. Can you please sign it? Otherwise ready to go 👍 |
|
@KGAdamCook bump! I'd like to get this into the next release if possible. |
|
Apologies @trevor-scheer , I have signed the CLA and resolved the comments you raised. |
|
Our CLA bot was having a fun time around when this PR was opened or pushed to last. Just noting that the status still says "waiting" but I've confirmed in the database that you've signed it. Thanks! |
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @apollo/[email protected] ### Minor Changes - [#7465](#7465) [`1e808146a`](1e80814) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Introduce new opt-in configuration option to mitigate v4 status code regression Apollo Server v4 accidentally started responding to requests with an invalid `variables` object with a 200 status code, where v3 previously responded with a 400. In order to not break current behavior (potentially breaking users who have creatively worked around this issue) and offer a mitigation, we've added the following configuration option which we recommend for all users. ```ts new ApolloServer({ // ... status400ForVariableCoercionErrors: true, }); ``` Specifically, this regression affects cases where _input variable coercion_ fails. Variables of an incorrect type (i.e. `String` instead of `Int`) or unexpectedly `null` are examples that fail variable coercion. Additionally, missing or incorrect fields on input objects as well as custom scalars that throw during validation will also fail variable coercion. For more specifics on variable coercion, see the "Input Coercion" sections in the [GraphQL spec](https://spec.graphql.org/June2018/#sec-Scalars). This will become the default behavior in Apollo Server v5 and the configuration option will be ignored / no longer needed. ### Patch Changes - [#7454](#7454) [`f6e3ae021`](f6e3ae0) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Start building packages with TS 5.x, which should have no effect for users - [#7433](#7433) [`e0db95b96`](e0db95b) Thanks [@KGAdamCook](https://github.com/KGAdamCook)! - Previously, when users provided their own `documentStore`, Apollo Server used a random prefix per schema in order to guarantee there was no shared state from one schema to the next. Now Apollo Server uses a hash of the schema, which enables the provided document store to be shared if you choose to do so. ## @apollo/[email protected] ### Patch Changes - [#7454](#7454) [`f6e3ae021`](f6e3ae0) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Start building packages with TS 5.x, which should have no effect for users - Updated dependencies \[[`1e808146a`](1e80814), [`f6e3ae021`](f6e3ae0), [`e0db95b96`](e0db95b)]: - @apollo/[email protected] ## @apollo/[email protected] ### Patch Changes - [#7454](#7454) [`f6e3ae021`](f6e3ae0) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Start building packages with TS 5.x, which should have no effect for users Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Previously, when users provided their own `documentStore`, Apollo Server used a random prefix per schema in order to guarantee there was no shared state from one schema to the next. Now Apollo Server uses a hash of the schema, which enables the provided document store to be shared if you choose to do so.
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @apollo/[email protected] ### Minor Changes - [#7465](#7465) [`1e808146a`](1e80814) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Introduce new opt-in configuration option to mitigate v4 status code regression Apollo Server v4 accidentally started responding to requests with an invalid `variables` object with a 200 status code, where v3 previously responded with a 400. In order to not break current behavior (potentially breaking users who have creatively worked around this issue) and offer a mitigation, we've added the following configuration option which we recommend for all users. ```ts new ApolloServer({ // ... status400ForVariableCoercionErrors: true, }); ``` Specifically, this regression affects cases where _input variable coercion_ fails. Variables of an incorrect type (i.e. `String` instead of `Int`) or unexpectedly `null` are examples that fail variable coercion. Additionally, missing or incorrect fields on input objects as well as custom scalars that throw during validation will also fail variable coercion. For more specifics on variable coercion, see the "Input Coercion" sections in the [GraphQL spec](https://spec.graphql.org/June2018/#sec-Scalars). This will become the default behavior in Apollo Server v5 and the configuration option will be ignored / no longer needed. ### Patch Changes - [#7454](#7454) [`f6e3ae021`](f6e3ae0) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Start building packages with TS 5.x, which should have no effect for users - [#7433](#7433) [`e0db95b96`](e0db95b) Thanks [@KGAdamCook](https://github.com/KGAdamCook)! - Previously, when users provided their own `documentStore`, Apollo Server used a random prefix per schema in order to guarantee there was no shared state from one schema to the next. Now Apollo Server uses a hash of the schema, which enables the provided document store to be shared if you choose to do so. ## @apollo/[email protected] ### Patch Changes - [#7454](#7454) [`f6e3ae021`](f6e3ae0) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Start building packages with TS 5.x, which should have no effect for users - Updated dependencies \[[`1e808146a`](1e80814), [`f6e3ae021`](f6e3ae0), [`e0db95b96`](e0db95b)]: - @apollo/[email protected] ## @apollo/[email protected] ### Patch Changes - [#7454](#7454) [`f6e3ae021`](f6e3ae0) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Start building packages with TS 5.x, which should have no effect for users Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
If you have multiple servers running with the same schema, you may wish to share the documentStore cache among them using something such as Redis, rather than inMemory.
Using the schema hash this should allow for sharing of the data whilst still creating a new prefix for whenever the schema changes.
Fixes #7471