For example, a "room" DO with a list of users might want to include their names, profile pic, etc. so you don't have to query each user's DO for that info, while each "user" DO might have additional info such as private docs they've created and only they need to access.

Thanks @lux that makes sense I am thinking along with field like name I can have a list of subscribers that get called on name being updated. on DO I can have a hook route that gets called to update names and unsubscribes if the name is no longer of interest. Writes are expensive but infrequent.

Just read the latest announcement. Is queueMicrotask() available on DOs?

Ya

Seeing elevated "Error: internal error" calling DOs this morning, even after retries - known issue?

Sweet! I'm guessing anything in queueMicrotask() still has to adhere to the CPU limits, but could essentially let you run a "background" task without blocking like await does. Is that about right?

Looking into it

Hmm, you can already make a promise and not await it if you want to run something without blocking.

queueMicrotask

is best described here: https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask

Good to know! I guess I'm thinking of it more like "keep executing linearly but process X later" whereas wouldn't a promise start working on X immediately whether you await it or not? I'm not as well-versed in these things in JS as lower-level languages 🙂

You could, for example, do a

fetch

to some website but not await it, and store the promise somewhere. It would begin the subrequest immediately, and you could go do other work and maybe

await

or

.then()

that promise at some future time, like after you finished handling some user's request.

Makes sense. I was thinking about some logic that the current request doesn't care to know if it finished, which it sounds like both ways solve that. If the background work didn't count towards hitting the per-isolate CPU limits, that would be even better... 😉 Anyway, thanks for the info!

Should be all good now, there was some instability in one of our colos caused by resource issues on a few machines. Let me or Brett know if you still see errors

Will do, thanks - haven't seen it fail enough times to escape retry logic in the last hour or so

Would it be realistic to use DO’s if you had 1m monthly active users each mapping to a single DO? They’d be calling it maybe 10 times a day. How much would that cost?

I heard a continuously open DO is $4/mo

Estimated

Not sure how that maps tho

Our most recent billing info is here: https://blog.cloudflare.com/durable-objects-open-beta/ If these are brief request/response REST calls I think it'd be really affordable (I didn't do any napkin math), we charge for the duration you keep an object active/live in memory to service some request, but it sounds like you're talking about milliseconds per user here? (1m users holding websockets open would be a different story)

Yeah brief requests

Okay gotta check that out and calculate

Another question: how hard is it to pull data out of DO persistent storage at scale

Yeah it would be great to get some clarity on the pricing. My goal is to replace a NodeJS server + Socket.IO with DO, especially if the pricing will be set right.

Like would it cost me more to host a NodeJS server with multiple game rooms running for a month vs. maybe having 3-5 active DOs running in parallel for a month.

Wondering about the overhead/impact of active tail sessions on production DOs. If I had a tail session running 24/7, would cloudflare folks cringe? Is it something that changes the CPU/IO/memory characteristics of the isolate enough to be unadvisable outside of targeted debugging sessions?

I am planning to play around with Durable objects and workers kv, anyone have a good getting started ideas/plan ?

Hello! I am curious about the E-order semantics implemented by object stubs. Given that all calls to the same stub will be delivered to the object in the order in which they were made, and that in the event of a network partition/outage/error, the stub will be permanently disconnected and all in-flight and future calls will fail on that stub, what if I had something like:

const a = stub.fetch("http://url.com")
const b = stub.fetch("http://url.com")
const results = await Promise.all([a, b])

My questions are: 1 ) Can I assume that in the above scenario, `a`'s call will be received by the DO strictly after `b`'s call, barring any network issues? 2 ) If

a

were to error out due to network issue, is it guaranteed that

b

will cancel? 3 ) What about the other way around? If

b

errors out due to network, can we assume that

a

will be unaffected given that `b`'s call is after `a`'s? I'm just trying to make sense of the guarantees offered by E-order in the context of Javascript's async mechanisms, both of which I feel I may have some knowledge gaps in haha Any help would be greatly appreciated!

1.) a will be sent before b, so a will be received before b 2.) yes 3.) no — returning the result to a has to go over the network, so if b has failed then there’s no way that we could transmit the answer to a if a hasn’t completed yet

What are the advantages of using cache within a DO if you expect a DO to only be needed in a single colo. Is it mainly to avoid the potential cold start?

In this particular example, the DO just returns a value from persistent storage

Great, thanks!