As far as I'm aware, 5 request units

request units?

oh

write request units

I see

that's not too bad actually

well

actually wouldn't that mean it's cheaper to store it as an array and just use one value?

Yes - one write. You can also track whether you are making changes to the any values in a non persisted key so that you only write when changes are made

One of my projects stored everything in 4 keys - each one was an js object about something. It was then serialised and written, if it was too big and exception was thrown and then it was split across multiple keys. The plus side was few keys, the downside was that if you made a small change to an attribute, it would cause all of the different chunks for that key to be written. It's swings and roundabouts as to which works better for your environment.

correct, just found this today

I would still do my own bindings so they can't directly access storage and such but I will play with that, praying it works!

👍 I think WASM is fully isolated & if you clear global variables they should have no access to bindings either

not sure but I think it should be possible

Yeah I think that should be perfect!

will play with it later

Am wondering if I can connect to D1 from durable object? How I would access the D1 binding in DO? Am trying to achieve the scenario described below. https://community.cloudflare.com/t/d1-bindings-in-durable-objects/448646 asked same question, but it was not yet answered. Thanks!

async alarm() {
  this.broadcast(this.getDataFromD1())
  this.storage.setAlarm(Date.now() + 3 * MSECONDS)
}

let id = OBJECT_NAMESPACE.newUniqueId();

-> in durable objects, this unique ID, is it unique per account or across cloudflare?

It will generate a unique ID that can only be used in that namespace. If another namespace tries to use it, it will throw an error. It should also be globally unique since it's 256 bits of obfuscated data.

Hmm, DOs are pretty normal workers, I think you'd configure the D1 binding on that Worker in Wrangler the same way you would any other.

D1 has a shim added into the fetch/etc handlers by Wrangler which isn't done in the Durable Object class

It's a weird one - but you can DIY it https://discord.com/channels/595317990191398933/992060581832032316/1059778299435425902

Ah sorry, have never used it myself.

Hi! Do you have any updates about Durable Objects instances in South America? I'm building something for Brazilian users, and the latency might be an issue 🫤.

So for sockets with a DO (from a Worker). As long as a requesting party (e.g. browser) sends a GET/upgrade request to the Worker, does it matter what headers/method is sent to the DO as long as it responds with a socket client (and the Worker responds appropriately)? As in, does the DO actually care about any of the normal socket requesting protocols, since it's only a middle layer?

Just access it off the

env

accessible to fetch requests within the DO.

doesn't look like it, Buenos Aires DOs spawn in ATL/MIA/EWR... https://where.durableobjects.live/

Btw, The counter is broken, but it should still be updating regularly

I am building a game that allows multiple users (1-10) to talk to each other. I used Durable Objects that respond to web socket requests routed through a Cloudflare worker. I got to deploy the project today (yay!), but when I checked the billing section, I saw that I had already amassed 400 GB-s. After reading into it, it sounds like every second of connection is billed (not just when data is being sent or processed) instead of computation time when things are happening. Is this correct? Is there any way I can restructure my architecture to use less time (aside from polling)?