
Caching AJAX calls with local storage - toni
http://fre.sc/tech-blog/a-new-approach-of-caching-in-web-applications
======
zacharyvoase
Y’know, browsers already have several built-in mechanisms for transparent
caching without having to rely on Web Storage. I'd strongly recommend taking a
look at them before implementing a jQuery plugin.

The only problem is that HTTP-based caching requires sane server URLs, and the
Rails code here indicates a lack of understanding of how to build a cache-
friendly URL structure.

I'm also a little fazed by the fact that the 'isCacheValid' key not only
checks the validity of the cache, but also _sets_ a cache key at the same
time.

~~~
robinkomiwes
I'm one of the guys behind this plugin. In our case built-in browsers cache
mechanisms were a no go because we needed to have a programmatic control over
our cache. Our app is heavily powered by realtime notifications from the
server, and we needed a way to invalidate the cache when some events occurs.

About 'isCacheValid' setting the cache key, you're right, it should have been
done in the success callback. The gist is going to be updated soon with your
feedback.

~~~
untog
Couldn't you use just an extra query string parameter when you want to force a
refresh? Like, ?v=12312312353. It's a little hackish I'll grant you, but so is
caching HTTP in LocalStorage.

~~~
pohl
This won't actually cause anything to be evicted from the cache. It just adds
a new cache entry with a new key. This is poor resource management, and
removes some of the appeal of going out of your way to reuse the browser's
cache mechanism.

~~~
untog
Sure, but the HTTP cache is managed by the browser. Unless you are pulling
down mammoth amounts of data, cache management is unlikely to be a concern for
you.

------
d0ugal
Hi, Author of locache.js (<http://locachejs.org/>) here.

I think there is a good use case for something like this in certain
situations, but using the browser cache for Ajax requests is generally a
better idea.

I wrote locache as a more general client-side cache mechanism for all sorts of
objects rather than just caching requests. I was caching lots of backbone
models and user actions - it generally worked quite well. I also actually used
it quite a bit for caching third party API's that I had no control over (more
specifically I was working on a mashup using three different API's and often
fetching the same content). When being lazy I tried once to cache my own API
and regretted it after as its basically a poor mans browser cache.

Your going to run into a bunch of issues with localStorage if you have not
already - specifically to do with memory limits, the blocking API and some
strange support on mobile browsers. You may find some useful things in my
code, or you may want to drop me a line to discuss it further.

------
ef4
There's no reason AJAX calls can't get cached the normal way. Just set
appropriate headers on the response and the browser will cache it for as long
as you want.

~~~
robinkomiwes
I'm completely aware that in most cases, the browser should do the job.

Like I said before, we wanted to have a programmatic access to our cache. It
let us read what is cached, update it or destroy it when some events occurs.

