That's interesting. I wonder how it interacts with the Cache API.
The Cache API has kinda poor cache hit ratio today if you serve users from multiple locations since the cache is per DC per location.
If the Worker runs close to the Origin, then we wouldn't have dozens of DCs to MISS our requests anymore. Unfortunately, we'd miss all the advantagens of caching assets, like lower TTFB.
I guess running two Workers, one close to the origin and other close to the client, could replicate a bit their Smart Cache Topology. Unfortunately, I don't think it's possible to route things like that (maybe with service bindings?), and I'm pretty sure we'd end up paying twice per uncached request, lol.
The Cache API has kinda poor cache hit ratio today if you serve users from multiple locations since the cache is per DC per location.
If the Worker runs close to the Origin, then we wouldn't have dozens of DCs to MISS our requests anymore. Unfortunately, we'd miss all the advantagens of caching assets, like lower TTFB.
I guess running two Workers, one close to the origin and other close to the client, could replicate a bit their Smart Cache Topology. Unfortunately, I don't think it's possible to route things like that (maybe with service bindings?), and I'm pretty sure we'd end up paying twice per uncached request, lol.
Cool feature for non-cacheable content anyway