The biggest problem with cache is its per datacenter so if you have spread out requests even in the same region you can still have a lot of misses, but cache does help for sure.

by separate thread, do you mean a separate isolate entirely then? or another event loop inside the same isolate

I guess I could probably use KV for a better cache hit for any objects that I want to ensure higher write throughput to

or general read-only access to another DO's storage by another DO?? that would be killer

big +1, dumping out of durable objects is really slow. would love to see point in time backup and restore

potentially yes separate isolate (again not promising anything, but we're aware and have been talking about various approaches)

sending reads only to KV is one way of using cache in front of a Durable Object today, yes. What I'm trying to ask is if you could use every other feature of cache (including tiered caching and request coalescing to limit thundering herds) was available in front of a durable object would you still want read-only access for non-backup related workloads?

Oh if those other features of cache were available I wouldnt need readonly DOs for non-backups 🙂

No, I guess its clear. If its in storage, then its all good...

DB shards yes please!

Also would be cool if they could spawn in colos that otherwise didn’t support DOs

Can someone pls explain what this means "by splitting the requests among more instances of the Durable Object." (here https://developers.cloudflare.com/workers/learning/using-durable-objects/#error-durable-object-is-overloaded). How can I have more than 1 instance of a DO for the same context? Taking the example of the chatroom example that is given as a good use case for DOs - 1 chatroom can only be represented by 1 DO. If there are more rooms, then there will be multiple instances of the DO, so thats fine. But if there are too many messages / users / activities within the same DO, for the same room - how does one follow this guideline "splitting the requests among more instances of the Durable Object."

currently, dividing up state between multiple DOs is entirely up to you as a developer. For the chatroom example, perhaps that would mean giving up on having a total order of messages, splitting the room into several DOs with X users per DO, and batching messages between those DOs

What is the behavior for unhandled exceptions in DOs supposed to be? I was under the impression it was supposed to shut down the DO, but experimentation seems to show it does not.

Is there a little thing somewhere that explains how exactly DO alarms work. I've been trying to wrap my head around how CF becomes sentient and knows when to execute the alarm out of the probably thousands of other alarms, at the same time, but it doesn't make sense really

surely not a setInterval checking every x time

https://blog.cloudflare.com/durable-objects-alarms/ is probably as close as it gets

can somebody please help me out with itty-durable

I am not using itty-router and having trouble actually using the durable classes

when I try DurableClass.get() it says get is not a function. so I think I need to access the proxied object but I am not sure where that is. I did call withDurables on my request already

const doObject = proxyDurable(env.DO_CLASS).get("doID")

doObject.ping() (or whatever function you want 🙂 )

I ended up using

env.DO_CLASS.get(key)

, is that okay or should I use proxyDurable?

also where does proxyDurable come from?

Hi! Currently we create 1 DO / user , based on idFromName(email) So, when it's sign in / sign up, we first need to known if the DO already exists. For that, I think we are forced to make a request to the stub and check the storage/state for that, I haven't found any .exists(id) method that prevent to create it. But with jurisdiction laws like GDPR, we need to search in the worldwide DO namespace, but also in each jurisdiction subnamespaces ( only 'eu' for now ) This mean we need to create stub + fetch multiple DO, just to known if the users exists, it's a poor performance solution. Until CF proposes a .exists(id) function, it's not really interesting to uses idFromName(email), we are forced to uses another storage layer to known if an account exists (but it's not GDPR compliant to store the email in KV or D1 because it's replicated on worldwide... )

You could maybe use a hash of the email for GDPR compliance?

Since it isn’t reversible, unless they know the original email, they won’t be able to get any data from it

And if they have the original email, they don’t need KV

yes it's what we've done, but the second problem is a KV is slow, because it's will be always a cold key (> 60s)

could be really useful to have an .exists(id), do you known if it's planned?