Revalidate -- how to avoid browser cache?

[lukebarton]

Let's say we have an /api/me endpoint that returns { name: "Joe Bloggs" }. This endpoint also uses a cache-control: private, max-age=120 header. Let's say the user updates their name to "Steve Madden" in our app, so, after, we trigger amutate-and-revalidate, so we're up to date with origin (just in case). The issue now arises that the revalidation fetch is going to hit the browser cache returning stale data (due to cache-control) and thus set us back to "Joe Bloggs" after revalidation.

Potential ways out of this situation:

1. Don't revalidate (short lived benefits, as soon as another revalidation occurs, the same issue will appear)
2. Don't use cache headers (lost engineering opportunity)
3. Trigger an separate fetch with pragma: no-cache header, to skip the browser cache and update the resource in browser cache with a new resource, before revalidation (not really ideal, a lot of manual leg work, fetches being done outside of swr)

As far as I can see, swr lacks any ability to ask the fetcher to apply any kind of pragma to it's fetch. swr chooses to skirt http altogether, which makes sense as a general fetcher/revalidator of things.

So I thought it might be appropriate to target the fetcher directly, causing the fetcher to revalidate with different cache pragma:

const invalidations = new Map<string, boolean>();

export const invalidate = (key: string) => {
  invalidations.set(key, true);
};

export const jsonFetcher = async (key: string) => {
  const shouldReload = (key: string) => invalidations.get(key) || false;
  const requestInit: RequestInit = {
    cache: shouldReload(key) ? "reload" : "default",
  };
  const res = await fetch(key, requestInit);
  invalidations.delete(key);
  return res.json();
};

Used like so:

const me = useSWR<{ name: string}>("/api/me", jsonFetcher);
const newName = "Steve";
me.mutate(async (prev) => {
  await updateNameOnBackend(newName);
  invalidate("/api/me");
  return {
    ...prev,
    name: newName;
  }
}, true); // << revalidate = true causing revalidation

This works great and let's swr remain agnostic of any upstream caching that might apply to the fetcher 🥇

However, a developer experience issue with this becomes more apparent when I hide away the useSWR call as recommended by the docs:

const me = useMe();
const newName = "Steve";
me.mutate(async (prev) => {
  await updateNameOnBackend(newName);
  invalidate("/api/me");
...
}, true);

My code needs to know about the key but mutate doesn't provide the key to us so we have to get/know it ourselves, which is a bit of a pain.

Change/feature proposal:

• Add key (key being mutated) as a second arg on the callback passed to mutate; and;
• Add a key prop to the result of useSWR to indicate the key that was used when fetching the current data/error etc.

All other ideas welcome

[SleeplessByte]

If updateNameOnBackend hits PUT /api/me or even POST /api/me, your browser/http agent MUST clear the cache per 4.4 Invalidation.

That means that updating a REST resource followed by a GET on that rest resource, should give you a fresh copy.

[lukebarton]

Realisitic use cases that invalidate /api/me might be /api/switchUser or /api/logout, so you can't rely on that.

[SleeplessByte]

Not if you add Vary: Authorization; you can definitely rely on this with REST API design. However, most APIs these days aren't, so I absolutely understand if you need something else.

[lukebarton]

I can't be the only one to be using browser caching in conjunction with useSWR? Kinda feels like the point of useSWR is to get people to use the browser cache since revalidateOnMount and revalidateOnFocus lead to rather chatty behaviour.

Working on high-traffic sites, doubling, tripling the number of requests that get made for a resource isn't going to fly because the order of magnitude is ever higher, therefore browser caching and edge caching are a must. That's all well and good, but sometimes you need to overcome that browser caching, and useSWR doesn't really provide any help to do that, especially not even being kind and offering up the key in invalidate callbacks or even on the actual responseInterface itself.

Does no-one else have this problem? I'm surprised!

[sergiodxa]

I think the only way to ignore the browser cache is to add a query to the URL and change it when you want to ignore it, like changing from ?v=1 to be ?v=2, this way the browser will ignore the cache, aside of that even if you are not using SWR there is no way to invalidate it client-side.

Maybe, you could set this v in a global variable and your fetcher functions could read it and add it to the URLs, then when you want to ignore the browser cache you can do window.v++ and then mutate(key), this will make SWR send a new request, and because your v changed it will ignore the browser cache and get new data.

You could wrap mutate to do the window.v++, maybe even add a special global variable per SWR key so you can invalidate the browser cache of only certain keys and not all of them, e.g. window["/api/me"]++; mutate("/api/me");

[lukebarton]

I think I've realised the answer: don't apply cache-control, even a short private one, to things that mutate. This avoids the issue altogether.

/post/1234 with cache-control: max-age=60 then updating /post/1234 still has the same sort of problem, but maybe it's not such a big issue. IDK, I'm happy to assume it's not an issue that affects most people.