Saving Data in a React app

Transactional vs Analytical data

First it’s going to be important to make a distinction between transactional data and analytical data. Here’s a good graphic that explains it:

From Stitch Data

Storing data

There are a lot of ways to store data for an app, and we basically categorize them by technology and permanence:

  • In-memory databases (backend)
  • Browser storage (frontend)
  • In memory (frontend)


Databases are the work horse of the internet. You’re definitely familiar with them so I’ll just list the main features of them:

  • There are two main types: SQL vs NoSQL
  • Types of SQL databases: MySQL, Postgresql, sqlite
  • Types of NoSQL databases: MongoDB, DynamoDB, there’s a lot of them

In-memory databases

These are similar to databases, but less permanent. Usually they’re used for information that’s only needed for a short time. Sometimes they’re used in combination with other databases. Some popular ones are Redis.

Browser storage

This is the most permanent type of storage that you can get on the frontend. There are a bunch of different types of browser storage and they all have some similar characteristics. This type of storage is useful when you want to store information that your frontend needs to access without having to make a network request to a backend service. (We care about network requests because they’re slow, relatively speaking.)

  • Identity information about the specific client (especially if the user is not logged in)
  • Information about network requests that we plan to send in the future (if a network request fails sometimes we store it in local storage to retry in the future)

In memory

This is the least permanent type of storage that there is. This type of storage goes away any time the user refreshes the page or navigates between pages. This type of storage includes:


There are a lot of different ways to store data for your app. You probably want a database, but for each type of thing it’s usually important to decide on purpose where to store it based on how long you need/plan to keep it around. Permanence of the data roughly correlates with effort to store it (i.e. it’s harder to make a backend request to store something in a database than it is to stick it in a Javascript variable).


Caching is one of the two hard things in Computer Science. I want to make a couple important points right up front:

  1. Never manually store things to a cache, and never write your own caching library. Most API communication libraries (like react-query or redux-toolkit) have an option for caching that you can just turn on. If you’re planning to write your own it’s most likely going to end up being a big waste of time.
  2. Probably don’t use caching before you need it. If you need it, you’ll generally know. Maybe your app will be slow or it won’t work without an internet connection (or both).

Cache invalidation

When you cache things, you’re storing a temporary record of what the truth was at a moment in time. However, in web apps the truth changes all the time so it’s important when you start to cache things to know how often they’re probably going to change.

Request speed

The most common reason for caching is to increase the speed at which things happen in your app. Network requests take a long time, and getting a large amount of data from a database also can take a long time.

App Loading speed

Another reason to use caching is to be able to display information in your app faster. If I were to load a web app and then refresh the page, the app would have to make all new requests to the backend to load data even though the odds that any of it changed in the 200ms that the page was reloading are low.

  • information about what products are available to display a nav bar
  • Lists of items that are read frequently but don’t change that often
  • things with frequently-changing information like product quantity or which NFTs are for sale

Offline access

The last type of caching is directed at making apps available even when there’s no internet access. These are called progressive web apps and I can’t do a better job explaining them than MDN although I want to point out Service Workers as an important article to also read


Most apps involve some sort of communication with other devices, so most apps will have to have a data store of some kind.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store