What’s up everyone? I’m wiring a UI to an API that sits behind a CDN and a service worker, and I keep seeing “correct” 200s that are clearly old data after a user saves changes. Hard-refresh fixes it, so it smells like caching layers fighting each other, but I can’t just disable caching because performance is already tight.
What’s your practical strategy for making API responses reliably fresh when it matters (writes, immediate reads) while still keeping CDN/browser caching on for the rest?
Your “hard refresh fixes it” detail screams the service worker is caching API GETs (or the CDN is), and you’re not varying the cache key after a write, so you keep getting a perfectly valid 200 from the wrong layer. My practical approach is: never cache “read-your-writes” endpoints at all, and make that explicit in headers. For the GET you do immediately after a save, return Cache-Control: no-store (or at least no-cache, must-revalidate) and have the service worker bypass its cache for that route; keep long-lived caching for the “browse” GETs that aren’t immediately coupled to a mutation. One question: is your service worker doing a generic “cache-first for all GET /api/*” rule? That’s the part that usually bites—CDN config is visible, SW logic is easy to forget.
:: Copyright KIRUPA 2024 //--