alt Hacker NewsRealizing there's a more fundamental piece I'm not explaining well here.
Our architecture is something like:
ingress -> routing -> security -> workers -> cache -> origin
That is, workers run "in front of" cache. That's usually what you want. Workers run on the edge, so putting them in front of cache doesn't cost anything in terms of latency, and there's a lot of useful stuff you can do only if they run in front, e.g. serving pages from cache but customizing them for specific users.
Putting workers behind cache is an architectural change. All of the logic around routing to them lives in front of the cache. And it makes Workers a lot less useful.
We weren't that excited about it until we had a clearer story for how to run custom logic on both sides of the cache, but it was pretty unclear how to do that in a nice way until the recent developments around ctx.props, ctx.exports, channel tokens, etc.
Replies
blog post didn't cover two details re stale-while-revalidate:
1. What headers does content that will revalidate use on client. Eg can a react hook trigger if a cms json revalidates?
2. If edge worker can call database worker: if database worker sends stale while revalidate, does that revalidate whole worker chain?
btw overall very cool, esp fine grained cache for authed/etc data
Does that new architecture make it more expensive to serve worker’s static assets and do worker-to-worker invocations? Or just harder to measure?
This change in billing makes enabling caching not such a straightforward decision, and encourages separating cached and non-cached parts of your workers into two separate workers, which is a bit annoying.