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).
Prior to embarking on the request pipeline work, and to facilitate
development on the new request pipeline, @martijnwalraven and myself
intentionally reverted some commits that had been recently introduced but
conflicted with the request pipeline branch that was already in-flight.
Rather than dealing with an incredibly difficult merge conflict, it was
easier to revert them an re-apply them later.
Original commits, reversions, and reintroductions:
* 6d6c9ff, 03a894d, b90ccc2
* 96af44e, 68c82e6, 81c4642
* 408198e, 2b470e1, 84bc834
* 4175f1b, 38e7b6a, 261994c
As is demonstrated by this short follow-up commit, this was all that was
necessary to make it work in the new model - once that model was finished.
While we're certain that the new request pipeline and its plugin model will
actually better support some of the behavior that required these initial
commits in the name of not introducing breaking changes, we feel it's
necessary to maintain their support.
I will point out, if you are at all affected by the above commits, we may
consider deprecating portions of those APIs in the not too distant future,
but we hope that the new model will help support those needs even better.
* Pass the context along to all the extension methods
Addresses #1343
With this change you should now be able to implement an extension like so:
```javascript
class MyErrorTrackingExtension extends GraphQLExtension {
willSendResponse(o) {
const { context, graphqlResponse } = o
context.trackErrors(graphqlResponse.errors)
return o
}
}
```
Edit by @evans :
fixes#1343fixes#614 as the request object can be taken from context or from requestDidStart
fixes#631 ""
* Remove context from extra extension functions
The context shouldn't be necessary for format, parse, validation, and
execute. Format generally outputs the state of the extension. Parse and
validate don't depend on the context. Execution includes the context
argument as contextValue
* Move change entry under vNext
