Exploring Client-Side Storage in HTML5
- Often you need to store data accessed from the internet to your local system.
- The most common method to store data locally in all browsers is cookies, which are key-value pairs of strings that are stored locally in a text file.
- These text files are sent to the server, having the same domain name, with respect to every HTTP request.
- There was an increasing number of issues with cookies, however, especially as Web developers tried to use them in ways the creators didn't originally envision.
- Cookies pose multiple security issues. They are unencrypted, so unless your entire website is delivered over SSL, the cookies aren't secure. Across the time some hackers discovered, cookies can also be stolen via cross-site scripting techniques and DNS spoofing.
- When users found out about the security and privacy issues with cookies, many users started to restrict or entirely disable cookies — meaning that websites could not always assume they could use cookies.
- Cookies also pose performance issues. As cookies are included in every HTTP request, they can affect how long it takes for a browser to download a webpage — which means you don't want to store large amounts of data in them. And even if you wanted to store lots of data, you usually couldn't. Most browsers restricted each cookie to a max size of 4KB and allowed a max of 20 cookies per domain — not a lot of space.
- Luckily, we are now in the era of "HTML5": the new set of HTML, CSS, and JavaScript specifications that try to make Web development easier and websites more powerful. These specifications include multiple approaches to client-side storage that go far beyond cookies
- The HTML5 provides a new feature that supports the client-side storage, which is further divided into the following types of storage:
- Session Storage
- Local Storage
- Database Storage
- IndexedDB
- File API
Session Storage
Session storage is a storage that acts as cookies but has more storage capacity. A cookie has the capacity to store a maximum of 4 kilo bytes (KB) data; however, a session storage has the capacity to store data in mega bytes (MB).
Learn more about session storage
Local Storage
Local storage is same as the session storage, except the feature of persistency. In other words, a localStorage object can be assumed as a persistent version of a sessionStorage object. The session storage stores the data till the duration of a browser tab session, while the local storage stores the saved data on a user's computer even after closing the browser window.
Learn more about local storage
Database Storage
HTML5 also provides database storage to store data on a client's machine using a Structured Query language (SQL) database. It uses a temporary database to store data for a specified period of time.
The following code snippet shows how to make a connection with a database:
db = openDatabase("DBTest", "1.0", "HTML5 Database API example", 200000);
The preceding code snippet creates a database object, db, with the title DBTest, a version number of 1.0, along with a description and approximate size.
After creating a database connection, two basic functions transaction() and executeSql() are used to execute a SQL query. The transaction() function takes a single argument, executeSql() function, which actually executes the query. The executeSql() function takes four arguments, a string query, an array of strings to insert the values for place holders in string query, a function on successful execution of the query, and a function on failure of the query.
Learn more about Database Storage
IndexedDB
The IndexedDB is an object based data store.
The IndexedDB API is a more capable but far more complex API. The API allows you to store large amounts of structured data (in the form of objects and object stores) and then perform queries on that data using indexe
The API permits you to create databases, data stores and indexes, handle revisions, populate data using transactions, run non-blocking queries, and traverse data sets using cursors.
The File API
The File API is a way for websites to store files on the user's file system, scoped to their own little sandbox. The File API is very similar to the IndexedDB in actual capabilities — synchronous data storage and retrieval — but its API may feel more intuitive for developers that are accustomed to dealing with the file system. In addition, the File API specification includes support for storing binary files, such as images or PDFs.
Reason to store data client-side
- Performace is enhanced when you are not going to server for data which can be stored client side. The data can be cached client-side, so it can be retrieved without additional server requests.
- When you have significant amount of client-side data to store like HTML string or configuration settings.
- When you want to make your application work offline. No connection or request to server.
- Remembers user data, form input and also retain application state.
Data Security with Client-Side Storage
We must also discuss security when we discuss data storage and anything related to data. Like storing information in a server database of a web application, similar security guidelines should be applied to database storage on the client side. This is especially true since unlike a server where you may have control over the firewalls, users, passwords, and other security features, a visitor's browser is outside the immediate network. This makes it that much more important to be vigilant about what is stored in the client browser and how it is stored.
Storage Data Type
Cookies and localStorage accept only strings, but of course, you can often serialize other types of data into strings (via JSON, for example); so if it is not binary, it can probably be turned into a string.
IndexedDB can natively accept most JavaScript objects (with a few exceptions, such as functions).
The File API accepts both text and binary objects, so it is the most capable in this regard.
cookies | String |
localStorage | Strings |
IndexedDB | Most JS Objects |
File API | Text, Binary |
Storage Limit
The APIs differ in the quantity of data they can store, so even if you are storing strings, your API choice is affected by how much string data you need to store.
The cookies can only store up to 4KB each (~4000 ASCII characters), and the specification recommends that browsers support a minimum of 20 per domain and a 300 total. The localStorage quota varies, with some browsers supporting 2MB per domain, some seemingly unlimited, and most averaging around 5MB.
The indexedDB and File API specifications don't yet give recommendations for how much browsers should give to websites, so Chrome is currently experimenting with a unified quota API for those APIs. With their quota system, there are two types of storage — temporary and permanant. Any data in temporary storage can be evicted by the browser whenever it feels the need. Data in permanent storage will only be removed when the website or user requests it. For temporary storage, a website can use up to 20% of the total available temporary storage space, but for any permanent storage, the website must explicitly ask the user for the permission to use that space, and then can request however much space is available.
With all of these APIs, you can never safely assume that you can store everything. It's the user's computer that you're storing data on, not your own server, and it's ultimately up to the users to decide what to do with their hard drive space.
cookies | 4KB each, 20 per domain min | |
localStorage | 2.5-5MB average | |
IndexedDB | Temporary: up to 20% of available space per app. Permanent: Can request up to 100% of available space. | |
File API | Same as IndexedDB |
Browser Support
The HTML5 storage options have a wide range of browser support, as there's been a lot of disagreement in the standards world about what a client-side storage API should look like.
The localStorage API was the simplest and least controversial of the APIs, and so it was the first to be implemented. It's now supported in all "modern browsers," including IE8.
The IndexedDB and File APIs are growing in acceptance among browser vendors and hope to see significantly more support for them over the coming year. At the time of writing, however, the IndexedDB is supported only in FireFox 4+ and Chrome 11+.
The File API is only supported in Chrome.
What API to Use
In situation of having to develop only for one browser (like making a Chrome extension or an internal tool), you could consider using the File API or IndexedDB API. However, most Web developers are trying to target multiple browsers and given the browser support situation, the only practical cross-platform HTML5 data storage option is the localStorage API.
The HTML5 storage options have a wide range of browser support, as there's been a lot of disagreement in the standards world about what a client-side storage API should look like.
The localStorage API was the simplest and least controversial of the APIs, and so it was the first to be implemented. It's now supported in all "modern browsers," including IE8.
The IndexedDB and File APIs are growing in acceptance among browser vendors and hope to see significantly more support for them over the coming year. At the time of writing, however, the IndexedDB is supported only in FireFox 4+ and Chrome 11+.
The File API is only supported in Chrome.
What API to Use
In situation of having to develop only for one browser (like making a Chrome extension or an internal tool), you could consider using the File API or IndexedDB API. However, most Web developers are trying to target multiple browsers and given the browser support situation, the only practical cross-platform HTML5 data storage option is the localStorage API.
cookies | Good fallback. |
localStorage | Practical current option. |
IndexedDB | Good future option. |
File API | Chrome-only! |
0 comments:
Post a Comment