anyway since I'm here to research usability of cloud for multiplayer games, and have next to no knowledge of cloud best practices, here's my next question. Is there anything stopping me and any reason why it would be a bad idea, to throw the equivalent of a game loop for a very simple game on a durable object?

I for one wouldn't stop you. but recently CF released Doom with working multiplayer powered by Durable Objects, so...

from what I understand, the durable objects for that have nothing to do with the game logic, just communication?

Is it possible to call other functions of a Durable Object, not only fetch?

from my understanding, that is what stubs are for

I also thought so, but it seems I'm unable to call any functions except fetch

huh, weird. I mean, there's ways to work arround it if it's really true, but it seems a bit counterintuitive

yeah, at present, fetch() is the only form of communication implemented. We'd like to add more general RPC at some point.

There's a pretty massive difference in hello world code size for the various compile to js languages on https://developers.cloudflare.com/workers/platform/languages#compiled-to-javascript you can try out the templates to see for yourself. As matt mentioned, bucklescript/reasonml/reasonscript/whatever-theyre-calling-it-this-week is the best I'm aware of, it's actually smaller than handwritten js in a lot of cases. If you just want a good type system that compiles to JS and don't care about anything else, that's what I'd look at. If you care about a more stable language ecosystem, f#/fable is a close second in terms of generated code. Scala and Kotlin have a good ecosystem, but generated code is a lot bigger. Purescript I don't have any experience with but might be another option. Anything else on that list of languages I'd stay away from unless you're a big fan of that particular language

That's pretty unfortunate, means that we'd have to serialize/deserialize the content manually via the fetch function

Is there any timeline on RPC?

One of the folks in here was working on https://github.com/kwhitley/itty-durable as a way to have on a more RPC like interface on top of

fetch()

using ES6 proxies.

It’s not in our near term roadmap

Can a single durable object handle thousands of concurrent websockets? I'm looking at migrating a web game that shares a consistent state over websockets with thousands of players

I have a co-worker in Vancouver, Canada. Their colo is

SEA

according to /cdn-cgi/trace. Yet, when they access my script, the worker is running in

LAX

. And the Durable Object is also being created in

LAX

. Tried a few more locations via VPN: * user: Vancouver, Canada. Colo:

SEA

. Worker:

LAX

. DO:

LAX

. 🤔 * user: Frankfurt, Germany. Colo:

FRA

. Worker:

FRA

. DO:

FRA

. 🤗 * user: Sydney, Australia. Colo:

SYD

. Worker:

SYD

. DO:

SIN

. 🙃 * user: Tokyo, Japan. Colo:

KIX

. Worker:

SJC

. DO:

SJC

. 😬 We do have clients in Japan so I'm curious why the worker would not be in Asia, at least? Is the connection from Japan to

SIN

slower than to the US?

Does anyone know what this error means? ``# could not be cloned.``

https://developers.cloudflare.com/workers/learning/using-durable-objects#limitations says "Not all Cloudflare locations support Durable Objects yet, so objects may not be created in exactly the same point-of-presence where they are first requested." :/

I assume it's the same story with workers

Weird that Tokyo is going to San Jose and not Singapore.

We have a few users looking into this. Define "very simple" 🙂

This depends in part on the routing associated with the zone. What zone is this?

This isn't the case for Workers, they are supported in every PoP.

How would I know the zone?

Your limits here are the 128 MB limit and the fact that Durable Objects are single-threaded, so it depends on how active these WebSockets are.

Where are you deploying to? workers.dev?

Yes

Are you sure there is no limit per DO? Won’t the VM run out of sockets?

Just clarifying - for Workers, routing depends (somewhat) on the plan associated with your Cloudflare zone. Since workers.dev are free zones, they don't route to every colo. Durable Objects instantiate your Object near the colo your worker is running in. So, for the Tokyo example, the free tier routing is sending the traffic to SJC, where the Worker is run. When it calls DO, the nearest PoP with DO is SJC, so the DO runs there. This goes away if you upgrade the zone to the pro plan or above.

nope, there's no socket limit.

Wow. Then that's better than any single linux server. Impressive.