Starlord
Starlord2mo ago

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?
No description
26 Replies
convex-threads
convex-threads2mo ago
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!
Starlord
StarlordOP2mo ago
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
erquhart
erquhart2mo ago
I wonder if you can just query the config and generate the result client side
ballingt
ballingt2mo ago
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.
Starlord
StarlordOP2mo ago
you mean client side cache? this data is loaded only once on app start
ballingt
ballingt2mo ago
I mean in the Convex backend, where each query result can be cached There's no DB bandwidth if the query result is cached
Starlord
StarlordOP2mo ago
how can i cache it?
erquhart
erquhart2mo ago
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,
Starlord
StarlordOP2mo ago
so static queries are cached automatically and if there are dynamic parameters not understand
erquhart
erquhart2mo ago
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.
Starlord
StarlordOP2mo ago
ok i understand this query doesnt have dynamic parameters. i will check why it consumes database data thank you ah ok it does have
ballingt
ballingt2mo ago
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.
Starlord
StarlordOP2mo ago
is there a way to debug if data is fetched from databse or from cache?
ballingt
ballingt2mo ago
It says in the dashboard whether a function call was cached or not
Starlord
StarlordOP2mo ago
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
ballingt
ballingt2mo ago
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.
Starlord
StarlordOP2mo ago
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?
Starlord
StarlordOP2mo ago
here exactly same request but for different users
No description
Starlord
StarlordOP2mo ago
and next request for user that was already cached is also not cached again
No description
Starlord
StarlordOP2mo ago
the problems is because of id increase in paginatedopts paginationOpts: { cursor: null, id: 6, numItems: 20 }, yes this bug comes from different id
ballingt
ballingt2mo ago
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
Starlord
StarlordOP2mo ago
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
ballingt
ballingt2mo ago
Yeah, today sometimes you can hoist the paginated query up to somewhere it is shared this behavior could be made more automatic
Starlord
StarlordOP2mo ago
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
ballingt
ballingt2mo ago
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
Starlord
StarlordOP2mo ago
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

Did you find this page helpful?