Ah np.

KV is eventually consistent, meaning that if I write a value from a Worker in New York, it may not show up in Hyderabad for another minute or so(depending on latency). DO uses a single isolate, and a single storage instance, so latency will be higher, but there will never be a conflict in whether a variable exists or has changed.

miniflare is best for now, but FWIW I'm actively working on

wrangler dev

support.

Miniflare dev merge confirmed?

No, what I'm working on is extending

wrangler dev

to be able to support durable objects using the real edge stack, just as

wrangler dev

has always worked.

@User why did you pick Supabase for storage? it's not that I'm not super hyped with SB, but given Miniflare does already handle redis, I guess upstash would have been more straightforward?

Oh, I mainly wanted to try Supabase, and the idea of hosted miniflare just came up as a challenge. The workers.run is nothing I plan to maintain and run for public audience 🙂 I actually use redis as the persistent storage there, Supabase is for user auth/scripts storage.

It's an amazing piece of work dude

To me as a programmer, the best explanation of Durable Object is that it's basically an instance of a class that runs in the cloud, which can maintain WS connections and state. So you could write some game logic there and more! Just as if you were to start a server and create an instance of a Server class that keeps track of connections and other related state.

It's just an instance of a JavaScript class with access to a persistent storage API, that only exists in one location at a time.

at least that's what I'm telling myself so I hope it's correct 😛

Yeah that's a pretty good defintion 🙂

Additionally, those class instances can communicate with each other as well

🔥

Which is actually my next experiment. N number of room DOs that communicate with a single Lobby DO to maintain user count in rooms.

Can a DO call methods on another DO's class methods? E.g. let userCount = await roomStub.getUserCount();

Or do you need to call the fetch method

Like a regular worker, you entry point will be always the fetch event. You can encapsulate that behaviour using itty-durable or you custom handler.

Ok thanks

A DO has the id of itself under state.id, but is it possible to get the string the ID was created from?

Or would I need to pass the name of the DO object via fetch from the worker

You'll need to pass the name of the DO object via fetch @User

Yeah I ended up doing that, thanks

Actually thinking about using KV for storing details about each instance, AFAIK KV should be accessible within DOs?

Yeah looks like it based on the docs

Yup. Absolutely no problem.

Hmm. KV might not be ideal if two players on the opposite side of the globe want to play in the same room. Player 1 creates the room and the room details get stored in KV. Player 2 attempts to join the room, but the KV may take up to 60 seconds to sync with every other location in the world, so player 2 can't join.

Oh no.. it is not a sync every minute. If a value is returned it is saved for at least a minute. But if the key is new, it will check central storage straight away.

Mmmm.. so that only applies to changes?

If I’m working on something using durable objects, how can i publish updates to my class to cloudflare? Currently it seems that wrangler publish is not enough.