**Caching limitations. please consider
Caching limitations. please consider this an official answer thread (for now) 😄
3 Replies
There are two main gotchas with convex caching
1. paginated caching using convexes usePaginatedQuery react hook, it ends up it uses an incrementing id as part of its params payload. I'm sure there's a good reason it does this for correctness etc, but it mean, formally, queries using this hook will essentiall never be cached. this is old code, and I just learned about this shortcoming. we'll see what we can do about it, but in some ways I'm not shocked--we're not terribly happy with the old pagination system. so finding another limitation in it isn't that surprising. there are alternative approaches (2 or 3 of them) that the team has written in convex-helpers and in the aggregate module that may give you better cacheability of your paginated queries if that's important to your app
2. interactions between caching and authentication. the "top level" query is parameterized on user id etc, for security reasons. so this means that every user will have to recompute the query. this makes sense and it the right thing to do. Except, often, most of what this user wants to access is a shared resources (a "subquery") that definitely can be shared between all users and save you massive amounts of database bandwidth etc. At Convex, this need has been called "subquery caching", and it's not implemented yet. The idea would be if you run
ctx.runQuery(other.query) in an authenticated query, and that other queries contains common data, you should be able to avoid the invocation and pull the cached query value very cheaply. this should work, but we've never prioritized building it, yet. it's another thing we need to do soonthere ya go! those are the two things to be aware of. everything else should work, and if you want to reason more thoroughly about index ranges and cache keys etc, always encourage you to read How Convex Works ( https://stack.convex.dev/how-convex-works )
How Convex Works
A deep dive on how Convex's reactive database works internally.
feel free to fire away with any more questions about caching gotchas
oh, here's a third thing: we don't reason about individual function changes when you push more code. this is really b/c a bundler creates just a giant mess of JS and it's pretty fragile to try to like introspect the AST and make sure you know that a query wasn't affected byh a push. so any backend push does invalidate all the caches. the cache key is like the codebase version, not (codebase version,function name) or anything like that
on the benefit side: many people don't know that convex also utilizes a document-level cache as well. so even though a query cache invalidation may trigger a function re-run, it often won't actually need to talk to the database for most records, and you're not charged for bandwidth when that hapens
okay! that's everything for now. I think!
I'm very motivated now, though, to have the team add some debug logs in the OSS version that drop in tracing information about what the cache keys were for any given query so folks can dive in and learn more easily why cache hits are and aren't working. there are obviously a lot of subtle ideas here, so more transparency would help speed up communication between users and the team about what is happening and why