Caching Ideas in the FuzzyToast Framework

If you followed my introduction for my proposal for a client-side framework in JavaScript for creating rich internet applications (code-named Fuzzytoast), you'll be interested to know that I finally got around to putting the source code up on GitHub.

I'm realizing now that I could increase the performance if I were able to cache the downloaded collateral. Here are some of my ideas.

Where to Store?

The $.fuzzytoast() function creates an object for holding a reference to the URL for the template, the URL for the web service request, where to place the results, etc. I realized that I could cache some of the network activity and store it in this same object. Easy-squeezy.

The way the demonstration is written, we have a single page that instantiates the jquery.fuzzytoast.js script and its objects, so this could actually work.

However, a browser is not a database. Specifically:

• The data results are persisted only as long as the page is not refreshed.
• The data is stored in the browser's memory and we've all seen the interesting results when that is filled.
• How do we know when to partially flush the cached data? Wait, this isn't a specific problem with JavaScript objects, so let's chat about this later.

Let's assume that the amount of data we'll be storing won't be that large, but with a little selective purging, we might be fine with this approach. If not, we'll move to depend on HTML5.

HTML5 Storage

If we use the new sessionStorage feature introduced with HTML5-compliant browsers, we can cache all the live-long day and let the browser worry about it! Right?

• Browsers are still browsers and we shouldn't be kicking where its painful.
• As of 2011 (mere 10 days before the end of the world), not all browsers are HTML5-compliant.

But we could degenerate nicely, especially taking advantage of the DOMCached plugin.

What to Cache?

What can we cache? Obviously we can cache downloaded templates, as those wouldn't change, and they probably won't be very large. Perfect candidate.

It would be easy too, before I make the $.ajax() call, I check to see if it is already in the $.fuzzytoast.linkdata array, and use it if it is, and grab it and store it if it isn't. Something like:

    var linkdata = $.fuzzytoast.linkdata[id];

    if ( linkdata.templateData ) {
        $.fuzzytoast.getdata(linkdata);
    }
    else {
        $.ajax({
            // . . .
            url: linkdata.template,
            success: function(templateData) {
                linkdata.templateData = templateData;
                $.fuzzytoast.getdata(linkdata);
            }
            // . . .
        });
    }

What about the web service calls? The page designer probably knows more about this part and may know what can and can't be cached, so we should probably add a cache property that is actually an object of additional properties:

cache: {
    template: true,
    data: false
}

Is true and false sufficient, or do we need something like a time-to-live?

Tasks

So here is my list of things to do:

• Implement a cache property to the $.fuzzytoast() links.
• Investigate the DOMCached plugin for jQuery
• Implement a session storage based on my investigation

Tell others about this article: