Cloudflare Developers•2y ago

You could also use a Durable Object for each user?

HHello, I’m Allie!You could also use a Durable Object for each user?

x03•3/24/24, 6:21 PM

Wouldn't that be expensive?

x03•3/24/24, 6:21 PM

I need some efficient way of storing users and sessions. My current approach is D1 database for users and KV for sessions

Xx03 Wouldn't that be expensive?

Hello, I’m Allie!OP•3/24/24, 6:23 PM

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

HHello, I’m Allie!It shouldn't be? DO compute is slightly more expensive than Workers on Standard,...

x03•3/24/24, 6:23 PM

Where would sessions be stored though?

x03•3/24/24, 6:23 PM

As part of the DO?

x03•3/24/24, 6:26 PM

Durable objects seems really complicated, are they really necessary for what I want to achieve?

Xx03 Where would sessions be stored though?

Hello, I’m Allie!OP•3/24/24, 6:28 PM

In DO Storage

Cloudflare Docs

Transactional Storage · Cloudflare Durable Objects docs

The Transactional Storage API allows you to achieve consistent key-value storage.

Xx03 Durable objects seems really complicated, are they really necessary for what I w...

Hello, I’m Allie!OP•3/24/24, 6:28 PM

Not necessarily, though going with KV will also mean that it may be hard to modify a session more than once a minute

HHello, I’m Allie!Not necessarily, though going with KV will also mean that it may be hard to modi...

x03•3/24/24, 6:29 PM

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

x03•3/24/24, 6:30 PM

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

Xx03 I dont really have a need to modify it once a minute. My main reason for using K...

Hello, I’m Allie!OP•3/24/24, 6:44 PM

Ok, then another option would be to have two types of records in KV:

SID

SID

, and

UID:SID

UID:SID

SID

SID

stores the actual session data, and

UID:SID

UID:SID

doesn't actually store anything, but just allows you to list through a user's Sessions

Hello, I’m Allie!OP•3/24/24, 6:44 PM

It's slightly more expensive, but in return it should be simpler to work with

HHello, I’m Allie!Ok, then another option would be to have two types of records in KV: `SID`, and ...

x03•3/24/24, 6:49 PM

I guess that will have to do, thanks for the suggestion.

Xx03 I dont really have a need to modify it once a minute. My main reason for using K...

Isaac McFadyen•3/26/24, 2:33 AM

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.

[1] https://developers.cloudflare.com/workers/platform/pricing/#workers-kv
[2] https://flareutils.pages.dev/betterkv/

mr nooli•3/26/24, 2:28 PM

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?

Mmr nooli Question from a noob here, why would you use something like CF KV vs Upstash's R...

Chaika•3/26/24, 2:44 PM

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)

mr nooli•3/26/24, 2:44 PM

Okay! I massively misread that as 0.2 cents

sorry haha

Chaika•3/26/24, 2:45 PM

well it looks like upstash redis is 0.2 per 100k

mr nooli•3/26/24, 2:45 PM

What a weird way to say 20 cents

mr nooli•3/26/24, 2:45 PM

Trailing 0 is what got me

mr nooli•3/26/24, 2:46 PM

Your right. CF is cheaper! I’m a donut

Chaika•3/26/24, 2:46 PM

well it depends what you're doing too. Upstash redis is flat pricing for read/writes

Chaika•3/26/24, 2:46 PM

CF KV is $0.50 per million reads, $5 per mil writes

mr nooli•3/26/24, 2:46 PM

I wanted a faster way to validate tokens for a cms I’m building

mr nooli•3/26/24, 2:47 PM

Rn I think the database call is slowing down the operation by quite a bit

Chaika•3/26/24, 2:47 PM

hmm, to me session store/that kind of use case is more of a Durable Objects thing

Chaika•3/26/24, 2:47 PM

CF's KV weakness is eventual consistency and min 60s caching

Chaika•3/26/24, 2:48 PM

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

mr nooli•3/26/24, 2:48 PM

Not necessarily sessions, but long standing tokens to hit the api with

mr nooli•3/26/24, 2:48 PM

Something like what unkey.dev does

IIsaac McFadyen Keep in mind that KV reads are $0.50/million [1] (and if you're doing a KV fetch...

x03•3/26/24, 2:51 PM

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

Mmr nooli Something like what unkey.dev does

Chaika•3/26/24, 2:52 PM

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.

mr nooli•3/26/24, 2:59 PM

Cool I’ll take a look!

mr nooli•3/26/24, 2:59 PM

My issue with unkey is it gets very expensive for a lot of keys

Xx03 That's really unfortunate. I saw articles of people saying to "host your whole a...

Isaac McFadyen•3/26/24, 3:10 PM

So kind of. You should investigate JWTs.

Isaac McFadyen•3/26/24, 3:11 PM

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.

Isaac McFadyen•3/26/24, 3:13 PM

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.

IIsaac McFadyen So kind of. You should investigate JWTs.