https://discord.com/channels/595317990191398933/802187271067140107/869307059466797066 Should be now, I think!

Oh awesome! I should follow these community posts more closely!

Is there a way to easily identify a variable as a DO id or DO name? I think I saw a snippet somewhere but can't find it. Edit: I found something in the chat example actually 😅

ES modules can import CommonJS modules in our system, just like in Node. We felt that it would be too harsh to say that people can't use CommonJS libraries at all if they use ES modules.

Is it possible to change a durable object's id without making a new object? I've not tried yet, just curious

No, a given id always routes to the same object. I'm assuming you're using named ids and want to migrate DOs?

yeah, is there any way about that?

say I store a users account with their email for the ID and their password persisted (I don't think this is a fit use for durable objects, but correct me if I'm wrong), how would I go about updating the ID when the user changes their email?

Is there a in-memory limit to Durable Objects?

hehe, there is indeed

standard limit for workers is 128MB

however, more than one instance of your DO may instantiated in the same isolate - in this case, they all compete for the same 128MB

in practice, you shouldn't have to think about it, especially if you keep your state small and mostly just make

.storage

calls

but it definitely can burn you in certain scenarios if you try to keep a bunch of things cached in memory, and expect to be able to instantiate several instances of the DO all at once

Ah okay, while experimenting and working on a chat application I got intrigued by scaling and how websockets / pubsub systems (horizontally) scale to millions of connections, it's interesting that you basically need some kind of Redis or In-Memory DB instance (which doesn't really horizontally scale) to get that far. I can image that once I have millions of websocket connections open on a DO, it'll probaby hit that memory limit. Edit: Should have been horizontally*

yea, you'd hit it before millions and should probably shard them across multiple DOs at that point. It would be awesome to have a runtime api for observing the current memory usage - so you could have a rough estimate of how much each additional websocket connection costs from a memory pov

I was actually about to request that today hahaha, I've been thinking about how you would scalably setup a pub/sub system on Workers / Durable Objects. Having some sort of memory indication might help to prevent it from going over and booing up more DO's to handle that scale.

yes! as long as you don't get unlucky: the runtime might decide to instantiate the other DO in the same isolate! then you're screwed : )

E.g. you'd have a primary DO handling storage and 'children', all the children of a DO connect to it's parent through WebSockets and can individually spawn 'children' too.

Ah yes that's a problem.

You'd just spawn 10 just to be sure 😅

Like a spider laying it's eggs, many will die, but many will survive

haha, they've stacked 21 of my larger objects into the same isolate - which is kind of a big problem - i wish you could specify the "sharing" level or a target mem usage when making the first stub call, that would give them more info on a per-instance basis of when to share or not

it's a tough problem, because for some DOs, they could get away with tons of sharing, no way to really tell ahead of time, but they could certainly use the runtime info from prior instantiations - anyway a way for us to specify this either at the class or instance (stub call) level would be awesome

i get the sense DOs are not really meant to be large and centralized, it would be difficult to build a centralized pub/sub bus - it seems like they are going more for smaller, user-level-state mostly https://discord.com/channels/595317990191398933/773219443911819284/869608842789552228

which is too bad imo, can think of lots of cool stuff you might be able to build with DOs if they were a bit more predictable in the memory department

I almost had a fix for this in on Friday but I need to do more testing, and I'm out this week. Soon!

either 1) migrate the data in their durable object to the new id or 2) use an id that's decoupled from the email, like a system-generated id. We have some ideas for how to ease migrations in the future.

Anyone know if there is a way to delete a Worker with an attached DO namespace if I do not have access to the script anymore?

As other have noted, there is an HTTP List API that you can use to paginate all objects in a namespace. DM me for details. But I would say that API is more for "administrative" tasks, like maybe to periodically crawl all objects to do some task or sync to some other DB. If you want to list objects quickly from inside a Worker/DO I would definitely make your own object and store the inside of a DO. Hopefully people will find useful patterns/abstractions and share their code, I think this will be generally useful.