Is this documented already somewhere?
Is this documented already somewhere?
WBrett can PM you the link, i dont know if i can share the same info. But im using the rest api to get list of DO objects, works well but is not "very fast"... depending of your requirements maybe just be simple to make you own list.
WThis same concept is also part of the nodejs module resolution. Thats nor pretty but i cant call that a antipattern considering the is very common and is the default resolution from the biggest js runtime out there. Anyway, you can just rename the output as part of your build step. Personally, im using the ESBuild bundle, so i just ask to output a .mjs file, but i can understand that other bundlers may need a rename. Anyway, i do think that request can be made on the wrangler github issues section, appear to be a simple adjustment.
KWe need to distinguish between the types somehow. The HTTP upload API allows each module's content-type to be specified explicitly. But, Wrangler needs some way to know what type each file is. For now, it uses the file extension to figure it out. However, you're welcome to propose a change to Wrangler that lets it figure out the file type some other way.
WI just got: workers.api.error.max_durable_object_namespaces_exceeded [API code: 10067]
WWhat is the limit?
WOps... Okay!
WThats will increase in the future right? I setup a 3 stage test system. And the script has 8 DO ... so i need will reduce on only basic two step (prod/dev) until that, also, i need to avoid the creating more than 2 new DOs xD
CAren't you using 3 wrangler environments?
WMy wrangler.toml is dynamic generate as part of my deploy script. I assumed the effect was be the same.
JWhoa 20? quite a bit less than unlimited : )
CI'd assume you get 20 namespaces per environment
KNumber 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.
WWhen 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.
WI 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.
GI think KV also started out with a 20 limit, but is now 100. Just for reference.
CHow 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?
WBut the 10GB is account-wide, not for each namespace; So if we have 10/20/1000 namespaces the total limit is the same....
JYea must be a wrangler thing. The http upload api uses content-type = application/javascript+module in the multipart request body
KI 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
IIs 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.
IOh awesome! I should follow these community posts more closely!
IIs 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 
KES 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.
IIs there a in-memory limit to Durable Objects?
Jhehe, there is indeed
Jstandard limit for workers is 128MB
Jhowever, more than one instance of your DO may instantiated in the same isolate - in this case, they all compete for the same 128MB
Jin practice, you shouldn't have to think about it, especially if you keep your state small and mostly just make calls
Jbut 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
IAh 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*
Edit: Should have been horizontally*
Jyea, 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
II 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.
Jyes! 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 : )
IE.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.
IAh yes that's a problem.
IYou'd just spawn 10 just to be sure