Feature Request: expose cache keys in resolvers/directives

[guoliu]

I haven't find any current ways of doing this, but it should be extremely helpful for folks who need more control on caches like us.

We are implementing a cache invalidation mechanism, where we keep a mapping between object global id and the list of cache keys associate with it, then invalidate that list when needed.

However, there's currently no easy way of getting the cache key in resolvers or directives. Looks like the cache key can be add to request context after this line, so everything downstream can access it if needed.

Do you think that's a reasonable feature, and are there any unexpected side effects of adding keys to context?

[glasser]

That does seem like it would be a useful bit of data to expose. I haven't been personally using this feature (or working in the Apollo Server codebase at all) very heavily since my initial implementation, so definitely curious what @abernix and others who are more involved think.

[guoliu]

Thank you for your response @glasser! Since we rely on this feature currently, we are using a customized plugin with cache key injected into context. I would love to submit a PR if @abernix and others think this is a useful feature to the community.

[BondDimy]

Hello, any updates about this feature ? I've also faced with cache invalidation issue, could you help me, please ?

[guoliu]

Hello, any updates about this feature ? I've also faced with cache invalidation issue, could you help me, please ?

@BondDimy I think the easiest way is to implement your own cache plugin that exposes the cache key, record the key in a directive, and invalidate them in another directive when needed. More discussions here: #2437 (comment)

[BondDimy]

@guoliu Thanks too much for your reply, yep I thought about custom plugin, currently working on it

[nelsonpecora]

Does anyone have examples of plugins that do this?

[guoliu]

Does anyone have examples of plugins that do this?

@nelsonpecora you can checkout this repo: https://github.com/thematters/apollo-response-cache

[nelsonpecora]

@guoliu ooh, this looks like exactly what we need, thanks!

[glasser]

I hope the other cache plugin helps!

One note is that the concept of "the cache key" for the current full response cache plugin doesn't quite make sense: when using the sessionId hook, the plugin tries two different cache keys (one with the session ID and one without it).

Since AS v3.10.0, the response cache plugin has a generateCacheKey option which takes in GraphQLRequestContext. So you could pass this option and give it the side effect of recording the generated cache key on your contextValue.

Because it seems like there are multiple ways to achieve this goal (and the goal itself isn't entirely well-defined) I'm going to close this issue. Sorry for the delay!