true

We don’t have any intention to limit folks that are using the storage legitimately. It’s primarily there for abuse protection.

What do you need/expect to happen? R2 should serve the old value until the modify completes. But it is read-your-writes.

What he wants is a transactional update basically so between any read and write its impossible the value changed

Which is the default for DO 😛

I assume for DOs though there's basically no limits as far as total storage just have to request increases if needed?

Yeah DO has that built-in.

That's great to hear, DO is the perfect fit for this use case and good to know I won't run into potential scaling issues later.

You could also use DOs to ensure consistent writes out to something like R2

There’s a limit in the sense that we don’t have infinite disk. So I guess if you need a PB or something you may want to talk to us in advance. Or I’d lean toward the R2 hybrid above in that case

Yep that's the other way I was thinking, but would be higher cost not only the extra R2 class A, but also DO writing to R2 will be billed for the wall clock time.

Yeah thats fair haha that would be insane scale for a database so I dont imagine many people would ever really hit that

I've looked at something similar with D1 + R2. Could do an entry per key that maps to an R2 file and update the mapping at the end of the transaction. iirc that should still allow blazing fast reads as D1 will eventually be replicated everywhere. Writes would be slow/centralized though

guys, I am getting this error "DurableObjectError [ERR_CLASS_NOT_FOUND]" during development. can anyone help me with how to use durable objects in development??? I am using this command "npx wrangler pages dev -- npm run start"

Use hono template/example, and you’re ready to fly.

Hey muslex, Thanks a lot for the reply!!! we are working with Pages and function, can we use hono for that? We are trying to bind the DO during development and use it from functions. Is there any example on the same?

Not sure for Pages. But I have a lot of projects with Workers.

It may help https://github.com/honojs/examples/tree/main/pages

Is there any publicly available material that explains implementation of a chat app using do? The example offered on the github is for advanced users or people with substantial experience in programming. What I was asking is sort of a tutorial that explains some basic-to-intermediate parts with words small examples and in order.

do you guys know a type-safe library (very small, just minimum features) to easily work with durable objects?

Hi everyone. I have an existing application that I have running in Azure Durable Entities, and want to see how the application can transform into Cloudflare Durable Objects. Currently the average state size of each item is roughly 500KB, although it could hit a maximum of 15MB. Does that exceed the limit in Durable Objects or be an issue performance wise? Thanks

I am a heavy Microsoft Orleans user and am looking at Cloudflare Durable Objects as a lightweight approach to achieve a similar outcome 🙂

Not sure how azures thing works but for Cloudflare DOs can have an unlimited number of key value pairs per object. Each value can be up to 128KiB so if you split up your data into many keys you can easily have 15MB

So the entire state object isn't just serialized into a blob value?

I see that everything is keyed

await this.state.storage.get("value");

I was expecting more of the state object being some dictionary (of anything). That would give me unlimited state storage (as its just serialized into a blob) but it would make it slow to hydrate a durable object from the blob if the durable object was not already in memory.

No, you only retrieve DO data from a key-value storage, where values are max. 128kb. Some restrictions: batch read (list command) retrieves keys+values, not just keys, and materializes all values in memory.. memory limit is strict 128MB in contrast to I think 1GB+ on Azure functions; overall definitely more restricted, I think using Cloudflare KV storage (similar to Azure Table storage) might be more appropriate and just save the corresponding KV storage key in DO, KV value size limit is 25MB

I would assume DOs are still more comparable and probably what he would want here. And there can be an unlimited number of key value pairings in a DO so the limit really shouldn't be much an issue

Fetching 15 MB in a DO isn’t ideal (fetching 120 keys, stitching together, list limit is 128), I think DO is the right compute primitive here, but it’s not ideal for many storage patterns, that’s IMO where KV/R2/D1 can help

I am working on such experiments at https://github.com/cleaton/type-knit . There is also work on getting such features integrated to next version of honojs https://github.com/honojs/hono/issues/727