Caching woes
Hello, I have a question regarding Convex. I'm exploring its use for an internal app for approximately 3000 staff members. My understanding so far is that caching appears to be limited to a user's session if
ctx.db.auth is called.
However, since the entire application is behind a login, I anticipate that I will largely not benefit from caching, despite having a significant amount of shared data among staff.
My current thought is that the only solution would be to move all queries to the server, perhaps by using a stable argument like a secret. Is this understanding correct, or are there alternative approaches to leverage caching for shared data in an authenticated environment?6 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
Your understanding is correct - that caching would largely benefit each user (as they move pages, refresh, etc), but not be shared across them.
However, when an action does a ctx.runQuery to an internal query, if that query doesn't read auth, it will be cached between users.
However, even with 3000 staff members I would avoid worrying about caching until you know it's an issue. Hard to say without knowing your usecase. but the biggest customers on convex all use auth and generally don't think about optimizing cross-user caching
Hi Ian, thanks for getting back to me.
I don't usually over-optimize, but it really feels like a waste to not use the cache, especially since Convex's caching feature was what first got me interested. Plus, with my users being in SEA, I think it would definitely help with latency. My only real gripe is that I can't use the WebSocket client if I'm fetching on the server. but I think it's acceptable since i'm gonna do this only if the data is very much shared among the employees (like company events, announcements, etc.)
Maybe start with the simple approach and see if bandwidth is an issue?
We're also hoping to add sub-query caching, but not in the next few weeks.
By "sub-query caching", do you mean caching on a statement-level instead of query-level? For example caching a single
.collect() statement inside a query?
That would be very cool! I've inquired about this previously. In our product, we render the same video feed to all users (so can be cached), but we allow for users to disable certain topics on their account and find it easiest to apply this filter on the backend by just filtering this feed after we fetch it. This invalidates the cache however, but shouldn't need tono on a
ctx.runQuery level.
But I'll re-emphasize that generally database bandwidth isn't a concern for most customers. Definitely reach out if you're seeing something eggregious! One way to get around this is to have organization members get issued a shared token in an authenticated route, then all use that token on a shared un-authed query, and rotate & refetch that token, but that's kinda re-implementing auth tokens. This is what the presence component does I believe