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
* Add correct project references for `apollo-server-cloud-functions`.
The `apollo-server-cloud-functions` has been been mis-referenced (or
referenced inconsistently) since its original inception in #1446 when its
package directory was `apollo-server-cloud-function` (singular!) and the
`package.json` referenced the plural form (`apollo-server-cloud-functions`):
https://github.com/apollographql/apollo-server/commit/724d9ff0#diff-e1d725fd66f7e9ef5251abf0437a09ca
These references have been mostly fixed in the READMEs and supporting
documentation, but the underlying monorepo directory structure has still not
been fixed, which I'm sure contributed to this module being overlooked and
unreferenced in the move to TypeScript project references in #1772.
Additionally, the lack of referencing in the monorepo's TS config has
resulted in it being broken in the most recent 2.2.0 release, as reported by
@pyros2097 and @thetre97 in: https://github.com/apollographql/apollo-server/pull/1896#issuecomment-436994955
This should fix that by properly adding the TypeScript project references.
* Sorting.
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 wasn't currently being exported, but this in-between commit will make
sure that the commit which follows this can be reverted without
inadvertently dropping this export.
By avoiding this pattern, we can maintain better typing for users of
TypeScript 2.8, which didn't maintain typings when passing through
`Function.prototype.bind` calls.
Also, personally, this just appears to be more readable.
