Number of objects is unlimited. Number of namespaces (i.e. classes) is limited. Though I'm a bit sur

Number of objects is unlimited. Number of namespaces (i.e. classes) is limited. Though I'm a bit surprised the limit is 20, that seems like something we should increase.

Ccodefrau I'd assume you get 20 namespaces per environment

Wallacy•8/9/21, 10:13 PM

When i list my namespaces using the rest-api, i only get id/name/script/class theres no info about the environment; I just tested using the --env and the effect is the same, as the each env is also another new script.

Kkenton Number of objects is unlimited. Number of namespaces (i.e. classes) is limited. ...

Wallacy•8/9/21, 10:16 PM

I dont know exactly what can be a reasonable number, but if the intention is to have several small DOs, i was expecting something like 300 (i.e 30 scripts x 10 DOs) ... I do not plan to use that number but was just my expectation.

GregBrimble•8/9/21, 10:18 PM

I think KV also started out with a 20 limit, but is now 100. Just for reference.

Kkenton Number of objects is unlimited. Number of namespaces (i.e. classes) is limited. ...

codefrau•8/9/21, 10:28 PM

How do environments affect that number? I'd think if my script has 20 different DOs I could still separate testing from production by deploying them into different environments, right?

GGreg-McKeon the current namespace limit is due to the storage limit - not much use in each D...

Wallacy•8/9/21, 10:50 PM

But the 10GB is account-wide, not for each namespace; So if we have 10/20/1000 namespaces the total limit is the same....

AAggressiveInlining Or it should be that way...

John Spurlock•8/10/21, 12:38 AM

Yea must be a wrangler thing. The http upload api uses content-type = application/javascript+module in the multipart request body

Vvwkd Thanks for clarifying. Don't we specify the entry point module in the `wrangler....

kentonOP•8/10/21, 1:09 AM

I suppose it'd be possible to assume the main module is ES syntax, but then people might be confused why their main module is allowed to be

.js

.js

but all other modules have to be

.mjs

.mjs

...

ItsWendell•8/10/21, 8:48 AM

Is it possible / wise to do fetch requests in the constructor of the Durable Object? E.g. when a durable object is (re)-created, I want to update some information (mainly the location / colo of this durable object) in our database.

IItsWendell Is it possible / wise to do fetch requests in the constructor of the Durable Obj...

GregBrimble•8/10/21, 8:49 AM

https://discord.com/channels/595317990191398933/802187271067140107/869307059466797066

Should be now, I think!

GGregBrimble https://discord.com/channels/595317990191398933/802187271067140107/8693070594667...

ItsWendell•8/10/21, 8:54 AM

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

ItsWendell•8/10/21, 10:39 AM

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

Vvwkd By other modules you mean for the same worker? Since an ES module can't import c...

kentonOP•8/10/21, 2:25 PM

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.

ItsWendell•8/10/21, 5:04 PM

Is there a in-memory limit to Durable Objects?

John Spurlock•8/10/21, 5:06 PM

hehe, there is indeed

John Spurlock•8/10/21, 5:07 PM

standard limit for workers is 128MB

John Spurlock•8/10/21, 5:08 PM

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

John Spurlock•8/10/21, 5:09 PM

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

John Spurlock•8/10/21, 5:10 PM

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

ItsWendell•8/10/21, 5:18 PM

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*

John Spurlock•8/10/21, 5:21 PM

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

ItsWendell•8/10/21, 5:22 PM

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.

John Spurlock•8/10/21, 5:23 PM

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 : )

ItsWendell•8/10/21, 5:24 PM

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.

JJohn Spurlock yes! as long as you don't get unlucky: the runtime might decide to instantiate ...

ItsWendell•8/10/21, 5:24 PM

Ah yes that's a problem.

ItsWendell•8/10/21, 5:25 PM

You'd just spawn 10 just to be sure

ItsWendell•8/10/21, 5:25 PM

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

John Spurlock•8/10/21, 5:28 PM

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

John Spurlock•8/10/21, 5:29 PM

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

John Spurlock•8/10/21, 5:32 PM

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 durable-objects

John Spurlock•8/10/21, 5:33 PM

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

Hello, I’m Allie!•8/10/21, 6:11 PM

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?

Bbrett You can get your namespaces with `https://api.cloudflare.com/client/v4/accounts/...

Hello, I’m Allie!•8/10/21, 6:43 PM

Thanks, @brett_h!

codefrau•8/10/21, 10:04 PM

The main difference (IMHO) is that a random worker will be selected to serve any specific request, but you can control which DOs that worker will talk to. That makes the DO a single global point to do stateful computations. Storage (again, IMHO) is secondary to that idea, but it makes DOs even more powerful since you get fast persistence.