Thursday, May 4th, 2006
An AJAX Caching Strategy
Category: Examples, Programming
Making HTTP requests willy-nilly from AJAX applications, however, is almost never a good idea or design decision. The server side of the equation may not be able to handle the flood of requests. The client side of the AJAX application may have some of its requests time out or abort, which will disrupt the user experience that is meant to be AJAX’s strength.
They give the example of grabbing the latest energy prices from the U.S. Energy Information Agency and displaying them in a section of your site. Of course, you could make the request for the information each time, but depending on your connection and how popular the site is, there is a better way to handle it.
They give the example of caching based on a time limit first, complete with the code to grab the information, set up the refresh capability, and create the cache for the script to check later on. Of course, grabbing the information across from another domain requests a little coding magic, and they chose this kind of proxy to get the job done.
Related Content:
theres so many different instances and cases where you would need to cache in ajax, and this isnt one (it should be done at the server / proxy level in this case). I’ll start working on a big caching article tonight.
“Making HTTP requests willy-nilly from AJAX applications, however, is almost never a good idea or design decision. The server side of the equation may not be able to handle the flood of requests.”
Baloney! What’s the difference between an Ajax application requesting a little squirt of data, and a browser requesting an ENTIRE PAGE? If a user is going to click on something they’re making a request from the server regardless. Users do that “willy nilly” too
A smaller data packet means the server will complete the request SOONER and be available for more requests.
I’m interested in this and would like to see your article, Allen.
@James
At first glance your 100% correct, and when it comes down to it, standard practices in ajax caching (i.e. its nonexistant heh) will do the trick. But when your dealing with sending / receiving large amounts of data, triggering queries each time, etc, and on a large scale, you can run into problems. Max connections can be an issue in itself (yeah i know, its a stretch). There is no end all cache solution for Ajax, so my writeup will cover as many specialty niche’s / cases as possible.
Also, there are implications on the client side as well, if a user has already looked up data with an xhr call, why should they ever have to look it up again? It *should* be cached if it can be.