Workers Requests vs Subrequests?

I build a very small test setup to better understand how Worker requests are counted.

Basically like this

              main request
             /            \
sub request #1         sub request #2
sub-sub request #2

All are connected via service bindings.

By my count that should be

  • 1x main request (billable)
  • 3x sub request (non-billable)

But “Requests today” counter on the worker dashboard goes up by +4 (= all billable).

Isn’t the point of subrequests via service bindings to be counted as one with the main request?
Or am I missing something here?

I’m pretty sure that sub-requests count because the worker you are making the requests to still needs to fire.

Well, yeah.
That’s probably where my different expectation comes from.

There it states …

Shared resources
Workers connected to one another via Service bindings share the CPU resources of the top-level request. A single thread is allocated and reused amongst these Workers. This means no idle resources are wasted while work is performed across various Workers.

Hence no extra resources should be required.

Either way, it’s understandable and I don’t want to argue about :logo:'s pricing.
It’s simply a bit sad from a software architecture POV, as small workers calling each other would be great regarding the “low coupling, high cohesion” design principle. The price incentive OTOH strongly nudges one towards (comparatively) larger, more monolithic Workers.

It’s the main issue with the recent work that Cloudflare has done to demonstrate microfrontends using Workers - sounds great in practice, but inflates your requests bill 8x.

I suspect that pricing will get a rework to make it feasible.

Very true.

And from a pure performance POV many subrequests from the same main worker is likely not even that smart, as even fetch() to another “nearby” Worker will be much more expensive than a simple local JS function call.

Monolithic workers can be reasonably solved by trunk based development techniques and a CI/CD pipeline setup with some hand tuned bundling strategies. Minimize chunk count and chunk size limit, for example, are staples of virtually every modern bundler.
The crux is that most SME have neither time nor expertise to properly setup such infrastructure and will be stuck on higher than necessary cost from either Cloudflare bills or code maintenance efforts.

So I as well look forward to a rework of what would be a great help for many of these small development teams.