How to Implement Different Client-Side Data Storage Using JavaScript

If you are guilty of having 1,001 tabs open and want them to be available every time you open your browser, you should know this is possible thanks to browser storage. 

Data storage not only allows you to save those Pinterest inspirations or email attachments, but it also enables your computer to remember information just like the human brain, so that it doesn’t get lost.

There are several ways to implement data storage, and in this article, the focus will be on client-side data storage.

Let’s get started!

TL; DR:

Client-side storage enables browsers to save data locally. Different methods of storing data include cookies, local storage, session storage, and indexedDB. Cookies can send data to the server, and clear after an expiration date is reached. Local storage holds data until it's manually cleared, session storage holds data as long as the tab is open, and indexedDB allows you to store large and complex data for long-term use.  

Data Storage 

Data storage is a means of preserving files, documents, information, and other digital data for continuous and future reference or use. There are several reasons why data storage is important, including;

• Data storage can reduce the need for repeated server calls, thereby improving the performance of the web application. 

• Storing data locally allows some applications to function without an internet connection.

• It can help maintain the state of an application, such as preserving form inputs or saving items to a cart in an e-commerce app. 

• It improves users' experience, especially in terms of personalization, where users can tailor their experience, e.g., changing themes of a website like Gmail

Client-Side Storage 

In web development, client-side storage allows information to be stored in the browser for later use without requiring a connection to a server. Sometimes it can be used alongside a server; for example, you can download a media file from a server, and then store it on the client-side database, retrieving the file when needed. 

There are different methods to implement client-side data storage, including:

Cookies

Cookies are small data that a website stores in the user's browser to remember information about the user or their session across multiple requests.

Cookies can persist across many sessions if they have an expiration date. When the browser sends a request to a server, for example, the relevant cookie is added to the request, which can also be used to authenticate users.

• Cookies are used for session management, for example, a user remains logged in even when navigating through different pages of a web application. 

• It is used for personalization, specifically to store users' preferences such as theme or language. 

• It can also be used for tracking and analysing user behaviour, i.e., how often a user visits a page 

In your web browser, if you click on the application tab, you'll find the cookies 

Cookies include attributes that determine how they behave like:

Secure: This ensures that the cookie is transmitted through HTTPS connections only.

HTTPOnly: This prevents JavaScript from accessing the cookie, reducing cookie exposure to attacks like cross-site scripting (XSS)

Expiration date: This is used to set the duration of a cookie. This means when an expiration is reached, the browser clears the cookie automatically.

SameSite: This determines whether cookies can be sent with cross-site requests, which prevents them from the risk of cross-site request forgery (CSRF) attacks 

Limitations of Cookies

Privacy: Cookies store sensitive data like browser history, and users' preferences which can raise privacy concerns especially when it is used to track users' behaviour without consent. 

Security: Cookies can be exploited by threat actors who carry out attacks like cross-scripting (XSS), and session hijacking to steal sensitive information, and carry out unauthorised actions without the user's knowledge. 

Storage Capacity: Cookies can store only small amounts of data, which means they cannot store complex or large information.

Here’s a basic example of what a cookie looks like;

Local Storage 

Local storage allows client data to remain in the browser even after the page is closed.  The reason data is stored locally is to reduce server overhead so that the server doesn't have to send data repeatedly.

The browser can store the data and reuse it every time the user makes the same request or performs the same action. This can speed up the process of loading pages and improve user experience. 

• The local storage provides persistent client-side storage using a Key-Value API, which helps save user preferences and remember form data. 

• Local storage uses key methods such as setItem(), getItem(),removeItem(), and clear() to manipulate data.

• Local storage has a 5MB storage capacity, but it offers excellent browser compatibility and performance, which reduces its dependence on a server.

Limitations of Local Storage 

Storing Sensitive Data: Local storage is not secure for storing sensitive data, which makes it vulnerable to cross-site scripting (XSS) attacks. 

User Authentication and Session Management: When session identifiers or user roles are stored in local storage, it can lead to session hijacking. In other words, threat actors can steal a user's session ID and impersonate the user.

Storage Restriction: The size of local storage is 5mb per domain, which is great for small data sets but not for large data collections

How to implement Local storage

setItem()

This allows you to store data in the browser as a key/value pair

Note: If you keep changing the key and value in your file, and check the local storage, you’ll see that it keeps all the key and value pairs that you’ve added. They will remain until you manually delete them.

removeItem()

removeItem() deletes a specific key/value pair

Clear()

This removes every key/value pair stored in the local storage.

