Who Needs MySQL When There Is IndexedDB?

matthew setter is a professional technical writer and passionate web application developer. he’s also the founder of malt blue , the community for php web application development professionals and php cloud development casts – learn cloud development through the lens of php. you can connect with him on twitter , facebook , linkedin or google+ anytime.

recently, i discussed an alternative to cookies with the introduction of html5 or web storage . i took a look at what it is and why it’s such a great alternative to (the much maligned) cookies.

just in case you missed it, here’s a quick summary. local_ and sessionstorage provide a much more efficient way of storing information client-side in the browser. what’s more, they don’t have the overhead that cookies do since they aren’t included with page requests. we looked at how it works, potential security implications, browser support and more.

but local- and sessionstorage aren’t the only available options when we’re looking to increase the complexity of the web applications that we develop and deliver today. with html5, the w3c provides another standard that may be more of what you’re looking for, especially if you’re a fan of the nosql based technologies. this option is indexeddb .

so in this series, we’re going to look at what indexeddb is, what its advantages and disadvantages are, and where it would be a good fit for your development needs. in the next installment, we’ll finish off with a sample application so you can get a hands on understanding of how it works.

technology overview
indexeddb is an alternative to the (now deprecated) w3c standard websql database (websql). it was introduced around april 23, 2009. this is a description from wikipedia:

“… is a web page api for storing data in databases that can be queried using a variant of sql”

as it says on the tin, websql brings client-side application development the full power of sql . based on sqlite , it allows us to employ one of the fundamental skills we have in our development toolkit – database development – both on the client and the server side.

on november 18, 2010, the w3c made the decision to no longer support the standard. this was due to disagreement from a number of vendors – including mozilla and microsoft – on how it should be practically implemented and incomplete browser support. as a result, indexeddb was introduced as an alternative standard for web data storage.

however, indexeddb is not a browser database but an object store . it allows for applications to design, store and manipulate objects, without sterilization, and the ability to conduct high performance searches on them.

as i mentioned earlier, it’s a lot like nosql databases, such as mongodb and couchdb . objects are created and manipulated in javascript, and then stored and updated in the object store.

but it’s not exactly the same as say a standard php, ruby or python script creating and persisting objects. there are a few key points to know and remember when using it

operations require transactions
every operation that you perform when using indexeddb must be carried out within a transaction. whether that’s reading information from an object store, manipulating data in it or changing its structure.

transactions can have three modes:

operations are ashynchronous

here’s the difference. with sql, you run a query and receive back the result. with indexeddb, you run a transaction and set up a callback to handle the success or failure of the transaction, which you can check in on later. you don’t fire off the request and wait for the result, such as retrieving a list of objects matching an index.

if you’re familiar with jquery, you’ll know what i’m referring to. if not, have a look at the following code:

var jqxhr = $.ajax( "http://www.newrelic.com" )
    .done(function() { alert("success"); })
    .fail(function() { alert("error"); })
    .always(function() { alert("complete"); });

with the code above, we’re making an ajax request to newrelic.com . we then setup three handlers or callbacks ; one for the done, fail and always events. we also do this in indexeddb. have a look at the sample below:

// open the library data store
var request = indexeddb.open("library");
 
request.onsuccess = function(e) {
    newrelic.indexeddb.getallbookslist();
};
 
request.onerror = function(e) {
    console.log("error opening object store. : ", e);
};

here we make a request to open the library datastore. if the request is successful, we fire off the getallbookslist function, which in turn, follows a similar pattern. if the request fails, we log the reason why.

indexes & cursors
continuing the database analogy, objects in the object store can have one or a collection of indexes to speed up data retrieval. creating them is rather simple, as shown in this code from the mozilla development network (mdn):

// this is what our customer data looks like.
const customerdata = [
  { ssn: "444-44-4444", name: "bill", age: 35, email: "bill@company.com" },
  { ssn: "555-55-5555", name: "donna", age: 32, email: "donna@home.org" }
];
 
