When I use it, I make sure the "value" is actually in the metadata that is returned with the list operation so that doesn't worry me but I'm wondering about the relative slowness? Do you have any benchmarks that show how much slower it is? I could create a simple one that worked completely in the local pop, but a distributed one would be better. When I use KV list prefix functionality, eventual consistency is good enough for me, so I would think KV would have the advantage considering that DOs might have to overcome a distance delay?

You can make whatever change to the JS side on your DO; The migration is not about the interface, is more about on how you "call"... If you rename the class (for any reason) you need the migration to the old data (storage) be available on that class... Besides that is just a regular JS class.

But if yo change your data structure you need to migrate your data on runtime.

If it works for you, that's great! And yes, there are certainly trade-offs between KV and DO depending on the application architecture. All I'm saying is, calling list() on the DO storage API (assuming your code is already running in a DO) is much faster and cheaper than calling list() on a KV namespace. (If you take a look at the pricing page, you'll see there's a pretty big difference there too.)

Am I right in understanding that I must call fetch() on my DO and essentially do routing inside of it if I want to handle different request types?

or am I supposed to create and initialize the DO stub and then... call its methods from the parent worker?

Essentially I just have a few transaction types that I'd like to implement as methods on a DO. I'm not sure if I can just do that and call those transaction methods on the stub from the public Worker, or if I have to have a big switch statement inside of fetch() and basically build an HTTP API for my public worker to call?

You hit on the two general strategies. There is a library itty-durable that will allow you to design an API inside of your DO and that will expose that API from inside a calling Worker. However, the default is to do routing inside of the fetch() function of your DO. The original itty-router can assist with this but the APIs for my DOs are simple enough that I have never found it worth it.

Does the in-memory cache for DO storage auto-evict when memory gets low, or are we supposed to guess at it?

it auto-evicts

If I have an instance of a DO with data persisted via the storage API, and I want to persist additional data, is there a way to append the new data without reading the existing data in order not to overwrite it, i.e. without a read request? I guess no..

Not without using a separate key

If I have something like ex. A e-commerce order. While that order is opened I have the requirement that multiple clients from across the world mutate it simultaneously in real time. My plan is while that order is open and being mutated keep it in durable objects. Then when the order gets closed I transfer that object to planetscale database

Does that seem like a good approach?

Thank you! That's what I thought too. We could just write additional instances and then read them all at the end. Depending on the size of the accumulating data, it would either incur the same or a smaller number of reads, I believe. EDIT: But it would require more delete requests, which are expensive. Maybe altering one DO instance is more cost-effective then.

Sounds fine, though it depends on how many clients are mutating the state at once

Max 1-10. Is that okay?

Should be fine then, as long as it is less than ~100 rps

Awesome. Yay. I love DO

And it will always be strongly consistent for everyone reading /writing to do regardless of where they are in the world right

Also, would I use list to get all of the orders that are open so meaning every order stored in the do persistent storage?

Do feature suggestions for DO go into this channel (there isn't a separate one like for Workers and Pages)? If yes, I'd like to share two feature ideas that would be awesome but are probably not compatible with the current architecture: 1. "Persist on evict": In-memory state would be written to the storage API in case of eviction. 2. "Append-only writes" to the storage API, i.e. without needing to read the data already stored.

1. Can’t really work because evictions may happen without warning, and in that case, you would probably want to evict whenever state changes

When the DO gets evicted from storage is there a way to save the memory to persistent storage during that event

I assumed the same, but maybe some incredible Cloudflare engineer can think of a solution. 😉

No, that's basically the feature suggestion I shared above. 🙂

I'm afraid he's right. Fundamentally, we cannot guarantee that the power won't suddenly go out, leaving no chance to persist anything. In theory we could provide an unreliable version of this, but people would inevitably rely on it and then complain when it doesn't happen. If an unreliable version is really what you want, I'd suggest setting a timeout for 5 seconds and then persisting. If a new request comes in during that time, cancel the timeout and set a new one for 5 seconds again.

That makes sense, and thanks for the idea, sounds like an optimization that could work quite well for us.

For #2, you could store data to progressively increasing keys, and use list() to read them back later.

Yes, that would lead to the same or a smaller number of reads. However, it would also mean more delete requests in the end, which are expensive, which is why for us updating an instance would probably still be cheaper overall.