Allow gateway query planner to pass request context to GraphQLDataSource

[mgilbey]

When the query plan is executed, the query planner calls each relevant GraphQLDataSource, and it passes to it an object containing request; the new request for the data source, and context; this is the context property from the GraphQLRequestContext.

We can see this in the current send operation function:

    const response = await service.process({
      request: {
        query: source,
        variables,
        http,
      },
      context: context.requestContext.context,
    });

As there are many contexts involved here, lets call the GraphQLRequestContext the request context, and the context property from that object the user context. The type of this object would be GraphQLRequestContext<UserContext>.

The user context is created from the incoming http request in the contextFn argument to the ApolloServer constructor. This context is 'scoped' to the http request; all graphql operations in a single http request will share this object.

The request context is created for each graphql operation, and will be passed to apollo server plugins via the various lifecycle functions. This provides a good mechanism for adding properties to the request context that are useful for request or application diagnostics. Lets use the queryHash property from the request context as an example of data that we want to consume in a GraphQLDataSource. Our request context looks like:

{
  queryHash: "1234abcd...",
  context: { .. }, // user context
  ... other fields
}

We can see that the sendOperation above will only pass the user context and not the request context to the GraphQLDataSource, therefore preventing the GraphQLDataSource from accessing any data for the operation; in our example use case the queryHash. We cannot store this information in the user context as it is shared by all operations.

The feature request is to allow customisation of the context object that the gateway passes to the GraphQLDataSource so that information specific to operations can be retrieved, or to expose the original request context.

[glasser]

I think it would make sense to add a third topLevelRequestContext: GraphQLRequestContext option to process. (Arguably we could deprecate the context option if we wanted since it would be redundant.)