It shouldn't be? DO compute is slightly more expensive than Workers on Standard, but if you are just using it for storage, then compute shouldn't be much of an issue
I dont really have a need to modify it once a minute. My main reason for using KV is because I need to fetch the session on EVERY request, so the speed of the fetch is really important. Also KV has expiration so its super easy to make sessions expire after a week
I've never used durable objects and it seems like a really weird approach to storing state, especially since currently my users and apps and subscriptions are all nicely related in the database
Keep in mind that KV reads are $0.50/million [1] (and if you're doing a KV fetch on every request that can get expensive fast). I'd recommend something like BetterKV [2] if you're doing a KV read on every request.
Question from a noob here, why would you use something like CF KV vs Upstash's Redis implementation? Cost wise alone (unless my maths isn't quite right) it's a hell of a lot cheaper going upstash?
Is it? I'm sure there are some advantages to other KV products, CF's KV is kind of narrow in scope, but it looks like Upstash Redis is $2 per million commands times the amount of replicas you have (KV is $0.50/mil), plus $0.03 per gb used of bandwidth (where CF is 0)
DOs are cheaper anyway unless you're going to be performing hundreds of reads a second on that key, in which case you'd kill/overload the Durable Object
That's really unfortunate. I saw articles of people saying to "host your whole app only using cloudflare" and that just seems impossible since most crud apps with auth need to read from some sort of database / KV store to verify user authenticity on every request, racking up read costs.
I might just switch to using a VPS if a full cloudflare setup isnt practical
hmm, wouldn't be able to do rate limiting without DOs or something but API keys alone would be kvable/as long as you stay it may take up to x time to become active. DOs are interesting though because they're cheaper even including request pricing, depending on how much duration you need.
TLDR: issue a JWT one time (DB lookup), then you can cryptographically validate the JWT (without a DB lookup) on every request which will tell you whether the user is who they say they are.
The downside is that JWTs are more tricky to revoke, other than the standard "this is valid for 24 hours". If that's a concern you can always do a DB lookup on sensitive actions like password changes, while allowing regular JWT validation on standard actions.