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.
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
This PR fixes#1836.
This PR enables developers to inject the http agent to be used on the network requests to apollo engine endpoint.
<!--
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
* [x] Make sure all tests and linter rules pass
<!--**Pull Request Labels**
While not necessary, you can help organize our pull requests by labeling this issue when you open it. To add a label automatically, simply [x] mark the appropriate box below:
- [ ] feature
- [ ] blocking
- [ ] docs
To add a label not listed above, simply place `/label another-label-name` on a line by itself.
-->
This commit follows-up on #1795, which introduced the new request pipeline, and
implements the triggers for its new life-cycle hooks within the various
integration packages. Previously, the only implementation was within the
`apollo-server` package and didn't get triggered for those invoking the
`applyMiddleware` method on integrations (e.g. `apollo-server-express`,
`...-hapi` and `...-koa`).
While in an ideal world, ALL existing `applyMiddleware` functions would be
marked as `async` functions and allow us to `await ApolloServer#willStart`,
in practice the only `applyMiddleware` which is currently `async` is the one
within the Hapi implementation. Therefore, we'll instead kick off the
`willStart` lifecycle hook as soon as `applyMiddleware` is started, return
as quickly as we have before and then (essentially) yield the completion of
Apollo Server's `willStart` prior to serving the first request — thus
ensuring the completion of server-startup activities.
Similarly, we'll do the same for `createHandler` methods on integrations
which don't utilize Node.js server frameworks but don't have `async`
handlers (e.g. AWS, Lambda, etc.).
In the same manner as AWS Lambda, this now utilizes the
`ServerOptionsFunction` type pattern. Previously, this typing still appears
to be incorrect, but that incorrectness was being missed because the
sole invocation of this at the end of this integrations `createHandler`
method was utilizing `this.createGraphQLServerOptions.bind(this)`, whose
types were unable to be inferred. (I'm making a slight assumption on this
last bit because this mis-typing only surfaced after I switched to a more
explicit notation, but I believe this to be true).
