A better solution is to give theusercontrol instead. (The user in this case is the web developer using ourcachedFetchfunction). Like with storage such as Memcached or Redis on the server side,you set a lifetime specifying how long it should be cached.

For example,in Python (with Flask)

>>> from werkzeug.contrib.cache import MemcachedCache
>>> cache = MemcachedCache(['127.0.0.1:11211'])
>>> cache.set('key','value',10)
True
>>> cache.get('key')
'value'
>>> # waiting 10 seconds
...
>>> cache.get('key')
>>>

Now,neithersessionStoragenorlocalStoragehas this functionality built-in,so we have to implement it manually. We’ll do that by always taking note of the timestamp at the time of storing and use that to compare on a possible cache hit.

But before we do that,how is this going to look? How about something like this:

// Use a default expiry time,like 5 minutes
cachedFetch('https://httpbin.org/get')
  .then(r => r.json())
  .then(info => {
    console.log('Your origin is ' + info.origin)
  })

// Instead of passing options to `fetch` we pass an integer which is seconds
cachedFetch('https://httpbin.org/get',2 * 60)  // 2 min
  .then(r => r.json())
  .then(info => {
    console.log('Your origin is ' + info.origin)
  })

// Combined with fetch's options object but called with a custom name
let init = {
  mode: 'same-origin',seconds: 3 * 60 // 3 minutes
}
cachedFetch('https://httpbin.org/get',init)
  .then(r => r.json())
  .then(info => {
    console.log('Your origin is ' + info.origin)
  })

The crucial new thing we’re going to add is that every time we save the response data,wealsorecordwhenwe stored it. But note that now we can also switch to the braver storage oflocalStorageinstead ofsessionStorage. Our custom expiry code will make sure we don’t get horribly stale cache hits in the otherwise persistentlocalStorage.

So here’s our final working solution:

const cachedFetch = (url,options) => {
  let expiry = 5 * 60 // 5 min default
  if (typeof options === 'number') {
    expiry = options
    options = undefined
  } else if (typeof options === 'object') {
    // I hope you didn't set it to 0 seconds
    expiry = options.seconds || expiry
  }
  // Use the URL as the cache key to sessionStorage
  let cacheKey = url
  let cached = localStorage.getItem(cacheKey)
  let whenCached = localStorage.getItem(cacheKey + ':ts')
  if (cached !== null && whenCached !== null) {
    // it was in sessionStorage! Yay!
    // Even though 'whenCached' is a string,this operation
    // works because the minus sign converts the
    // string to an integer and it will work.
    let age = (Date.now() - whenCached) / 1000
    if (age < expiry) {
      let response = new Response(new Blob([cached]))
      return Promise.resolve(response)
    } else {
      // We need to clean up this old key
      localStorage.removeItem(cacheKey)
      localStorage.removeItem(cacheKey + ':ts')
    }
  }

  return fetch(url,it will be
        // consumed by the time it's returned. This
        // way we're being un-intrusive.
        response.clone().text().then(content => {
          localStorage.setItem(cacheKey,content)
          localStorage.setItem(cacheKey+':ts',Date.now())
        })
      }
    }
    return response
  })
}

On CodePen

Future Implementation – Better,Fancier,Cooler

Not only are we avoiding hitting those web APIs excessively,the best part is thatlocalStorageis a gazillion times faster than relying on network. See this blog post for a comparison oflocalStorageversus XHR:localForage vs. XHR. It measures other things but basically concludes thatlocalStorageis really fast and disk-cache warm-ups are rare.

So how could we further improve our solution?

Dealing with binary responses

Our implementation here doesn’t bother caching non-text things,like images,but there’s no reason it can’t. We would need a bit more code. In particular,we probably want to store more information about theBlob. Every response is a Blob basically. For text and JSON it’s just an array of strings. And thetypeandsizedoesn’t really matter because it’s something you can figure out from the string itself. For binary content the blob has to be converted to aArrayBuffer.

For the curIoUs,to see an extension of our implementation that supports images,check outthis CodePen.

Using hashed cache keys

Another potential improvement is to trade space for speed by hashing every URL,which was what we used as a key,to something much smaller. In the examples above we’ve been using just a handful of really small and neat URLs (e.g.https://httpbin.org/get) but if you have really large URLs with lots of query string thingies and you have lots of them,it can really add up.

A solution to this is to usethis neat algorithmwhich is known to be safe and fast:

const hashstr = s => {
  let hash = 0;
  if (s.length == 0) return hash;
  for (let i = 0; i < s.length; i++) {
    let char = s.charCodeAt(i);
    hash = ((hash<<5)-hash)+char;
    hash = hash & hash; // Convert to 32bit integer
  }
  return hash;
}

If you like this,check outthis CodePen. If you inspect the storage in your web console you’ll see keys like557027443.

Conclusion

You now have a working solution you can stick into your web apps,where perhaps you’re consuming a web API and you know the responses can be pretty well cached for your users.

One last thing that might be a natural extension of this prototype is to take it beyond an article and into a real,concrete project,with tests and aREADME,and publish it on npm – but that’s for another time!