One thing I find very confusing about Cloudflare Workers and WebSockets in the documentation is that it is not clear how sustaining a websocket makes sense when there are hard limits on the worker duration. After reading many pages of the docs, this is what I think the model is:

• Workers, unlike traditional FaaS, are priced by CPU Times, which is different from Wall Clock Duration.
• CPU Time is strictly when a line of code executes. Wall Clock Duration is CPU Time + time spent waiting on async calls when CPU is idle
• Because of this, 30s of CPU time (the Workers limit), typically, actually maps to significantly longer Wall Clock Duration, making duration limits a non-issue to sustain a websocket connection since each message will take ~1ms (is this the right magnitude?), giving you basically ~30,000 messages per request on the Unbound plan, but because there's a higher chance of eviction after 30s of Wall Clock Duration, in practice you'll get lower than 30,000 messsages per request.

My questions:

• The marketing page seems to contradict the docs on pricing. The landing page says 30s wall time per request, but everywhere I look in the documentation seems to suggest either 50ms of CPU time for the Bundled plan, and unlimited Wall Clock Duration for the Unbounded plan?
• What exactly is the model for eviction? Can my Worker get evicted mid execution? Can my Durable Object Worker get evicted while idle but holding a bunch of open connections? (Is that why there needs to be logic to rejoin on the client side? Because the Durable Object can get killed at any point?)
  

Hi, I see nowhere that it's called.
I assume that it's automatically called with every websocket data received. That's correct right?

I didn't read anywhere in the Durable Object docs about that. Can someone give me a link where I can read more about that behavior when exactly fetch requests (of DOs within DOs) are fetched? because in the code i don't see that it is anzwhere attached, so it happens automatically in the background. this is information i want/have to know if i want to develop something with DOs.

Next.js is the uprising React framework, it looks like a great candidate for Cloudflare Durable Objects demo because it has native Serverless support.

Would you consider building a similar demo (chat) using the Next.js framework? I'm sure it'd be a great visibility boost for this feature, and might even become the de-facto way to build real-time apps with Next.js.

Appreciate the project! One thing that would be really helpful is if this demo included a portion that demonstrated usage of standard KV storage. The normal method of using KV storage seems to not work in this project so I'm assuming workarounds need to done or is that something that will be supported laster in this new way of using workers. If this was addressed in this demo it would be helpful!

Using:
npx wrangler deploy --env staging,
then:
npx wrangler tail --format=pretty,
i cannot see the the logs in the hibernating websocket methods.
Note: webSocket.send() is working fine.
Example:

async webSocketMessage(webSocket, message){
   console.log("message received"); //<-does not show in wrangler
   webSocket.send(JSON.stringify({ echo:message, })); //<- working fine
}

however, i can see the logs if i use the old way:

webSocket.addEventListener("message", async (evt) => { 
  console.log("message received"); //<-does show in wrangler
  webSocket.send(JSON.stringify({ echo:evt.data, })); //<- working fine
});

Perhaps i am doing something wrong?

Getting this issue

 unknown field `upload_format`, expected one of `command`, `cwd`, `watch_dir`, `upload`

when executing:

wrangler publish

using @cloudflare/wrangler npm package

The following eventListener runs on the server:

The websocket is stored in the durable object:

I'm not sure what's going on. Does it just run on whatever Worker the Durable Object is currently at?

Hi !

Would it be possible for somebody from Cloudflare @kentonv @a-robinson to confirm what would be the approximate pricing for such chat demo ?

For example if we had 1000 users each send about 50-60 messages per day for a month. I am very curious how well do Durable Object scale in terms of pricing versus traditional running VM.

Thank you !

Was attempting to use wrangler 1.15 rc2 to generate the project with an m1 MacBook where I modified the wrangler compile to use use the binary supplied for cargo-generate (fix described here: cloudflare/wrangler-legacy#1813 )

I try to following:
wrangler generate myproject-app https://github.com/cloudflare/workers-chat-demo

And I get the following error:
🔧 Creating project called delivery-websocket...
Error: ⛔ Git Error: failed to find branch master
Error: tried running command:
/Users/username/.cargo/bin/cargo-generate generate --git https://github.com/cloudflare/workers-chat-demo --name delivery-websocket --force
exited with exit code: 1

Just to make it smoother for new people, would the solution be to add a master branch?

After adding my own account ID, and running wrangler publish, I get:

Error: error decoding response body: missing field `result` at line 1 column 76

Caused by:
    missing field `result` at line 1 column 76

Clever, but I believe the durable object still runs into a consistency violation if the clock does go backwards because the object does not persist lastTimeStamp

I could be wrong though, distributed systems are hard 🤯🤓

First of all, thank you of a well-documented demo! It really helped me to understand the concept of Durable Objects, which I find one of the most amazing things that the Workers platform has.

The demo and the official documentation mention that a durable object can be destroyed and then recreated again, I assume in order to migrate the object closer to the clients and to make it easier to handle deploys. This perfectly explains why there are essentially two ways of storing data: in-memory and storage. The memory acts as a cache: we can keep intermediate data in there that can be lost. In order to ensure data safety we sync that data with the storage, which will guarantee the presence of the data between the lifecycles of the object.

In the chat demo however we store a list of all current WebSocket clients in an instance variable this.sessions. And that made me wonder: what happens with these WebSocket connections when an object is destroyed? Do they get disconnected? And if they are not is there a way to persist a WebSocket object in the storage (since they aren't plain JS objects)?

i want to try this on my acc

when try to publish with command:
wrangler publish --new-class ChatRoom --new-class RateLimiter

an error message appear
error: Found argument '--new-class' which wasn't expected, or isn't valid in this context

already using lates wrangler v.1.15.0

warngler is login and config:

wrangler.toml

any insight what to do?
thanx for the help.

I recieved some advice in discord to use a ping pong to keep my connection alive. should that be added to this demo?

https://github.com/cloudflare/workers-chat-demo/blob/main/src/chat.mjs

Line 24 and 43 you reference publish.sh

I'm new to persistent objects...and have no idea what was in publish.sh is at first glance because it looks like there has been a move to no longer use that file.

What are the changes of this sample being updated and tested with latest wrangler and typescript updates.
So much has happened, and it seem that this is the only sample still referenced on the current documentation.

In code (dog) years, this is about 40 years behind the time. It would be really useful.
Unless I'm missing other examples and references?

I'd like to use miniflare so I can use breakpoints to step through the code, as I believe this isn't supported in wrangler currently. When I run:

npm run miniflare --modules --watch --debug

I get the error:

VMScriptRunnerError [ERR_MODULE_RULE]: Unable to resolve "src/chat.mjs" dependency "./chat.html": no matching module rules. If you're trying to import an npm package, you'll need to bundle your Worker first.

Commenting out lines 62 and 104 in chat.mjs prevents the error but means no web client is available. Does anyone know a workaround for this issue, or a related ticket?