Warming caches?
haruska opened this issue · 7 comments
This is a great gem. Thank you for releasing it!
I was curious if you had a good strategy for warming caches in the background. Ideally, we'd want to set the expiry on graph to an hour and run an ActiveJob that warms/refreshes the cache every 30-40 min.
Anyone have thoughts on how to do this? I'm happy to write an enhancement but I'm unsure what that would be. Maybe a flag/option passed into a query to ignore and regenerate the cache?
The goal would be for someone calling the graph to rarely, if ever, end up with a cache miss.
He @haruska Thanks for checking the gem out. Currently there isn't and official way to pre-warm the cache. I have considered adding a force argument for something similar that forces resolvers to execute without fetching from cache. It sounds more like you want something that will parse the schema and execute all the resolvers in context so that the cache is warmed.
There are a lot of factors to consider in this case too, though. Currently we cache values under keys that include arguments to the field so you'd have to fully exercise those fields to get a full cache up front. It would depend heavily on your schema design. If it is sufficiently simple you should be able to just execute a bunch of queries in a background job to warm the cache.
sorry for the little rant, does that help clarify at all?
Actually, I don't need something to parse the schema and execute all the resolvers... that seems like a wide problem to solve. What I'd actually like to do is signal to the API that a request should update the cache (force?). However, when storing the result in the cache to strip that force param so that it is a cache hit for other clients.
Then, I could actually resolve queries that I'd like refreshed in the cache by passing a force param in a background job. The other clients of the graph would continue to see the currently cached result. When the job's query finishes resolving, the result would replace the cache. Then other clients would get the updated cached results on subsequent requests.
Hope that makes sense. I don't even know if a param would be the way to go... but the ability to signal to the resolver to force-update the cache somehow I think would solve the enhancement.
🤔 maybe we could look into the query context on resolution so you could execute your query like this:
MySchema.execute(query, context: { force_cache: true })which can be triggered off of a header or param or something. In the caching logic we could force the resolver to execute and write to cache...is something like that what you're looking for?
I just published #33 which should fulfill your needs here. Take a look and let me know what you think.
i looked at the diff... This would certainly allow for a separate job to warm/re-populate a cache entry. Thanks!
No worries 😃