The API calls shouldn't be stored in the browser. That would just be a mess. A refresh should predictably fetch fresh data, because that matches user intent. There are also times I want to turn caching off. The understanding of what is reasonable to cache and what isn't is better understood on the front end, where the data is actually used/consumed. Browser caching is out for my use case.

I create a JavaScript object that matches the interface of my request library, axios in my case. The cache is basically a middleware to it created by function wrapping. Kind of like how memoize works but with a bit of extra smarts.

I have my own .get(), .post(), .delete() and .put() functions. So when a .get() is called, it's a cache check and return the stored value. If not found call axios.get() with the passed in args and store in cache before returning.

The post() function clears the cache then passes through the arguments to axios.post().

Etc.

The 5 minutes is accomplished with an entry on the event loop to remove said item.

It's only like 30 lines of code.

The real wins for this is in basic navigation. Clicking around site exploring, makes it snappy. Another advantage is lowering the total request count a bit to the backend, lowering the cloud bill.

You’d be surprised how far you can get with even the dumbest possible caching strategy. I’m talking about something like a server side memcache that just blows everything away on any non-log write.

If your baseline is so a new fetch every single time anyway, it doesn’t take much to achieve some pretty impressive wins.