APO is super exciting, but as someone who already uses Workers, the way APO is implemented in front of Workers instead of behind them is a serious limitation.
Currently, it seems to function like this:
Client ←→ APO ←→ Workers ←→ Origin
Your Workers only get run when there are cache misses, and a fetch needs to go to the origin.
But it would be so much more powerful if it were implemented like this:
Client ←→ Workers ←→ APO ←→ Origin
This would allow you to see and manipulate every request and response, just how you can do without APO enabled.
As it is right now, Workers can only act on the following inputs: the URL, the device type (if you opt in to splitting the cache into those three buckets), and whether or not a WordPress-related bypass cookie is present.
If you need Workers to act on other inputs, like custom cookies, a specific user agent, other headers, custom KV fetches, or time-based variation, APO will cause issues (as responses will get cached), and you’re basically on your own to implement APO’s features manually via Workers and KV or go without.
I’ve considered trying to build (and open source) my own APO-like Worker/KV code, and I’m considering doing something convoluted like having a non-APO domain with Workers redirect its fetches to an APO-enabled domain and seeing if I can make that work… but I don’t really want to do those things unless I hear that APO is never going to have a better integration with Workers.
@yevgen or others: what are the chances that APO will ever be able to work as a layer between Workers and the origin fetch, so that we can make use of all the amazing power of Workers on every request?