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.
This silences the deprecation messages which have been showing up in recent
local development on the new request pipeline work. e.g.:
> ```
> [DEP0010] DeprecationWarning: crypto.createCredentials is deprecated.
> Use tls.createSecureContext instead.
> [DEP0011] DeprecationWarning:
> crypto.Credentials is deprecated. Use tls.SecureContext instead.
> ```
The actual resolving of the context happens in ApolloServer#graphQLServerOptions, but errors thrown while doing that are currently converted to a throwing function.
This silences the deprecation messages which have been showing up in recent
local development on the new request pipeline work. e.g.:
> ```
> [DEP0010] DeprecationWarning: crypto.createCredentials is deprecated.
> Use tls.createSecureContext instead.
> [DEP0011] DeprecationWarning:
> crypto.Credentials is deprecated. Use tls.SecureContext instead.
> ```
* Provide ability to specify client info in traces
Adds the createClientInfo to apollo-engine-reporting, which enables the
differentiation of clients based on the request, operation, and
variables. This could be extended to include the response. However for
the first release. It doesn't quite make sense.
* Use extensions and context in createClientInfo
* Remove support for clientAddress
The frontend will not support it in the near future
* create -> generate and make default generator
createClientInfo -> generateClientInfo
* Clarify default values
* Allow an optional function to resolve the rootValue
Passes the parsed DocumentNode AST to determine the root value,
useful when providing a different rootValue for query vs mutation
* Add API docs for rootValue
