Not only it allows me to prototype for cheap, it actually allows cost to grow along with the userbase. Compared to something like: https://github.com/HumbleNet/humblenet
How is the communication between workers handled? Their blog post about websocket support only advertised the possibility persist state via their key/value store, but here the workers handling different clients need to communicate with each other in real time. How is this done?
edit: Their "Router" class is a "Durable Object". There is no trace of this in their code, this is configured separately when creating the worker. A durable object is a durable JavaScript object, unrelated to K/V storage; it seems to essentially be a class whose instances act like service workers and can respond to requests using their persistent state. I guess there is special support for WebSocket endpoints in their Durable Object system so that a WebSocket endpoint can be sent to/from the Durable Object.
Their docs are really not optimal, with many different iterations of the syntax mixed together (e.g. some thing only work with the "Module syntax" but every single example is written with the "addEventListener syntax").
> some thing only work with the "Module syntax" but every single example is written with the "addEventListener syntax"
The new modules syntax is still beta -- it'll eventually be the official recommendation for all Workers, but we're not there yet. But it is indeed required for Durable Objects, which is also beta, because we didn't want to come up with an old-style syntax for Durable Objects that would just be deprecated immediately anyway. It does unfortunately leave things in a confusing state at the moment, but it should get better soon.
In short: the vendor (Cloudflare) handles it, not you. Cloudflare has to quickly disseminate a lot of things to their data centers all the time (new files, routing rules, cache invalidations, etc.) and Durable Objects piggybacks on that same infrastructure.
From the client's point of view, all the network I/O is to a "centralized" server and not peer-to-peer, except in this case the "centralized" endpoint is actually a cluster of data centers that all talk to each other behind the scenes.
Client --> nearest Cloudflare node --> all the other nodes via their phat pipes, not yours
Imagine an entire decentralized gaming platform like this powered by WASM/WebGPU, with support for Unity/Unreal titles to run in HTML5. This will disrupt all of the native stores like Steam, EGS, as well as the mobile app stores. No 30% cut, and instant distribution to end users without a middleman. WebAssembly gaming is truly the future.
Wouldn't it be better to use WebRTC data channels for communication between instances of the game? If I'm not mistaken, that's even based on UDP. Of course, that wouldn't show off the new Cloudflare features nearly as much, though I guess Workers and Durable Objects could still be used to help the clients establish the WebRTC connection.
For Doom specifically, which uses a P2P networking model, yes, that probably would have been technically superior. It would have taken more work, though -- this demo was thrown together pretty fast. Durable Objects could still have been used for setup, yes.
Most modern games use a client/server model, in which case the possible role of Durable Objects is a lot clearer.
10 comments
[ 2.6 ms ] story [ 33.5 ms ] threadQuake 3 networking is much more efficient and would definitely shine here. For the curious:
https://web.archive.org/web/20190316154729/trac.bookofhook.c...
https://fabiensanglard.net/quake3/network.php
Not only it allows me to prototype for cheap, it actually allows cost to grow along with the userbase. Compared to something like: https://github.com/HumbleNet/humblenet
edit: Their "Router" class is a "Durable Object". There is no trace of this in their code, this is configured separately when creating the worker. A durable object is a durable JavaScript object, unrelated to K/V storage; it seems to essentially be a class whose instances act like service workers and can respond to requests using their persistent state. I guess there is special support for WebSocket endpoints in their Durable Object system so that a WebSocket endpoint can be sent to/from the Durable Object.
Their docs are really not optimal, with many different iterations of the syntax mixed together (e.g. some thing only work with the "Module syntax" but every single example is written with the "addEventListener syntax").
It has since gone into open beta.
> some thing only work with the "Module syntax" but every single example is written with the "addEventListener syntax"
The new modules syntax is still beta -- it'll eventually be the official recommendation for all Workers, but we're not there yet. But it is indeed required for Durable Objects, which is also beta, because we didn't want to come up with an old-style syntax for Durable Objects that would just be deprecated immediately anyway. It does unfortunately leave things in a confusing state at the moment, but it should get better soon.
From the client's point of view, all the network I/O is to a "centralized" server and not peer-to-peer, except in this case the "centralized" endpoint is actually a cluster of data centers that all talk to each other behind the scenes.
Client --> nearest Cloudflare node --> all the other nodes via their phat pipes, not yours
Edit: their global stateful serverless chatroom demo more clearly demonstrates how it works: https://github.com/cloudflare/workers-chat-demo
Most modern games use a client/server model, in which case the possible role of Durable Objects is a lot clearer.
I wish they had included a detailed costs breakdown, as it seems like it might cost too much to be viable.