If you have a blog running at blog.mycompany.com, that is not going to be as effective for SEO as if the blog were at mycompany.com/blog. You want your primary domain getting the credit. But it’s also not ideal to have a separate subfolder if you have two different services (blog and main product).
So the best solution is to reverse proxy so that internet traffic hits /blog, but the worker is actually forwarding the traffic to your internal service.
Got it. So you do that through a Cloudflare worker? Aren’t you loosing the caching perks from cloudflafe? It would nice to be able to do that directy through a page rule.
There are probably multiple ways to reverse proxy, it’s just that CF workers are versatile to handle many use cases. You don’t have to lose the caching benefits. You can still pull your assets through Cloudflare CDN since workers operate at the request level (afaik).
In fact it can be even more performant. You can use Workers KV to cache as well. So a request comes in, check KV store, return if found. If not, pull from asset CDN.
KV is a global persistent data store, so reads and writes may have to cross the internet. In comparison, the Cache API reads and writes from the local datacenter's cache. Also, Cache API doesn't cost extra (KV does).
However, better than either of these is to formulate your outgoing fetch() calls such that they naturally get the caching properties you want. fetch() goes through Cloudflare's usual caching logic. When that does what you want, it works better because this is the path that has been most optimized over many years.
There isn't really any magic here. If your resources or API are naturally cacheable using generic HTTP caching logic, then it's best to use fetch() and rely on that rather than try to re-implement the same logic with cache API. But if the default logic isn't a good fit, cache API makes sense.
So the best solution is to reverse proxy so that internet traffic hits /blog, but the worker is actually forwarding the traffic to your internal service.