// create an objectstore to hold information about our customers. we're
// going to use "ssn" as our key path because it's guaranteed to be
// unique.
var objectstore = db.createobjectstore("customers", { keypath: "ssn" });
 
// create an index to search customers by name. we may have duplicates
// so we can't use a unique index.
objectstore.createindex("name", "name", { unique: false });

with cursors, we are able to iterate over the data that we retrieve from the object store. we can also use an index to limit the data that we retrieve. in the example below, also from mdn, we perform a ‘getall’ type query:

var customers = [];
 
objectstore.opencursor().onsuccess = function(event) {
  var cursor = event.target.result;
  if (cursor) {
    customers.push(cursor.value);
    cursor.continue();
  }
  else {
    alert("got all customers: " + customers);
  }
};

browser support
unfortunately, it’s not all good news yet. at this time, indexeddb is only supported by the following browsers:

as websql is deprecated, it’s likely that support for indexeddb will continue to grow over time as the spec becomes more refined. to find out exactly which browsers (and their versions) support it, try it out at caniuse.com .

although safari, chrome and opera still support websql – and technically you could develop apps with it — it’s not a good idea to do so. some, however, suggest a middle ground with the use of a wrapper library allowing you to have the both of best worlds.

advantages

1. an emerging standard
with lots of support from the w3c, mozilla, microsoft and google, indexeddb is rapidly emerging as a standard. it is likely that it will be around for quite some time, meaning you can reliably develop against it. what’s more, it offers a sense of stability and vendor independence that websql does not.

2. use objects – not sql
additionally, indexed db lets you work with objects as best suits the needs and designs of your application (whereas websql required that you had a solid grasp of sql.)

disadvantages

1. lack of browser support
at this stage, the primary disadvantage is clearly lack of browser support. yes, it’s already available in the latest versions of firefox and chrome, and it’s going to be in ie 10. but it’s only available in the full release of ie 10 and that’s only available on windows 8.  and since ie 10 has only been released recently, it will take awhile before it’s the dominant version of ie in use.

the good news about this is that chrome and firefox make up about 54% of the browsers in use. see this in the graph below from statcounter :

where is it a good fit?
as i’ve alluded to, indexeddb is a good fit if your client-side data needs are more complex than what local/sessionstorage can provide (i.e. you’re looking for more than a simple key/value store in your application).

yes, you can use javascript functions (such as json.stringify and json.parse) to manage information stored in it. but it doesn’t offer you the flexibility and power that indexeddb does. so if you want a storage layer that offers higher performance, duplicate key values or an efficient way to search through the data stored, then go with indexeddb. but if your needs are simpler, then go with session and localstorage. remember, your needs are what should guide your choice.

is it the right choice?
there’s been a lot of debate for and against websql and indexdb. personally, i don’t see websql as a bad technology, but i see indexeddb as a better choice. i recently was reading paul harrison’s blog and his three points for indexeddb sums up why i think it’s a better choice:

* sql is an entirely different system, unrelated to the languages it’s usually embedded within.
* it’s easy for inexperienced programmers to embed security flaws in their sql statement
* it’s easy for inexperienced programmers to develop overly complex queries that database systems find impossible to process in a reasonable period of time

in the article he supports websql and i don’t want to quote him out of context here. but for me at least, web applications are getting ever more complex, and it’s not right to take a technology that predated the web and attempt to retro-fit it into it. i believe the better choice is to split from the past and to provide a data storage layer that is more appropriate to its needs. and this is what i believe indexeddb is.

conclusion
so there you have it. indexeddb is set to be one of the two key new standards for client-side data storage in the years to come. it allows us to store complex objects that we create and manipulate in javascript combined with a decent amount of index performance when searching for the information stored.

we’ve looked at the advantages and disadvantages and touched on whether it or websql is the right standard for the future. so what do you think about it? do you believe it’s the right fit for the future of web application development? or do you believe that websql would have been the better choice? voice your opinion in the comments. we want to know what you think.

for an interesting discussion about whether websql or indexeddb should be the standard to use for web developers, check out this thread on kevin dangoor’s (mozilla) google+ page. it makes for some interesting reading with a wealth of opinions.