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.
This commit supports two new concepts for reporting:
1. Client identity
2. Schema awareness
Client identity allows the GraphQLRequestContext to be mapped into
`clientId`, `clientName`, and `clientVersion` which can be used to
filter and view requests and metrics by client information.
Schema awareness introduces schema branches which allow arbitrary
strings to generate new "branches" (or variants) of a schema.
This commit adds a new field to the GraphQLServiceContext which is
a hashed representation of the schema. This is useful as a key value
to represent the schema and is sent as part of reporting to engine
when enabled
