Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / web

Picking a Web Client Side Persistence Mechanism

5.00/5 (1 vote)
15 Aug 2011CPOL3 min read 15.2K  
How to pick a web client side persistence mechanism

Picking a Web Client Side Persistence MechanismYesterday’s evening, I got a phone call from a client that wanted to discuss an interesting dilemma – How to pick a web client side persistence mechanism for an offline web application? This is a very important question with all the hype around HTML5 and the new specifications it brings. Many web developers which will build offline applications in the near future will probably find themselves stuck with this dilemma also. So in this post, I’ll summarize the options you got and I’ll point you to two new JavaScript libraries that can help you implement your persistence mechanism without the concern what will be the implementation underneath.

Web Client Side Persistence Mechanism Options

With HTML5 specifications, there are new options to store data on web client side that add to some older ones (such as cookies). Here are the new options that you face:

  • Local Storage is a key/value dictionary that is stored in the web browser and persists your data even if you close the browser/browser tab. The saved data is local to the web browser and isn’t sent to the server. It includes two different type of storages – local storage and session storage. If you like to read more about this mechanism, you can read the following post – Using Web Storage in Web Applications.
  • IndexedDB – Taken from the W3C specifications – “APIs for a database of records holding simple values and hierarchical objects. Each record consists of a key and some value. Moreover, the database maintains indexes over records it stores.”. I’ll write about this mechanism in a future post.
  • Your own custom implementation that can be based on the new HTML5 File API for example.

So with those new choices, what will you pick?
Since indexedDB is currently in specification development (meaning it is very unstable) and local storage is a stable specification, you might be tempted to use local storage, but you will probably want to use indexedDB in the future. So how can you solve this dilemma?

datajs and AmplifyJS

Let's not solve it at all. You can use a wrapper which will go to indexedDB by default and fallback to local storage or in memory implementation for older browsers. There are two great and brand new libraries that implement such wrappers which I recommend to check when you are going to use a web client side storage:

  • datajs – An open source JavaScript library from Microsoft data platform which is described as “new cross-browser JavaScript library that enables data-centric web applications by leveraging modern protocols such as JSON and OData and HTML5-enabled browser features”. datajs supports local storage, indexedDB (currently in experimental support) and a fallback in-memory storage for older browsers. For further reading, go to Working with Client-Side Storage Using datajs Store API.
  • AmplifyJS – An open source JavaScript library from .appendto() which is described as “a set of components designed to solve common web application problems with a simplistic API”. It includes a wrapper for various persistent client-side storage systems with the amplify.store wrapper. For further reading, go to Store AmplifyJS API Documentation.

These libraries can make your life easier and remove most of your doubts.

Summary

There are new web client side persistence mechanisms which can help you to create offline web applications. I hope that this post will help you to understand the options you have and some of the libraries that might help you to use those options.


License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)