Note that because Durable Objects are long running computations, they are stateful and deployments are disruptive (clients disconnected). So even though you could potentially put them in the "serverless" category, the deployment experience isn't quite the same as short-lived serverless functions / lambdas.
The real novelty of Durable Objects appears to be their intended usage of fine granularity (and the underlying tech that enables this). For example, if you were building a chat room service, you could have 1 Durable Object per room. Of course, you could conceivably build a chat room service running 1 Node.js process per chat room on traditional VMs or containers, but that probably wouldn't scale well.
With the Workers Bundled plan (https://developers.cloudflare.com/workers/platform/pricing#b...), your WebSocket connection will stay open until your 50ms of CPU time expires. On Unbound (https://blog.cloudflare.com/introducing-workers-unbound/), which does not have a CPU time limit, your WebSocket connection will stay alive as long as it remains active and your Worker doesn't exceed its memory limits. If the connection goes idle, it may be terminated. We're currently considering an idle timeout on the order of 1-10 minutes.
Workers handle WebSockets in a pretty straightforward way. The server-side API is literally the same WebSocket JavaScript API as in browsers. sock.addEventListener("message", callback), etc.
But if you aren't using Durable Objects, then WebSockets on Workers aren't particularly useful, because there's no way to contact the specific Worker instance that is handling a particular client's WebSocket session, in order to send a message down.
Durable Objects fixes exactly that. Now you can have worker instances that are named, so you can call back to them.
Here's a complete demo that uses WebSockets to implement chat: https://github.com/cloudflare/workers-chat-demo/blob/main/ch...
> Are they automatically terminated after the worker spends too much time active?
We're still tweaking timeouts and limits, but in general you should be able to keep a WebSocket alive long-term, and reconnect any time it drops (which any WebSocket application has to do anyway, the internet being unreliable).
> If so, doesn’t handling the WS handshake have a lot more overhead than a fetch call?
Not sure what you mean here. A WS handshake in itself isn't terribly expensive. I suppose a typical application will have to establish some state after the socket opens, and that could be expensive, but it depends on the app.
According to [0], they will - obviously - charge for both compute-time and storage operations, and with the price of storage operations expected to be around Workers KV. Assuming that compute-time is charged at minimum at-or-higher than Workers Unbound, using workers for chat-rooms and other WebSocket stuff would be unfeasible. Workers Unbound costs $12.50 per MM-GB-sec - given that the server is 128 MB (the current fixed memory size) - the price per-worker-second would be at least $0.0000016 per connected-worker. It could get expensive fast.
Also with paid Workers and no stop loss what happens if someone decide to ddos your app? I searched for this and come away with no clear answers.
Also wondering where will Worker KV fit in? From what I gather Durable Objects are strictly superior if pricing will be comparable.
Note that you could build KV on top of Durable Objects, by implementing your own caching and replication in application logic running in Durable Objects. On the other hand, you can't implement Durable Objects on top of KV; once you've lost strong consistency, it's hard (impossible?) to get it back. So in that sense, Durable Objects are "strictly superior". But in a practical sense, you probably don't really want to do the work to implement your own KV store on top of Durable Objects; it's probably better to just use KV.
KV is eventually consistent, appropriate for low-value data that is read a lot , written infrequently... Durable Objects will provide consistency, at the cost of not having the very low latency of KV because it has to run in a single location instead of on the edges. So there seems to be room for both solutions.
About DDOS, I believe Cloudfare is a leader in ddos-protection, so I would hope they include protection in all their Workers (pls someone correct me if I'm wrong).
[1] https://blog.cloudflare.com/cloudflare-workers-now-support-c...
[1] - https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
[2] - https://blog.cloudflare.com/cloudflare-worker-with-webassemb...
Edit:
(If someone from CF has questions, you can reach me at hn@elasticwaffle.com)
My use case is pretty much exactly the one described in the blog post (over on CF) for multiplayer games. Using DO for ongoing 1v1 matches in a trading-card-game style turn-by-turn strategy game. Players would play against a simple AI (which itself is a worker) or other players. The game is served from Workers Static Sites. But multiplayer required stronger coordination and the delay from KV writes to reach all PoPs is a deal-breaker. DO solve not only that, but the interface (just being classes) allows the game design to melt with the backend design.
We are taking things slowly. Storing data is a big responsibility. We'll need to test with a small number of users for an extended period (a few months) to work out any reliability issues before we really scale up.
Obviously Cloudflare is also a big user of Workers in production as well.
It works very well and their CLI tool Wrangler is easy to integrate into CI/CD. We’ll probably use it for more. Happy to answer questions people have: matt@happycog.com
From our Q3 earnings call:
"Turning to Cloudflare Workers, it's incredibly exciting to see how the platform is taking off. In Q3, more than 27,000 developers wrote and deployed their first Cloudflare Workers. That's up from 15,000 a year ago. History proves with new computing platforms, the more developers they have, the more quickly they improved and the more likely they are to win. Looking at GitHub and other sources of data on developer engagement, we believe more developers right deploy real applications and code on Cloudflare Workers every month than every other edge computing platforms combined. So what are they building?
- One of the most viewed publications during the 2020 elections used Cloudflare Workers to power their elections news platform and ensure it scaled during the unprecedented spike in traffic last Tuesday as well as Wednesday and today.
- A popular health foods company uses Workers to power their online ordering system.
- An online marketing firm working with major brands uses Workers to customize content on a per visitor basis.
- A publicly traded electronics testing firm use Workers to bridge their on-premise and cloud-based infrastructure.
- An innovative start-up is using Workers to power an online crypto scavenger hunt.
- And one of the largest online learning platforms uses Workers to deliver their customized content during this time of skyrocketing demand.
It's great to see more use cases every quarter, but I think we're just scratching the service. Most use cases today have focused on performance. Over time, I expect those use cases will pale in comparison to what is a much bigger opportunity, helping customers manage the challenges of compliance. As governments around the world increasingly insist on data localization and data regency, sending all your users' data back to AWS feeds for processing will become unacceptable. What our largest, most sophisticated, most compliant sensitive customers are looking to Workers for is as a way to manage this increasingly complex regulatory environment. That's why during Cloudflare's Birthday Week, our announcement of Durable Objects may have been one of the most important edge computing developments you may have missed. Durable Objects allows developers to define a data structure and store it safely on our network close to users that need to access it in order to ensure performance and consistency. It also allows developers to define where that data can move across our network and where it cannot, such as this user's data may never leave the EU or this user's data may never leave Brazil.
Given Cloudflare's network spans more than 200 cities in more than 100 countries worldwide, Durable Objects provides fine-grained control over where data is stored and processed. That functionality is critical for the increasingly complex compliance challenges that face every global company today. In other words, the future of edge computing will be defined as much by intelligent edge storage as it is by computing. And while others are still working to launch for edge computing platforms, we have products like Durable Object in market that are defining that future today."
> Given Cloudflare's network spans more than 200 cities in more than 100 countries worldwide...
I think, only the enterprise customers can truly claim benefit of all 200 PoPs. Free/Pro/Business(?) plans aren't necessarily routed to all 200. If that's not the case, then it doesn't match our interaction with Cloudflare's support.
---
That said, I absolutely love Workers. It is quite easily the best value for money of any edge computing platform. This blog post drives those arguments home: https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
[0] On the flip side, because of CNAME Flattening, it is hard to block privacy eroding solutions such as these: https://www.cloudflare.com/apps/google-analytics
A CP system cannot be available in both partitions, since by definition the two partitions cannot communicate (otherwise they wouldn't be partitions) and thus it's logically impossible for two clients in two different partitions to affect a shared state consistently. Thus at least in one partition the service will be unavailable.
Forcing all state changes go through a single "master^Wmain" node (for some key/shared) is a simple way to achieve CP.
This main node can change over time, but in case if a partition it can never move to side of the partition which has no quorum for a master election.
Wondering if you've also tried the newer real-time sync services like replicache.dev or roomservice.dev for this usecase? since it seems to do the same thing except client-side. also on server-side curious if you've evaluated Temporal.io
Is there any sort of run it locally for testing story yet? In theory paid localstack supports websocket API gateways on the AWS side, though I haven’t played with that yet either so not sure how good it is. Looking at the API being used and the fact it’s all dynamic JS land, it looks like maybe you could inject some implementations in to run the websockets and store some state locally?
