Client-Side Data Storage

Chapter 1. A Gentle Introduction to Client-Side Data Storage

Browsers have—slowly and with a lot of growing pains—evolved over the past decade to become powerful workhorses. Enhanced layout controls, 3D graphics and gaming, and even music are now within the realm of possibility of the little old browser. One more exciting, although relatively less flashy (no pun intended), feature is client-side data storage. But what do we mean by this?

The “typical” process by which you navigate the Web hasn’t changed since time began: your browser asks for a URL, a web server sends stuff back, you then ask for more stuff, and the web server sends more stuff to you.

You can certainly get more complex and add JavaScript and AJAX to the mix. But even in a fancy web 2.0 application, your browser may be requesting information from the server again and again and again. The reason for this is that—for all intents and purposes—the browser is an amnesiac. Everything it knows it has to learn from the server.

While this is true in general, it overlooks a powerful alternative—storing data on the browser itself. This enables the browser to skip asking the server for information and to simply retrieve it locally from the user’s machine. It even affords the chance to manipulate that data for whatever purposes may make sense. That data could then be sent back to the server for updating later.

In summary, this gives the browser:

• Immediate access to data. Even with AJAX being typically much quicker for fetching data, by having the data local to the machine itself access will be even quicker.

• Less network traffic. Instead of constantly fetching data from the server, data can be fetched once and stored for as long as it makes sense. This leads to...

• Less strain on your server. If your server is constantly responding to requests and fetching stuff from a database server, you could overtax your server. By reducing the amount of calls you make, your server does less work.

• Finally, with data stored locally, the possibility of a fully offline application becomes much more feasible.

Of course, it isn’t all sunshine and roses. Moving data to the browser can also have the following negatives:

• There isn’t any support for synchronization. Imagine you’ve copied data from a server to a browser. How do you handle keeping that data in sync? What happens if there are conflicts? None of the core technologies covered in this book support any concept of handling sync. You can, however, find libraries like PouchDB, that have this built in.

• Storage limits are fuzzy. As developers, we hate fuzzy. We want to know exactly how much of a resource we can use. Unfortunately, for many of the technologies this book will cover, the limits—as well as what happens when you break them—are a bit vague.

• Finally, while the technologies covered here are powerful, they are not a replacement for a full database server. Database servers are extremely fine-tuned to the job of handling huge amounts of data and providing a way to search them. The solutions we’ll cover are certainly capable of storing data, but at the same time, they aren’t like an embedded Oracle server. (Although that may be a good thing.)

In this book, we’ll discuss various client-side storage techniques. For each one we’ll also cover, plainly and honestly, how well they are supported in the wild. You’ll see examples of the APIs as well as demos you can use to help you learn how to use the APIs yourself. Finally, we’ll look at a few libraries that aim to make client-side storage even easier. Buckle up—this is going to be a fun, and sometimes rough, tour through some of the more useful aspects of the Web!