Session Storage

Session storage is a part of the Web Storage API that stores data temporarily; in other words, data is stored only when the page or tab is opened. If the page is closed, data is cleared automatically. It stores only 5MB of data per domain, similar to local storage. 

Some use cases where session storage can be utilized include; 

• Temporary session data is used where the data is only relevant for the session.

• Used to store temporary authentication tokens without cross-tab sharing if the token is not sensitive. 

• It can be used to store data gotten from an API, which is only available when the user is on the page and is cleared when the user closes the page. 

• It can be used to prevent users from multiple form submissions 

Limitations of Session Storage 

Data Persistence:  When a tab or page is closed, data stored in session storage is cleared, which means it can't be used for data that should persist across sessions. 

Storage Size: The storage size is 5MB, which means it is not suitable for storing large data.

Security Concerns: Session storage is vulnerable to Cross-Site Scripting (XSS). Sensitive information like authentication tokens stored in session storage can be exposed if a threat actor injects malicious scripts. 

Cross-Tab Communication: Data cannot be shared between tabs because each tab has its own storage. Once a tab is closed, the sessions are lost. This means it's not a good choice when the state needs to be shared across multiple tabs.

How to implement sessionStorage

setItem()

Note: If you keep changing the username, it doesn't add a new key/value pair; it just replaces the existing one, compared to local storage, which keeps everything you store until you clear it manually. This just gives you an idea of how temporary data is handled in local storage.

removeItem()

You can also use sessionStorage.clear() to clear all sessions.

IndexedDB

IndexedDB is a low-level API used to store data in the user's browser. It can handle large amounts of data, compared to local storage or session storage. It supports advanced features like; 

• Storing complex data types, including objects, arrays, and is suitable for apps that can function offline.

• It works asynchronously, which means it doesn't block the browser's main thread when performing an asynchronous task. In other words, it can run tasks in the background without slowing down or freezing the UI.

• It is efficient in fast data queries, allowing quick filtering and searching.

• It has a large storage capacity (up to 2GB of data), which makes it suitable for large applications. 

Limitations of IndexedDB

Complex Code: IndexedDB can lead to verbose and complex code when handling error management and other data operations. 

Not Reactive: IndexedDB does not provide native events when data changes, making it difficult for front-end components to react to updates happening in another tab or window.

Internationalized sorting: Languages have rules for sorting text, including special characters.  IndexedDB does not automatically sort data based on these rules, which means that you must manually sort the data in your application after retrieving it.

No Automatic Synchronizing: IndexedDB does not handle syncing with a server-side database. You have to write custom code to synchronize data between the client-side IndexedDB and the server-side database for consistency. 

Open Database

Create Object Store

Add Data

The image below shows that we have created a database and stored data using IndexedDB.

What to Consider When Choosing Client-Side Storage 

Data Size: Each storage methods have a different storage capacity;

• Cookie storage is about 4-5 KB of data

• Local storage and session storage are about 5MB 

• indexedDB has a larger storage capacity of 2GB or more, making it suitable for storing larger datasets. 

Persistence: This refers to the duration for which data lasts before it is cleared.

• Session storage persists only as long as the tab or window is open. When the tab is closed, data is removed. 

• Local storage persists even after closing a tab until it is cleared manually or explicitly using JavaScript code. 

• Cookies can persist data across sessions and usually have an expiration date.

•  IndexedDB is used in large-scale applications and can persist data even when the application is offline. 

Security: Security must be considered for each storage method to avoid exploitation from threat actors. For example, you should not store any sensitive details like payment details, users' passwords, or authentication tokens in client-side storage because they are vulnerable and can be compromised. 

Complexity:  Working with cookies, local storage, and session storage is straightforward because they use key/value pairs, while indexedDB can be a little complex cause it involves object stores, transactions, asynchronous operations, indexing, and so on. 

Offline support: Local storage and session storage support offline caching for small amounts of data, like users' preferences. While indexedDB provides offline capabilities for larger and complex applications. 

Performance: Cookies, local storage, and session storage are suitable for storing small amounts of data compared to indexedDB, which offers better performance when dealing with larger and structured data (e.g., objects, arrays, etc)

Summary 

Storing data on the client-side of a web application requires various methods like cookies, local storage, session storage, and IndexedDB. local storage is used for storing small amounts of data, cookies are used to send data to the server, and session storage stores data temporarily while the tab is open.

IndexedDB is used for storing more complex and larger data. Depending on what your web app needs, these storage methods can be used together or separately to handle different tasks.

Frequently Asked Questions