The TL;DR of the storage offerings is pretty much just: KV: fairly simple key - value store with cache and eventual consistency R2: Use for files / large data blobs DO: A bit more complex key - value store with transactions and good list operations

I took a look at setting up KV on the site real quick, but it looked, as you said, simple/not suitable for thousands of lines of objects. The 60mb is split between 200-300 files of more or less equal size, would you still recommend R2 in that case?

hopefully my use case is clear 😅 kinda outside rn

That would fit easily in KV from the sounds of it, as it's separate files

It's just less suitable for things that you're updating frequently, and need consistency with, or things passed the size limit

Hmm okay so just checked and there are over 300 files though I'm currently only using 27. I'm still piecing together data from these so it could go up but unlikely to pass 50.

Haven't checked for almost a year, any interesting things happened with worker lately?

Updates are very infrequent (every few months or so) and manual (it's read-only, no user can write to it) so consistency shouldn't be an issue. 👍 Would you set it up so that 1 namespace = 1 file?

1 namespace for every file

cool will give it a try

thanks you two!

@HardAtWork Do you use Supabase?

Supabase cloud doesn’t scale very well at least their real-time stuff unless something has changed recently

only planning on using it for auth

How would I go about trying to push a fix to @cloudflare/worker-types? The type for

FormData.get

is

string | null

when it should be

string | File | null

the types are auto generated so i am not sure how one would try and make a pr to fix this.

What version and entry point are you using? New ones have it correctly

I have just found I can add /experimental for newest version in tsconfig. fixed ;p

yeah we use it for just auth and CRUD stuff. no real-time and nothing that needs to be fetched on every request

works really well for us

How do you handle the situation where a long duration JWT for a user needs to be revoked?

we aren't handling that right now since we cache the JWT response from Supabase indefinitely (using DO). but will add in some revocation stuff using DO too

I think will just need to send a revoke request when user changes password and then store that in DO and check on each request

Ahhh interesting, I was planning on using the regular cache api to do something similar, but DO makes more sense.

we use DO for several basic caching strategies and it works great. with itty-durable it's only a few lines of code

Thanks, didn’t know about itty-durable!

@sathoro do you offer your users long lasting API keys? I need to give our customers a key for our AWS compatible endpoints, but ideally a way of revoking if they stop paying lol.

we do yeah. they are stored in DO too lol

Aren’t you worried about the api keys being lost with DOs?

the storage is persistent. should be more solid than a regular DB