How To Speed Up 10X Your In-App Dashboard With Client Storage

Published on Aug 24, 2020

If you built an app, your user probably accesses his data from a central dashboard.

The traditional way to code a dashboard is to fetch the data from a web server, before serving the web page if you use server-side rendering, or by requesting a web service if you perform an asynchronous call from your front-end code. You then have to wait for the data to be processed and arrive at your application.

If the user consults the app several times a day, you have to go through the same process again and again. It's costly for the web server, and it's costly for you if you have to pay for each API request. A web server can only serve so many requests, so it might prevent your app from scaling and make your users unhappy. You will end up paying twice as much: once for duplicate web services that have been provided to your application, and a second time for the business loss it will create.

What if you could send the request once, save the data you need for later in the user's computer, and ask again for new data later on? That's what a Client-Side Storage API allows you to do.

There are three different ways to store data at a local level: Session Storage and Local Storage, which are part of the Web Storage API, and the IndexedDB API. The latter is the one we need to store a big amount of indexed data for our dashboard. Web Storage is great for a small amount of data, like settings parameters, but they aren't indexed to increase the searching speed.

When a user logs in his dashboard for the first time, the application requests the data from the external web service and stores it in the IndexedDB database. The data will remain available from one session to the next, with or without an Internet connection (Progressive Web Application). This leads to near-instant loading time on repeat visits.

The user applies changes to the IndexedDB database, and the application takes care of sending the local data once in a while to the external web service. This way, you can fine-tune how much data you need to transport and how often you want to do it. 

If the user logs out or changes his access location, the data is synchronized beforehand with the external web server, so the application can redownload it locally somewhere else.

When logging out or after an expiration date, we can also tell our app to erase data from the web browser, leaving no trace for anyone else to read or use. You never want to store sensitive data on the client's side, of course, so you should only share what's strictly necessary and keep the local database clean at all times.