I think @User calculated it... it would be

$12.50 / 1000000 * .128 * 60 * 60 * 24 = $0.13824 per day

? This is the pricing for 24hrs with a 24hr constant websocket connection?

Yea still way too muchm, 10,000 users will be 1300$ per day

this is only true if your app needs network, compute; and storage isolation for each user in the same DO, which seems unlikely. if your connections are mostly idle, seems to me you could serve them from one DO.

just to clear my confusion: - if a connection to a DO is not "properly" closed (I guess proper JS could do that though on visibilitychanged event in website) we would pay basically 5 bucks a day without noticing until we see the charge - can we close the Websocket in the DO also from the DO itself, via some kind of cleanup task (and can we iterate all the still open Websockets) - is hibernating websockets in DOs a definitve "will do" or just a "maybe"?

Maybe a dumb question but when Im doing a put with more than one entry does that still count as one write op?

Same as list op I would say, like paying for each 4KB written https://discord.com/channels/595317990191398933/773219443911819284/827376869455298592

Hi , I want to know if cloudflare durable objet can work with wasm or only js ?

Is there or will there be a way to create expireable durable objects? I’m currently creating a new DO for game lobbies but after the game is done I’d like the whole thing to be tossed. I could create a job that manually cleans it up but it’d be nice to have a utility similar to KV keys where you can set them to expire so you don’t have to mess with keeping track of them. Would be especially helpful as there’s currently no way to list all the durable objects in your account, you can only list the storage items inside them.

System-generated unique IDs have better performance characteristics, but require that you store the ID somewhere in order to access the object again later. See the API reference docs for more information.

When these ids are generated, or maybe when the stub is connected? Or maybe even in the DO when storage items are set, being able to somewhere say “wipe this after 24hrs”.

Yeah, the lack of any

list_objects

or

map_over_all_objects

functionality makes some use cases harder. My current scheme is to have an

index

object to keep track of things.

I’m going to use KV to store IDs and then setup a trigger to flush them every 24 hours. But it’s cumbersome and with triggers not being name-able having multiple triggers causes additional complexity with another trigger I’m already running every minute

Afaik you will be able to determine what cron was triggered soon-ish, assuming from the discussions here. They also want to add ability to set DO event that will trigger at specific time, which will make it a bit easier for your use-case, I didnt notice any ETAs though 🙂

Regarding the "list of DOs", thats unfortunately heavy operation, as the lookup would need to be done globally - so keeping the index is way to go

Yeah,

state.storage.put(key, value, metadata: { ttl })

akin to KV's would be pretty cool to have.

Thanks for the comments. Very excited for the future of this product.

I think most of these requests (TTL, list of DO keys, etc) are pretty critical... in the meantime, I'll offer a suggestion from what I used on Slick (100% KV backed content engine/CMS). As you create new DOs, store a corresponding entry in KV as just a record of existence (delete this entry when you destroy the DO). These are easy to namespace via paths to keep organized, establish "ownership" or whatever. The only issue is a scan on the KV at any point might miss the most recent additions/deletions...

If you need up-to-date listings of DO IDs, you could store that list in a parent DO instead of KV (and you'd probably want to just reference that DO by name rather than

newUniqueId

).

hmmm - yeah that sounds better

Just depends on what's best for your use-case 🙂

ignore my suggestion folks, listen to Greg! 😄

Nah, there are totally times where KV is fine for the project. It just depends on what type of data you're working with

There some trick to this?

You need RC to work with DOs https://github.com/cloudflare/wrangler/releases/tag/v1.15.0-custom-builds-rc.2

ah, thank you!!

type = "webpack"

not allowed with DO?

No. Webpack 4 (which is what that default is) doesn't support module exports.

There's an example using Rollup here: https://github.com/xortive/durable-objects-template/

Or a Webpack 5 example here: https://github.com/cloudflare/modules-webpack-commonjs

esbuild is also excellent, but being newer, there are fewer plugins and less support available.