Picking a Web Client Side Persistence Mechanism
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 include 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
Lets 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:
These libraries can make your life easier and remove most of your doubts.
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)