Search for a command to run...
Solving Cloudflare's limitations
Motivated by weird problems & sleek solutions. Working on, learning with and bootstrapping coders.fail #BuildInPublic Passionate about tech and helping people as well as combining the two.
No comments yet. Be the first to comment.
A Journey of Learning and Discovery
Rounding out the Stripe payment provider portfolio
Load error of posts in admin backend since version 5.21.0
`ghost update` keeps 2 most current, not 2 last active versions, breaking downgrading
Ghost CLI commands `update`/`install` misinterprets provided versions, if omitting patch version, 2 digits & ending in 0
After having to shift from developing Workers, to developing a Worker marketplace, we ended up with a new challenge: To solve the issue of only one Worker being active and answering each request and route.
With multiple registered Cloudflare Workers, just one with the more specific route matcher will process the current request. This prohibits any chance of having multiple workers process the request.
This is needed, especially when using highly specialized workers, which optimize the content of the requests. Like caching and image optimizations.
This is hindered by the fact, that the obvious solution of having one router worker which proxies the original request to the first worker and sends its response and the modified request to the subsequent worker, following the same logic for any additional workers, just doesn't work.
Cloudflare does not allow for sending the response of the previous worker to the subsequent one but forwards the original request.
To solve this, some workarounds need to be used to make it possible.
We've managed to find multiple solution approaches, at least one of which already showed promising results and works. There is still room for improvement, and try to find the cleanest approach.
Obviously, every worker, every request, and every additional step adds latency and makes the request-response take longer to reach the client. To prevent this from happening to each request, this system needs to heavily rely on a good caching strategy.
To be able to make this approach work, there needs to be a proper setup for the worker to capture all the routes of the other workers. It needs to be configured to be able to proxy to all necessary workers.
We've already started building an interface to manage those workers and routes, to extend the possibilities offered in Cloudflare's web interface. The possibility to integrate into the future worker marketplace is already set up and conceptualized.
Like with the last pivot to a worker marketplace, the development complexity is much higher than originally planned for our first ideas. This won't keep us from trying, might lead to another pivot.
Stay tuned!