I would like one in Sydney. Southern Australia is a ways away from Singapore and I have customers in Australia (English as a first language) but none in SE Asia (English as a second language) Having at least one Durable Object pop on each populated continent would be nice.

I was hoping for some updates to Durable Objects announced this week. Have all the announcements been posted now? Is there anything for DOs that I missed?

Are there any restrictions accessing R2 buckets in a DO? I’m not sure if I’m doing something wrong, but I’m not seeing the names I’ve bound my buckets to (in wrangler.toml) as properties on the env object passed to the DO constructor. Thanks!

Just to confirm, are you checking the env properties at runtime (eg. console.log)?

this blog here says the changes made do not affect durable objects

are there still changes planned for DO pricing? (nothing was announced this week as it turns out 😦 maybe sometime soon though )

https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#durable-object-lifespan > A Durable Object remains active until all asynchronous I/O, including Promises, within the Durable Object has resolved. This is true for all HTTP and/or WebSocket connections, except for failure scenarios, which may include unhandled runtime exceptions or exceeding the CPU limit. I'm relaying a websocket traffics between two clients with DO, and as Rust

workers-rs

wrapper provides, the most idiomatic use case to receive a WS message seems doing

ws.events()?.next()

, then drop the

EventStream

created by

.events()

. Strangely after the first receiving the DO does not relay the message and the next

.next()

call hangs forever. Clients observes ECONNRESET, so something would be wrong. I'm guessing the DO is dropped because the last event listener is dropped after the first receiving, so DO is too. Can anyone kindly check my hypothesis and give any clue to workaround this issue? It seems like

Pin

should be introduced because

EventStream

struct has a lifetime tied to the

WebSocket

struct so we cannot hold them in a single struct, effectively creating a self-referential struct...

Yes

If you are using multiple environments in your toml, you might want to double check the bindings. [1] It will be easier if you can post a snippet of your toml here. Also I would double check if the worker script implementing your DO can also access R2 in its env - to narrow it down to being a DO specific quirk. 1: https://developers.cloudflare.com/workers/learning/using-durable-objects/#configuring-durable-object-bindings

No issues with my DO bindings, they work correctly and I can see them in the env (logged to console as JSON to avoid the truncation issue i.e. the "..."). That env object (passed to the DO constructor0 contains environment variables, secrets, do bindings, but no R2 bindings, here's what I've got in my toml file:

r2_buckets  = [
  { binding = "projectR2", bucket_name = "xxx-p-prod", preview_bucket_name = "xxx-p-dev"},
  { binding = "usersR2", bucket_name = "xxx-u-prod", preview_bucket_name = "xxx-u-dev"}
]

This is not DO specific, I also see it in a regular worker, I'll troubleshoot my wrangler.toml file, FYI, I'm having a hard time finding an example of a wrangler.toml that's multi-environment with R2 bindings, if anyone has one they can share, that would be greatly appreciated.

toml
[[env.foo.r2_buckets]]
binding = "foo"
bucket_name = "foo"

toml
env.foo.r2_buckets = [
  { binding = "foo", bucket_name = "foo" }
]

toml
[env.foo]
r2_buckets = [
  { binding = "foo", bucket_name = "foo" }
]

Thanks so much!

I suspected it had to do with the environments glad you got it sorted 🥳

Hello, I recently discovered that Workers supported WebSockets through DOs. I need to build a real-time chat application. I'm just not sure to understand the pricing... are workers better/cheaper for that task than Pusher or AWS AppSync for example?

It depends

Ok... but how 😅

How many chat rooms you have, how long each person is connected, how many rooms each person connects to, how many messages get sent

Ok, let's say I have about 10k users, with on average 3 chat rooms per user of ~5 people and they send ~200 messages per month

If I decide to use workers, would that be stupid or could it actually be a good alternative to a more traditional cloud architecture?

Using workers is fine as with anything you just have to keep in mind its limits. For workers you can only have a few hundred sockets connected to a single object before you start getting errors and you need to build some system on top of DO to load balance connections. AppSync and Pusher both handle the connections for you so you dont have to worry about them in any way pretty much. As far as pricing: Durable objects: Duration charges: $0.0016/million ms (multiple sockets connected to the same object share a duration charge) Per message charge: $0.15 / million (only messages inbound not outbound - pretty sure at least might need to double check) Storage charges: $1.00 / million writes (metered at 4KB per write). $0.20 / million reads (metered at 4KB per read). AppSync: Duration charges: $0.08/million minutes Per message charge: ($4.00 per million mutations) + $2.00 / million socket messages sent to users Storage charges: depends on the database you use Pusher: Something / month flat + whatever storage you use + whatever server you use that does storage ops + pusher messages

Ok, so DOs' pricing actually isn't as bad as I thought... thanks for your answer, very helpful!

Basically with DO if you have a lot of different chat rooms that people are connected to with a low volume of messages DO is outrageously expensive compared to appsync. But at lower number of chat rooms and higher volume of messages DO is better priced but may fall flat earlier given DOs are single threaded and you would have to build some sort of system on top to group many DOs as one room and communicate messages between all of them.

Ok, that is a good point to take into consideration

I feel that CloudFlare made their worker offer more complicated with KV and DOs rather than having a Redis like solution for both

KV is basically a simpler Redis, while DOs are atomic, which you can’t as easily achieve with Redis

As an example lets say your chat rooms was just direct messaging. (2 users per room basically). If there are 100 total DM threads where both users are connected 24/7 and send messages at a rate of 1 per second (86,400 messages per day) Daily duration charges: DO = 86.4 million ms per day * 100 active objects = 8640 million ms = $13.824 AppSync = 1440 minutes per day * 200 active connections = 288000 minutes = $0.02 Daily message charges (excluding storage & data transfer): DO = 86400 messages = $0.01296 AppSync = 86400 data modifications + 172800 real time updates = $0.3456 + $0.3456 = $0.6912 Total: DO = $13.83696 AppSync = $0.7112

Plus, DOs are also compute

Ok @Unsmart | Tech debt but I won't have DMs, my app is more group based, with group size being between 5 and 10 people on average. You said that multiple sockets aren't charged, right? So the same pricing apply?