This is an interesting blog post, but I'm surprised about this part: "[...] even though we have JavaScript code running in the browser, and it knows about the

This is an interesting blog post, but I'm surprised about this part: "[...] even though we have JavaScript code running in the browser, and it knows about the invalidation of a particular URL, it cannot tell the browser cache that the data at the end of that URL is now updated. Instead, we keep a local cache inside the web page. This cache maps URL to JSON payload, and our wrapper on top of XMLHttpRequest will first check this cache, and deliver the data if it’s there. When we receive an invalidation request over IMQ, we mark it stale (although we may still deliver it, for example for offline browsing purposes.)" I thought that the traditional approach to this would be to add a cache-buster [1] to the query string. Couldn't the Javascript code that knows there's a change update the cache-buster argument and refetch the URL? Then they wouldn't need their own cache implementation. [1] A cache-buster is typically a random value (or timestamp) included as a query-string argument on the URL. This value has no meaning to the server, but because the URL string has changed the browser can't make any assumptions about what the return value would be, and is therefore forced to make a request to the server. EDIT: I think I see now - what they refer to as "the cache" is more complex than I had thought; it seems somewhat more analagous to the state in a React app, in that it is triggering UI updates and isn't just a dumb layer between the client and server.