Introduction to Offline Storage
In the early days of the web, there was the Persistent cookie. Despite a lot of legal fuss, this was never a great mechanism for storing large amounts of data for offline use.
Then HTML5 era brought in a raft of ideas about how we could improve the situation. Some of them made it to fruition and others died. Today we have three main storage options:
Local Storage – Easy to use synchronous key value pair mechanism. Very well supported by browsers.
Web SQL – Never made it to recommendation status, but was widely implemented before it was killed off.
IndexedDB – The recommended database storage mechanism. However browser support is still patchy, and it isn’t as easy to use as Local Storage.
Because as developers we have very limited control over which browsers our customers use our software on, we need to cater for many different scenarios. This can either lead to very complex code and prolonged delivery schedules, or the smart use of a clever open source library.
My use case / point of view
Working on a mobile app project where we know that we need persistence, but depending on how the project evolves we may want to persist to local storage or IndexedDB or even both of these.
The storage limits are a concern. It is commonly said that there is 5MB limit for local storage, however this limit entirely depends on the browser and some mobile browsers limit storage to only 2MB! The IndexedDB storage limit is not necessarily higher than the Local Storage limit either.
If the limit is reached in on storage mechanism I’d like to move over to another available storage mechanism on the device until all options are exhausted.
LocalStorage is a synchronous mechanism where IndexedDB works asynchronously, so it is not typically easy to swap one out for another.
I do not want to do a lot of rearchitecture work each time the team decides to change the persistence mechanism.
Also support for older storage technologies such as Web SQL is a big plus if this works reliably.
Let’s look at some useful options:
What is Lawnchair?
Lawnchair is a JSON storage library, and is based on working with adapters, the default one being the DOM adapter which writes to local Storage. Alternative adapters include:
gears-sqlite (for old android browsers)
These adapters mean the API remains the same even though the storage mechanism changes. The only difference is we pass in a different adapter.
Who wrote Lawnchair?
Lawnchair was created by Brian Leroux and has received contributions from 51 other developers.
Brian has done a lot of work on PhoneGap and Apache Cordova and the project grew out of the persistence needs for mobile apps.
Free under the MIT licence.
Over 2,000 Github stars
Try it out
Avoid the quickstart guide. There’s a typo in the html, and after you’ve fixed that it still doesn’t do anything very useful.
Instead download from Github and run index.html in the test folder.
This runs all of the QUnit tests and should give you a good idea very quickly of what does and doesn’t work correctly in your browser(s) of choice.
Then if you open up the index.html you’ll see there’s everything you need in here already and you can just delete the stuff you don’t need.
– Very small: default build is only 1.5 gzip’d
– Clean and simple API
A mostly inactive project for the past 2 years
Further Reading on Lawnchair
using lawnchair to save config data in
Also covered by Craig Shoemaker at the end of the Pluralsight course HTML5 Web Storage, IndexedDB and File System.
What is Dexie?
Dexie.js is a wrapper library for indexedDB aiming to solve these issues with the native IndexedDB API:
- Ambivalent error handling
- Poor queries
- Code complexity
Who wrote Dexie?
David Fahlander, with contributions from 17 other developers
Free under the Apache 2.0 licence
Over 1,000 Github stars
– Simplifies the use of IndexedDB
– Can use with IndexedDBShim to fallback to Web SQL for iOS browsers and older browsers
– Doesn’t support LocalStorage
What is LocalForage?
Wraps IndexedDB, WebSQL, or localStorage using a simple but powerful API
Who wrote LocalForage?
LocalForage is from Mozilla. There are 68 different contributors and the most active contributor has been Matthew Riley MacPherson.
Free under the Apache 2.0 licence
Over 6,000 github stars
– Modern API designed for modern browsers
– Support for many other libraries, such as Browserify and RequireJS
– Can either use callback API or ES6 Promises
– Good documentation at https://localforage.github.io/localForage/
– Heavier page weight than Dexie or Lawnchair
– Opinionated in favour of using IndexedDB wherever available
Try it out
Either download from Releases
npm install localforage
bower install localforage
Then follow the docs. This includes some fiddles which are useful for getting up to speed quickly
In the src directory localforage.js is written in ES6, so you may need to transpile the code to work with ES5 browsers.
If you just want to try it out quickly and easily, use localforage.min.js which is found in the docs directory.
What is PouchDB?
A database inspired by Apache CouchDB that is designed to run well within the browser.
It enables applications to store data locally while offline, then synchronize it with CouchDB and compatible servers when the application is back online, keeping the user’s data in sync no matter where they next login.
Who wrote PouchDB?
Nolan Lawson began it, and there now 15 different PouchDB people
Free under Apache Licence version 2.0
Over 6 thousand GitHub stars
Easy to Learn with good documentation
It is fully tested and supported in:
- Firefox 29+ (Including Firefox OS and Firefox for Android)
- Chrome 30+
- Safari 5+
- Internet Explorer 10+
- Opera 21+
- Android 4.0+
- iOS 7.1+
- Windows Phone 8+
If you don’t want to use Couch DB, then this isn’t for you
Try it out
Follow the Getting Started guide.