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
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
We compile `requestPipelineAPI.ts` as a separate TypeScript project to avoid circular dependency issues from the `apollo-server-plugin-base` package depending on the types in `apollo-server-core`.
We can't use `apollo-server-env` as a project reference because that requires `composite: true`, and that implies `declaration: true`, which doesn't work for `apollo-server-env` because we need to write our own declaration files for re-exported imports.
This commit also removes `apollo-engine-reporting-protobuf` as a reference, which errored out because it doesn't actually contain any TypeScript code.
While cacheControl can take a boolean when passing it in to ApolloServer as part of a Config, these will be converted to default options before passing them on as options.
