caching
Is something like redis needed when using convex if it has built-in caching. I know the point of caching internally with convex is already great, however what if we want to limit the calls to the database because even if it only takes
80ms it still uses function executions. I guess what im asking is it smart to wrap convex in our own cache system to prevent more database calls or maybe a trick we can use to cache things ourselves, and to keep everything realtime maybe some kind of cache subscriped to the ws events just like the db, so its all in sync but doent have to make the http calls back to convex for reads?7 Replies
Our official goal is that you should never have to do this
so, perf wise, our cache is quite fast (~1ms execution times, eventual edge caching etc)
and cost wise, a goal of our will be to eventually price this through to you so that you don't have to worry about this
like right now, a cache hit takes a "call" but no db bandwidth
we'll probably have "business plans" in the future that price through cache hits a lot cheaper than regular calls.
biggest reasons that plan doesn't exist yet is (1) few users are at the scale that it matters; (2) complex pricing sheets are a turn off early in your relationship with a service; and (3) it takes time to ship everything at a high quality, including a new service plan sku 😄
but we definitely intend to make this all true in the future. if you feel like you need to manage yet another cache to get around a problem of convex, we've let you down
so the advice in the short term is, try not to worry about it until it's a problem. and when it's a problem, talk to us and we'll figure it out together
edge caching would be nice + nextjs edge runtime
understandable
okay thanks
Jamieno problem!
Oh that actually surprises me! I thought that cached hits to the server wouldnt count as a call.. hmm...
right now they do
yeah they do, which is why im happy for #Local backend .
But yeah the cache is on there end so it still requires a
http request. Also it could miss so then it would still need to be fetchedHi, quick followup @Jamie , loving the product so far 🫶
When you add the prefix search support later this month a nice usecase for it is serving "algolia style" search widgets.
According to the above info, each character typed by a user would mean a call ... burning through call counts quite quick. This does not seem to be a balanced approach. ( If I got it right)
I would like to see parity in pricing with something like upstash or algolia for those cases, enough to keep me from going the two-dbs route.
I love the elegance of having a single back end that just works regardless, but pricing needs to be flexible proportional to value (dont want to be making decisions on when to use this or that just for cost purposes).
Can I assume you will go "do no evil" and make this price balanced, and just build away? 🙂