[kentonv]

The engine is open source: https://github.com/cloudflare/workerd

We did not create our own engine to create "lock-in". On the contrary, it would be a huge win for us if we could simply run FastCGI or Node or whatever applications unmodified. We'd be able to onboard a lot more customers more quickly that way! Our product is our physical network (with hundreds of locations around the world), not our specific development environment.

But none of that tech scales well enough that we could run every app in every one of our locations at an affordable price. Meeting that goal required new tech. The best we could do is base it on open standard APIs (browser APIs, mostly), so a lot of code designed for browsers ports over nicely.

(I'm the lead engineer for Workers. These were my design choices, originally.)

[9dev]

Hey, just wanted to leave this here. It’s pure joy to work with Pages. I recently did a new homepage for my mom‘s beauty salon and decided to use CF Pages, with a few functions for booking requests and a contact form. It felt just… right. Everything fell into place as I would have liked it to. Hits the sweet spot between flexibility and pragmatism, in a way.

Enjoy your week! :)

[spiffytech]

Are there guides for application architecture with Workers?

I'm interested in Durable Objects but I don't know how to work within the 50-subrequest limit on the Free or Bundled plans.

It sounds like I can only read from 50 Durable Objects or KV queries in a single request. If my usage pattern is e.g., sharing docs with many users, how would I let more than 50 users access a doc?

Whether I consider fanning out on writes or fanning in on reads I'd need more than 50 subrequests. How should I approach this?

[kentonv]

Hmm, I think there are several different reasons why the subrequest limit actually doesn't apply to your scenario.

First, Durable Objects and Workers KV requests do not count against the 50-subrequest limit. It's HTTP requests to external servers that count.

Second, with the Unbound billing model, the limit is now 1000. The old "Bundled" billing model is really intended for "configure your CDN" use cases where you're mostly just rewriting a request or response and proxying to origin. For whole applications you should use Unbound. (Note that with Durable Objects, the objects themselves always use the Unbound pricing model.)

Third, to address your specific scenario:

> If my usage pattern is e.g., sharing docs with many users, how would I let more than 50 users access a doc?

If you mean you have 50+ users connected via WebSockets and you need to send a message to each one -- these messages (on already-open WebSockets) do not count against the subrequest limit. Only starting a whole new HTTP request or new WebSocket would count.

And for "fan in", these would be incoming requests from client, but the subrequest limit applies to outgoing request. There's no limit on number of incoming requests.

[spiffytech]

> First, Durable Objects and Workers KV requests do not count against the 50-subrequest limit. It's HTTP requests to external servers that count.

Ahhh, somehow I got the idea that requests from a Worker to Durable Objects and KV counted against subrequests. This changes things!

> If you mean you have 50+ users connected via WebSockets and you need to send a message to each one

I was thinking of, a client requests "give me a list of my documents" or "share this document with Alice, Bob, et al.", and the Worker that receives that request has to handle that somehow. I thought that was tough to do in 50 subrequests, but it's easy if I can just make an unbounded number requests to different Durable Objects or KV records.

Edit: I found what gave me the idea about subrequests. From the Workers docs:

> For subrequests to internal services like Workers KV and Durable Objects, the subrequest limit is 1000 per request, regardless of usage model.

https://developers.cloudflare.com/workers/platform/limits/#h...