Im sure that will be a blog post on that matter, but lets me see if i understand the latest changes: * There will be a "parallel" worker/cache with additional 128MB of memory that will cache DO storage operations, if a put/read something, in the next "read" operation will be almost quick as a local variable inside of the DO itself. * This cache will handle the back pressure of the writing operations and will automatically handle the cache limit up to 128MB; * If we don't await the "put" operation, before we return the response all writes operations will be awaited. I'm assume that if something get wrong we will see a exception. (Can we catch? ) * If want respond before the write finishes i need to pass "allowUnconfirmed" or use the ctx.waitUntil to write. Not recommended anyway. * No information if we will be charged for read on cache. But if not has a good potential to simplify the code and avoid unnecessary memory consumption on DO side. * Cloudflare is ruining our experience with other cloud providers as we don't have anything as fun as DO!

The cache won't store 128MB in steady state. It can go up to that while awaiting the completion of disk writes, but will drop back down to a much smaller number once the data is safe on disk. These are all implementation details that could change at any time, so you shouldn't rely on the precise details.

So, is still a good pratice to keep the value in memory to future reads if we believe that will requests rigth?

It depends. If it makes your code simpler, go ahead and store the value in memory. If it makes your code more complex, I'd rely on the built-in cache instead. Performance-wise, they will be similar.

Nice, so the only downside of that cache is that will be evicted at any time, well... like any cache btw. okay.

yes, but also, keeping a lot of stuff in memory hurts performance (garbage collector works harder), so the fact that the cache balances keeping hot entries in memory vs. evicting cold ones may be a benefit compared to keeping everything in memory. If you rely on the built-in cache then you don't have to worry about tuning this, we do it for you. 🙂

Thats a very good point. So, we can expect that will keep a reasonable good amount of hot data in cache.

Hoping the cached data ".get()" won't be charged.

It's the age-old balance of what makes varnish so fast: you just mmap a gigabyte of 'file' and let the kernel work out the details

Hey, any suggestion or doc how to add durable-objects to a worker that is writing in Typescript. From this doc https://developers.cloudflare.com/workers/learning/using-durable-objects#instantiating-and-communicating-with-a-durable-object I need to replace the addEventListener to export default { } but when i do that and deploy to a staging environment I received an message

No event handlers were registered

In my project I use typescript, webpack to transpile to JS and itty-router to handle the routes

Hey @User , I don't suppose you guys use any typescript in statusflare, do you? 👆

About my issue I found out that was more easy to change the bundler from webapp to rollup and then I had to export the Durable Object in the root file

Other question, do we have Durable Objects in diferent enviroments? like the same behaviour we have with Namespaces?

I need to persist like 10.000 keys in the storage durable KV, but each record Is small enough to fit in the metadata so I can list them all. Is this a base practice?

* bad practice

At that point, it might be easier to store a 10,000 item JSON dict

Yeah, but DO wont store more than 32kb. Btw I noticed I switched back to regular KV because of that. Otherwise I wouldn't get metadata at all. Which means my question makes no sense 💩

Yeah with the DO storage API,

list()

returns full values, and there's no separate "metadata".

is it possible to open WS connections from other DOs to DOs?

im looking at some modeling at it seems to make sense to have something like Wallet, User, User2 Where Wallet is a wallet that belongs to the User and User2. So it exists on its own DO

now, we dont want to lose realtime updates for User if User2 modifies something in Wallet

So then both User and User2 DOs open a WS connection to Wallet DO, Wallet DO keeps the balance syncronized

Yes you would just have to put an array of connected websocket clients in the Wallet, and then send update packets to the clients when the balance changes.

but what would be the cost of these internal websocket connections?

also would that kinda break the DO premise in that the DOs will be alive almost 24/7

like say a DO has a webscoket open to another DO, but both DOs just had all the webbrowsers connected to them drop

those DOs each still have 1 connection open between eachother

therefor they will never go down?

No because in the technical sides of things, Cloudflare websockets don't actually stay alive 24/7, the script is shut down and executed again when data comes in from the socket. Instead of thinking of it as a persistent connection, think of it as if it were separate http requests going back and forth as that's essentially how it works.

ahh