I'm using Workers as basically API gateway/smart load balancer to backend services that handle actual load (resource intensive data filtering). Most of the responses are not cached on Cloudflare level.
Thing is that I was using Workers for about 4 years already with not issue at at all, I'm aware that I use lots of requests and bandwidth but I just wish I was contacted about mandatory upgrade before effectively turning my service down.
I’m using cloudflare pages with workers doing the same as you on a much smaller scale. The workers reverse proxy a rest api under the same host so I don’t need to worry about CORS, take the country HTTP header provided by Cloudflare then route the request to backend servers in the nearest AWS region and also cache any responses with cache control headers utilising Cloudflare’s Edge caching. It works great and gives a fast user experience regardless of where you are in the world.
I was going to implement rate limiting backed by durable objects to protect my backends.
It seems exactly the usecase and ideal usage of workers! Now seeing this, it has me rethinking using/investing in cloudflare if they can decide if they like how you use workers or not and kick you off. It shouldn’t matter what output the worker generates as long as it conforms to https://developers.cloudflare.com/workers/platform/limits/
> Speaking from experience, if you only need rudimentary L7 load balancing, then Cloudflare Workers is as good as it gets.
What would you do in Workers that you couldn't do with Load Balancing? LB handles origin health, can do traffic steering, session affinity etc included. With Workers, you'd need to take care of all that.
I see a point if the Workers do some lifting / caching / transforming etc before passing on the requests, but as a simple load balancer, the actual Load Balancing service seems a better fit.
You're right: Workers are not a generic L7 load balancer, but of course plenty useful for the other stuff you point out (for ex, transformations and caching).
