3 ms·

I do. It helps with latency when someone hits the "back" button and your queries are page/view based. Instead of seeing the delay of the query, it's instant.

I do. It helps with latency when someone hits the "back" button and your queries are page/view based. Instead of seeing the delay of the query, it's instant. Because, well, it probably should be. Cache times are usually short, < 5 minutes, and are cleared whenever a POST/DELETE/PUT are issued. Works pretty well in my experience.

subarctic 4y ago
is this built-in browser caching? how do you set it up so it gets invalidated by POST/DELETE/PUT?
- TylerE 4y ago
  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.
- BackBlast 4y ago
  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.

subarctic 4y ago

is this built-in browser caching? how do you set it up so it gets invalidated by POST/DELETE/PUT?

TylerE 4y ago
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.
BackBlast 4y ago
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.