Also I am trying to have an in-memory list of connected users to a Durable Object. Basically doing

this.users = {}

and as soon as a user connects I do

this.users[message.id] = webSocket

But when I have an query that tries to get those in memory users I get returned nothing, it stays empty

Do the "automatically cached"

await this.state.storage.get(key)

-operations count as billable reads?

That message was sent before this blog post was made - does it still apply?

Nevermind, these changes were made a couple of weeks before that blog post, so the answer is probably yes.

yea he had mentioned having the blog post written back when the change was deployed, but holding off on the blog post until after "impact week". Although pricing around DO is not completely nailed down yet, I'd be surprised if cached reads were not billed at the same rate. I guess we'll find out : )

I'm just asking cause I need to decide whether to store the value as a variable or just read it each time

imo variables every time - but unfortunately it's still possible to store too much (even like 12mb) so that a bunch of these instantiated into the same isolate will collectively blow the per-isolate memory limit. But that will depend on how you are accessing, how many you have at once, etc

Even more convenient night be an “ephemeral/durable hybrid” object that automatically delegates storage ops to elsewhere - trading storage latency for client latency if the colo doesn’t support DOs directly.

Wrangler only shows the log after a request has finished. For a websocket connection that can be a very long time.

Am I interpreting this correctly that it is possible a worker and a DO may be loaded into the same isolate if they are the same script, sharing the same global scope? Or put differently, every isolate loads the whole script, and then it may receive a worker fetch as well as a DO instantiation+fetch?

We use KV with itty-durable because many of our data is bigger than DO value size and also the distributed side of the KV is also nice!

So you wrap KV in itty-durable?

I just make my own midleware to handle the KV calls. Nothing fancy.

Sorry, I was misinterpreting "using KV with itty-durable" as "using itty-durable as an interface for KV". My mistake!

I read that way…. Apear to be a reasonable trade off. But the behavior should be better documented.

That can also work, you just need to override the "persist" method.

That's correct. We try not to load two copies of the same script on the same machine, unless traffic levels actually require it.

Is it possible to access the value passed to

idFromName()

from inside the Durable Object?

Nope, just the hex id. You'll need to pass it down in your

fetch

call as a parameter if you want it inside the DO

Alright, that's what I figured. Would be nice to have the option it in the future, but I don't see how it could be easily implemented :/

Yea it would be nice if it was available off of the

state

passed to the instance, but I bet the name string is just an input to a hash function and never leaves the client side.

The issue is you can do idFromName and then just use that ID in the future. We don’t store the original name anywhere. Best to make a small abstraction that passes the name along every time like you said.

Can you hard-code an id, if you don't want to regenerate it on every rerun?

I’m not sure what exactly what you mean. You could do idFromName and then store that ID somewhere, which is what I was referencing above. But you can’t just provide your own ID without going through the system

If you make an ID from a name though you could use it forever

So say for example I was using a DO as a global cache. I don't need to have more than one DO active at one time. Could I generate an id using a name, push it to the terminal, copy it down, and then hard-code it into my code?

Yeah for sure. If you were going to do that though I’d use a unique ID