Since we already write to the persisted query cache asynchronously (and
intentionally do not await the Promise) this won't have any affect on the
current behavior of when the persisted query cache is written to in the
event of an executable request, but if an operation comes in and doesn't
parse or validate, we'll avoid wasting cache space on an operation that will
never execute.
Additionally, in a similar light, if a plugin throws an error which stops
execution, we can avoid the side-effect of writing to the persisted query
cache.
In terms of the APQ behavior, while this could cause additional round-trips
for a client which repeatedly sends an invalid operation, that operation is
never going to successfully finish anyway. While developer tooling will
help avoid this problem in the first place, this refusal to store an invalid
operation in the APQ cache could actually help diagnose a failure since the
full operation (rather than just the SHA256 of that document) will appear
in the browser's dev-tools on the retry.
If we're looking to spare parsing and validating documents which we know are
going to fail, I think that's going to be a better use of the (new)
`documentStore` cache (#2111), since its in-memory and can accommodate a
more complex data structure which includes the validation errors from the
previous attempt which will, of course, be the same when validating the same
operation against the same schema again. As the PR that introduced that
feature shows, sparing those additional parses and validations (cached APQ
documents still needs to be parsed and validated, currently) will provide a
more successful performance win overall.
Ref: https://github.com/apollographql/apollo-server/pull/2111
This PR contains the following updates:
| Package | Type | Update | Change | References |
|---|---|---|---|---|
| prettier | devDependencies | minor | `1.15.3` -> `1.16.1` | [homepage](https://prettier.io), [source](https://togithub.com/prettier/prettier) |
---
### Release Notes
<details>
<summary>prettier/prettier</summary>
### [`v1.16.1`](https://togithub.com/prettier/prettier/blob/master/CHANGELOG.md#​1161)
[Compare Source](https://togithub.com/prettier/prettier/compare/1.16.0...1.16.1)
[diff](https://togithub.com/prettier/prettier/compare/1.16.0...1.16.1)
- JavaScript: Do not format functions with arguments as react hooks ([#​5778] by [@​SimenB])
The formatting added in Prettier 1.16 would format any function receiving an
arrow function and an array literal to match React Hook's documentation.
Prettier will now format this the same as before that change if the arrow
function receives any arguments.
<!-- prettier-ignore -->
```js
// Input
["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce(
(allColors, color) => {
return allColors.concat(color);
},
[]
);
// Output (Prettier 1.16.0)
["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce((
allColors,
color
) => {
return allColors.concat(color);
}, []);
// Output (Prettier 1.16.1)
["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce(
(allColors, color) => {
return allColors.concat(color);
},
[]
);
```
- JavaScript: Add necessary parentheses for decorators ([#​5785] by [@​ikatyang])
Parentheses for decorators with nested call expressions are optional for legacy decorators
but they're required for decorators in the current [proposal](https://tc39.github.io/proposal-decorators/#sec-syntax).
<!-- prettier-ignore -->
```js
// Input
class X {
@​(computed().volatile())
prop
}
// Output (Prettier 1.16.0)
class X {
@​computed().volatile()
prop
}
// Output (Prettier 1.16.1)
class X {
@​(computed().volatile())
prop
}
```
- TypeScript: Stable parentheses for function type in the return type of arrow function ([#​5790] by [@​ikatyang])
There's a regression introduced in 1.16 that
parentheses for function type in the return type of arrow function were kept adding/removing.
Their parentheses are always printed now.
<!-- prettier-ignore -->
```ts
// Input
const foo = (): (() => void) => (): void => null;
const bar = (): () => void => (): void => null;
// First Output (Prettier 1.16.0)
const foo = (): () => void => (): void => null;
const bar = (): (() => void) => (): void => null;
// Second Output (Prettier 1.16.0)
const foo = (): (() => void) => (): void => null;
const bar = (): () => void => (): void => null;
// Output (Prettier 1.16.1)
const foo = (): (() => void) => (): void => null;
const bar = (): (() => void) => (): void => null;
```
- MDX: Correctly recognize inline JSX ([#​5783] by [@​ikatyang])
Previously, some inline JSXs are wrongly recognized as block HTML/JSX,
which causes unexpected behaviors. This issue is now fixed.
<!-- prettier-ignore -->
```md
<!-- Input -->
_foo <InlineJSX /> bar_
<!-- Output (Prettier 1.16.0) -->
_foo
<InlineJSX /> bar_
<!-- Output (Prettier 1.16.1) -->
_foo <InlineJSX /> bar_
```
[@​ikatyang]: https://togithub.com/ikatyang
[@​simenb]: https://togithub.com/SimenB
[#​5778]: https://togithub.com/prettier/prettier/pull/5778
[#​5783]: https://togithub.com/prettier/prettier/pull/5783
[#​5785]: https://togithub.com/prettier/prettier/pull/5785
[#​5790]: https://togithub.com/prettier/prettier/pull/5790
### [`v1.16.0`](https://togithub.com/prettier/prettier/blob/master/CHANGELOG.md#​1160)
[Compare Source](https://togithub.com/prettier/prettier/compare/1.15.3...1.16.0)
[diff](https://togithub.com/prettier/prettier/compare/1.15.3...1.16.0)
🔗 [Release Notes](https://prettier.io/blog/2019/01/20/1.16.0.html)
</details>
---
### Renovate configuration
📅 **Schedule**: "after 6pm every weekday,before 5am every weekday" in timezone America/Los_Angeles.
🚦 **Automerge**: Enabled.
♻️ **Rebasing**: Whenever PR is stale, or if you modify the PR title to begin with "`rebase!`".
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- renovate-rebase -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://togithub.com/marketplace/renovate). View repository job log [here](https://renovatebot.com/dashboard#apollographql/apollo-server).
* refactor: switch `json-stable-stringify` to `fast-json-stable-stringify`
* chore: drop `@types/json-stable-stringify`
* Update CHANGELOG.md for #2065.
Rather than crutching on the `return`, this logic reads more concisely with
a full `if` / `else` pattern.
I say this because two people looked at it and weren't immediately aware,
which really shouldn't be the case from such a brief piece of code.
This test harness is intended to be relatively temporary, but it seems
fruitful to start picking from where these types are already defined rather
than re-implementing them in multiple places.
This change came up in a larger feature implementation and should otherwise be
a no-op but was worth surfacing as its own commit in case that feature never
lands.
Now that there are specific versions of Node.js which don't support file
uploads (namely, <= 8.5.0) we need to explicitly disable uploads on those
versions, similar to how those users must opt-in to that behavior by setting
`uploads: false` in their Apollo Server constructor options.
This effectively accomplishes exactly that, but only when necessary.
Due to changes in the third-party `graphql-upload` package which Apollo
Server utilizes to implement out-of-the-box file upload functionality, we
must drop support for file uploads in versions of the Node.js engine prior
to v8.5.0. Since file uploads are supported by default in Apollo Server 2.x,
and there is an explicit dependency on `graphql-upload`, we must
prevent users who are affected by this mid-major-release deprecation by
being surprised by the sudden lack of upload support.
By `throw`-ing an error at server startup for affected users, we certainly
are breaking a semantic versioning agreement for these users, however with a
relatively simple ergonomic (setting `uploads: false`) we allow those users
who are NOT utilizing file uploads (as we believe is the case with a
majority) to continue using their version of Node.js until it reaches the
end of its supported lifetime (as dictated by its Long Term Support
agreement with the Node.js Foundation). If we did not `throw` the error at
server start-up, those affected may not notice since they may update and start
their updated server without noticing the impending chance of failure when
someone tries updating!
Apollo Server 2.x has attempted to maintain full compatibility with versions
of Node.js which are still under Long Term Support agreements with the
Node.js Foundation. While this continues to mostly be true, file uploads
are an exception which we've now had to make.
Third-party open-source projects must absolutely do what's best for their
project. From an architecture standpoint, I suspect that we (the designers
behind Apollo Server) are mostly to blame for this. Namely, it's unfortunate
that we had made such an incredibly coupled integration with a third-party
package that we restricted our users from incrementally adopting the
changes (and new/improved functionality) of, in this particular case,
the `graphql-upload` package. I hope we can take better care with decisions
like this in the future!
Lastly, this commit also adds documentation to help those affected.
Follow-up on the update to `graphql-playground-html` in previous release by
also bumping the minor version of the `graphql-playground-react` dependency
to `1.7.10` — which is the version requested from the from the CDN bundle by
`graphql-playground-html`.
Ref: https://github.com/apollographql/apollo-server/pull/2037
With any luck, we will no longer necessitate our fork which removed the
`graphql-config` dependency thanks to the work done in:
https://github.com/prisma/graphql-playground/pull/874🎉
Most notably though, this fixes a documentation scrolling problem with
Safari.
This was something I just happened to spot, though further investigation is
likely necessary to determine if other similar cases can be discovered.
This fixes this test to `expect` the number of additional `expectations we
have expressed for it: 2.
Testing errors in `catch`es of `Promise` chains necessitates the use of
`expect.assertions(n)` where `n` is the number of assertions declared in
that particular test.
Without this `expect`ation clearly defined, a resolved `Promise` will not
result in the assertion being tested. For example, if the `query` passed to
this test was a query against a type in the schema (i.e. `query: 'foo'` was
replaced with `query: { query: '{ testString }' }`) the desired error would
not be produced, but the test would still pass. I'm not saying that's
likely, but there's certainly the possibility that (given fault code)
something else in the plumbing could cause that Promise to resolve.
Ref: https://jestjs.io/docs/en/tutorial-async#error-handling
In an effort to maintain consistency and semantically correct meaning,
this changes (only in documentation and internal Apollo Server tests) the
name of the first argument in resolver signatures to use `parent` rather
than `root`.
While `root` certainly makes sense when the resolver is belonging to the
root `Query` or `Mutation` type, once nested field resolvers begin getting
called, the more semantically correct term would seem to be `parent`.
Since `parent` still makes sense at the root level, and since resolvers
frequently get copied and pasted into more deeply-nested positions, putting
this pattern in place for apps which are just beginning might just help
someone more clearly understand the relationship in the future — without
incorrectly thinking that a nested resolver is accessing the root of the
graph, rather than the parent.
Due to a number of other assignments within `createPlaygroundOptions`, the default is still maintained and the `playground` configuration parameter should be entirely optional.
I foolishly used `O.p.hasOwnProperty` here which, while safe for checking
properties, is actually not correct since this `then` property is inherited
from `Promise.prototype.then`.
Checking if `then` is a function should be safe _enough_.
Follows-up on: #1955
We expect introspection queries to behave in an synchronous manner since
they do not have any resolvers which return Promises. This expectation
seems to also be had by `graphql-js` which utilizes `graphqlSync`, rather
than `graphql` for execution of introspection queries. In fact, this may be
one of the entire reasons that `graphqlSync` exists: to fulfill a contract
for synchronous execution of server introspection. The introspection tests
within `graphql-js` seem to support this theory[[0]].
Utilities which wrap GraphQL resolvers should take care to maintain the
execution dynamics of what they are wrapping, or they should avoid wrapping
introspection types entirely by checking the type with the
`isIntrospectionType` predicate function from `graphql/type`[[1]].
[0]: 787422956c/src/type/__tests__/introspection-test.js
[1]: https://github.com/graphql/graphql-js/blob/74d1e941/src/type/introspection.js#L484.
Closes: https://github.com/apollographql/apollo-server/issues/1935
To avoid problems frequently associated with subclassing, and the possible
versioning ergonomics of subclassing the wrong version, this changes the
plugin infrastructure to no longer require subclassing the abstract class.
This was causing the `checkOperationPlugin` to be added to the list of
plugins to be executed, thus resulting in an additional plugin pass (of the
same plugin) for each request.
1st request = 1 plugin
2nd request = 2 of the same plugin
3rd request = 3 of the same plugin
Obviously, this was not intended.
This mostly reverts fd34771841 along with a
number of slight adjustments to avoid other typing luxuries which were
introduced with TypeScript 3.x.
While the generic `ServerOptionFunction` types and `HandlerArguments`
generic rest argument type were certainly welcome additions to the codebase,
they present a backwards compatibility problem for consumers of Apollo
Server who have not yet made the jump to TypeScript 3.x.
With any luck, when we bump the major version of Apollo Server to 3.x, and
in accordance with semantic versioning, we'll be in the position to
straight-up revert this commit.
