starlord_gf's Thread
hello, i have a query in my project that is executed every app launch by client. it fetches all the relevant configurations required for client logic and consumes the most database bandwith in my app. is there a way to reduce it somehow?

26 Replies
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets. If this is a support-related question, please create a post in #support-community. If not, carry on! Thanks!
the configs are mostly static and are only updated sometimes by admin. but this is pretty much data. the reason why it is in tables is because it gets updated sometimes and backend needs it too
i am missing caching mechanics in convex that would store static data without affecting database
I wonder if you can just query the config and generate the result client side
What's your cache rate? If it's not very high, you might split out the dynamic parts and the static parts so that you have a cache function that is always (automatically) cached. Reading dynamic data including auth busts the cache.
you mean client side cache?
this data is loaded only once on app start
I mean in the Convex backend, where each query result can be cached
There's no DB bandwidth if the query result is cached
how can i cache it?
Caching is automatic, the recommendation here is to split out dynamic parts like auth checks so this function’s result doesn’t vary. This should make virtually all calls to the function receive a cached response.
So you have a smaller function that handles things like auth, and move the heavier bulk that produces a consistent results into a separate function.
@ballingt is the recommendation here to use a sub query? Just realizing I don’t know how else I would split out auth,
so static queries are cached automatically and if there are dynamic parameters not
understand
They’re still cached with dynamic parameters, just at a lower rate since the same set of dynamic parameters would have to be encountered multiple times to hit cache.
ok i understand this query doesnt have dynamic parameters. i will check why it consumes database data
thank you
ah ok it does have
I'd split out the parts that can be public and do separate queries from the client. We haven't loudly recommend subqueries yet because we're working on tooling (like the new insights on the dashboard!) for this kind of thing and don't want to thrash people as we changed details but yes, a subquery that didn't contain auth info (normal public queries contain auth as an implicit parameter if you ever access
ctx.auth.getUserIdentity()
) is exactly what you'd want here.is there a way to debug if data is fetched from databse or from cache?
It says in the dashboard whether a function call was cached or not
i see thank you
hm seems there is no way to cache paginated queries even if database data never changes because cursor is always counted as dynamic parameter
@ballingt do you think it is possible to cache paginated queries somehow?
now it became the most database consuming query in my project
once cursor changes its always counted as new request
could you say more about the cursor changing?
usePaginatedQuery
works by subscribing to multiple pages of a query, but each of these pages can be cached. Are the cursors different for different users, or different points in time for one user using the app?
Oh also @Starlord could you open a support thread about this please? It's a good question, it'll take some discussion.i think i understand the problem now. the problem is not because of paginated query. but because of user. cache is different for every users. so even if data is same and user requesting it is different cache is not used. and no user related requests are used in the query
should i open community question for this?
here exactly same request but for different users

and next request for user that was already cached is also not cached again

the problems is because of id increase in paginatedopts
paginationOpts: {
cursor: null,
id: 6,
numItems: 20
},
yes this bug comes from different id
Yeah I should have said "community question," that's what I meant
Ah yeah it must be a new render of that component so a new id, we can look at whether that's really necessary.
Using a new id means each use of the paginated query starts over, which does some useful things but isn't good for caching
So that would mean i need to have query in central place to not recreate it on component remounting. Maybe just remove id from caching condition?
Caching in paginated queries becomes really useless this way
Right now i think I can solve it using custom pagination
Yeah, today sometimes you can hoist the paginated query up to somewhere it is shared this behavior could be made more automatic
Ok but please consider to remove id change from caching. Also I am not sure why id increment is there because it's practically useless. I might not be alone who would run into this problem
The way we'd remove it from caching is by removing it from the hook, the problem here is the usePaginatedQuery hook
unfortunately it's a lot of code so it's not trivial to reimplement, but that's the way I'd fix this https://github.com/get-convex/convex-js/blob/main/src/react/use_paginated_query.ts
rationale for id here https://github.com/get-convex/convex-js/blob/babd78c9f09d83190bde408ee374bc8380874a53/src/react/use_paginated_query.ts#L387-L410, agree that it's probably not something we need if we can get around these
yes i saw this in the code. just dont understand what this id is for
well ok i understand thats its needed when there are multiple same pagination queries running in parallel
still bad solution as far i can see
Instead of using an incrementing ID, we could create a stable identifier based on the query parameters and pagination state.
for now i created own implementation of paginated query that is using id 0 all the time
well it solved caching issue withing same session. but if it is new session after login or new user its still not cached for some reason while all query paramaters are same and stable
this is not just for paginated query but for every query
https://discord.com/channels/1019350475847499849/1325282507356110928