apollographql / apollographql/apollo-server
Allow passing in operationContext when fetching persisted queries
- Dominant language
- TypeScript
- Stars
- 14k
- Forks
- 2k
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 2
Description
tl;dr I want to be able to call my distributed APQ cache with the trace id from the GraphQL HTTP request
A customer is adding a Redis cluster to their pipeline for APQ requests. Today it is not possible to access the `operationContext` while making a fetch to Redis because the call to `.get` only passes in the simple key.
https://github.com/apollographql/apollo-server/blob/1b940cf682ade7bb699560e6cb316372f2814275/packages/server/src/requestPipeline.ts#L145
This by design due to the simple nature of [@apollo/utils.keyvaluecache](https://www.npmjs.com/package/@apollo/utils.keyvaluecache) which only accepts the key for `.get` calls.
However, inside the context in the requestContext we store a DataDog span that we would like to activate and create a custom DD span to have metrics for the request to the redis cluster.
Since we are not able to continue the span with the same trace id from the request the spans look like this and are detached from the GraphQL request:

------
Instead we would like to be able to read the trace id from the request context which means we need some way of passing extra info to the `.get` call. Some small tweaks to the existing package like this could work but open for feedback
```ts
export interface KeyValueCache {
get(key: string): Promise;
// Optional new method so it is not breaking
get?(key: string, options?: {}): Promise;
set(key: string, value: V, options?: KeyValueCacheSetOptions): Promise;
delete(key: string): Promise;
}
```
Contributor guide
Research direction
Start at packages/server/src/requestPipeline.ts around the linked .get call, then inspect the KeyValueCache interface in @apollo/utils.keyvaluecache and how operationContext is stored in requestContext. The change is complete when persisted-query fetches can receive the needed request context without breaking existing cache implementations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, redis, typescript
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100