Perfect, thank you! And yes I’d be happy to. I’m traveling this week but I’ll see if I can hep when I’m back in town next week.
1 Like
Thanks! If you could make a note in the issue to let the author know you’ll help – I’ll do same.
Hey guys,
I’m the author of that PR as well as maintainer of the upstash redis sdk.
Just stumbled across this and wanted to say thank you for testing the pr.
Right now we’re just waiting for Drop official Node.js 12 support by n1ru4l · Pull Request #1417 · n1ru4l/envelop · GitHub to be merged, afterwards the tests should pass and the provider can be merged into envelop.
I just created an account here to comment, so I can’t guarantee I’ll actively monitor responses here unfortunately. I’d appreciate if you ping me in the github issue instead.
1 Like
I’m sorry if it’s not appropriate to put this topic on top again, but we are testing Redis cache using this guide, that is excellent, and it’s going well… Except for one point:
Some queries don’t have input parameters. The one that retrieve the current user based on session is the most important, but we can just exclude it from cache. Not a problem.
Other queries have input parameters but change its result based on current user. For example: I have the object “Post”, and everyone can see this object in the frontend. But the Post has a resolver called “isItMine” that compares the author id with current user id. If I exclude “Post” from cache, possibly cache becomes useless.
Is there a way to include keys from context (or from auth header) or remove resolvers from cache or solve this with a smarter idea?
Yes, there is.
See envelop/packages/plugins/response-cache at main · n1ru4l/envelop · GitHub
You can access the context to get the currentUser id and then use that as part of the session so that each user will have their own cache of a particular query.
// context is the GraphQL context used for execution
session: context => String(context.currentUser?.id)
This assumes that your request is authenticated of course.
Hope that helps!
1 Like