So what is browser storage?
Now as I mentioned, we have the browser and we have the server,
these are the two pieces that typically interact when we're serving a web page,
the web page runs in the browser but a) it's served by a server and b) most web applications also talk
to a server, either behind the scenes through Javascript or by using the default browser behavior where
for example you can submit a form and the request is issued to the server.
Now the server then has a server-side database where data can be stored,
the browser also has a couple of storage mechanisms.
So this is the big picture
but now let's dive into two sides here. For the server side,
so for the data which we send to the server with a HttpRequest, we typically store the important data,
the data which also needs to persist, the data
we also want to store locked away from the users because for example if we have a list of all users
with all their e-mail addresses, of course that has to be stored on one central server. When we stored
something in the browser, then we effectively store it on the machine of our user,
so on your computer for example.
Now of course the implication of that is that this a) is data
we as the application developer can not always tap into, only when you're visiting our page we can basically
use the Javascript code to interact with the browser storage, so the data is not always available to
us
and in addition it also can't be shared with other users.
So the browser storage is really limited in scenarios where it makes sense,
for example if you're building an online shop, of course you wouldn't store the products or the orders
or anything like that in the browser because you need to share the products with the other users, with
all users of your web application,
therefore such data needs to be stored on your server. The orders of course belong to a single user but
you as the owner of the shop also need access to them so that you can fulfill them and therefore that
would also be stored on a server side database.
Now one thing however you could consider storing in the browser would be the shopping cart, the current
shopping cart of the user,
it only matters to that user
and you might not need to store it on your servers. If you're not running any analytics on that or something
like that, you can store it just where your user is,
so in the browser of the user,
same is true for authentication data, like a session ID, such data could be stored in a browser,
so temporary data or convenience data which might improve the user experience but which is not essential
to your entire offering.
Now when we talk about browser storage, we got three major storage types -
we got local storage and session storage which are very related
and I'll explain the difference in this module, we get cookies and we got IndexedDB
Now let's learn about the differences between these different storage engines, between local storage
cookies and IndexedDB. Local storage and session storage is a simple key-value store,
so it's like a Javascript object which we save in a file,
so it's basically just a couple of key-value pairs.
You could use that to store for example session ID of a user,
some analytics key which you need to send to your analytics servers, something like that,
so often you use local storage to manage user preferences or basic user data.
You can tap into local storage with the help of Javascript and only Javascript, so only the Javascript
code that runs in the browser is able to communicate with local storage.
It's easy to use, quite versatile but of course it's bad for complex data because it's just a key-value
store,
so if you would be building a rich web application, like Google Sheets for example where you might need
to store a lot of complex data in the browser as well, then this is not really a great option.
Now also a relatively simple storage is cookies. Now cookies are also key-value pairs in the end,
though we can configure them in various ways, for example we can set a cookie to expire at some time
in the future so that it automatically gets deleted basically, for local storage
we can also delete data but we have to do that manually through Javascript, for cookies we could set
it as an option on one of our entries.
We also since it's still relatively simple use it to manage basic preferences, session IDs, stuff like
that and we can also access and clear it with Javascript, just like local storage by the way because
I didn't mention it there, the user also can clear all that data through the developer tools, through the
browser settings where you can clear all local data, that is possible.
Now the special thing about the cookie is that it's a bit more clunky to use than local storage,
it's not having such a nice API
for working with it.
It's equally versatile though, maybe a bit more even because you can set expiry dates and and that's really
different,
cookies also typically are sent to the server with outgoing HttpRequests.
So cookies, unlike local storage and session storage can also be read by the server because they're attached
to outgoing HttpRequests in the headers of these requests,
so that can be an extra plus.
Now just like local storage because they're simple key-value stores, they're not suited for more complex
data
and then we get IndexedDB. IndexedDB is the most sophisticated storage device amongst these three,
it's a client side database in the end, built into the browser which you can use with a query language,
you can run more or less complex queries against IndexedDB,
you can therefore manage complex data in there because you can have different tables with records that
are connected and so on and you can access it with Javascript, you can also clear it with Javascript and
just like all browser side storages, the user can always clear and erase all that data with a click
of a button in the preferences and therefore none of these storages should be a storage you rely on.
You can use it to improve the user experience but you have to live with the fact that your user can
always clear these
storages. Now IndexedDB is also a bit clunky to use, it has a Javascript API but that is a bit annoying
and it's great for complex non-critical data,
it offers quite good performance so it's really good if you have complex data in your application.
I will say though, I'm really talking about rich client side applications there, something like Google
Sheets and so on,
so where you basically build a desktop level application in the browser and you might need to store
a lot of temporary or see my temporary data in some storage on the browser and you don't want to store
that on a server for whatever reason because you want to make sure that your application works
offline or anything like that, then this could be used, in a lot of applications
you'll not really need IndexedDB.