Transcript from the "Why Browser Data Storage" Lesson
>> So let's start talking about browser data storage then. So we have already seen everything that we're going to cover. So now we're going to start with the first part, with the first unit that we have there, the state of the browser storage. But first, why browser data storage?
[00:00:17] So why is this important to ask to web developers, okay? First, to increase user experience, okay? So, yeah, originally the web was actually server side, okay, then we moved to client side. And now we are kind of going back to the roots with a server side rendering again.
[00:00:38] But in the middle, even if we are doing just plain server side rendering, we need to increase user experience thanks to browser data storage. We will see a couple of use cases for that, okay, but that's the first thing. The second one is performance, okay? We know, or we should know, that web performance is actually really important for conversion, okay?
[00:01:02] So if you are following different guidelines of web performance, if you are applying techniques for web performance that will improve your web vitals, the metrics that are actually measuring performance in our websites, that will lead to better conversion. And we are doing websites because we want conversion, whatever conversion means for your app, for your website.
[00:01:29] More users register, more sales, more users typing things in your app, whatever conversion means, we can increase performance, thanks to using these APIs. Offline support, this may not be suitable for all the websites, for all the apps, okay? But anyway, sometimes offering some kind of a basic offline experience within your website or your web app is a good idea.
[00:01:58] Even if that offline experience is just your logo and a message saying, I'm sorry that we have a connection issue so I cannot provide you something. Or even if you can provide an alternative game. For example, there are some newspapers out there, some media websites, that when you're offline, you get a crossword.
[00:02:18] So okay, you don't get the news, but you get something from that web app. Well, thanks to these APIs, because they are browser-based, they are not based on the server. If the user has no connection or the connection doesn't work or your server is down, that's another option, then client side you can provide an alternative experience, okay, make sense?
[00:02:44] So we can store user generated content. For example, it can be social networks, I mean, when we are typing a post. So while you're typing the posts, you can do everything client side. Of course, you will sync that data later. But also it can be just an app, a corporate application for employees that are on the street collecting data.
[00:03:11] Well, you're gonna start collecting that data client-side and then that data will be synced to the server at one point in the future. So all that data that is generated by the user needs a place to be stored, and that's why we're going to use APIs for that.
[00:03:27] To store the app's state. So if you're using frameworks or libraries such as Redux, for example, or the Flux design pattern, anyway. Sometimes you have this idea of the app state that is kind of one or more objects that represents the current state of your app. Well, you can actually save that state and restore that state later.
[00:03:50] Because sometimes the life cycle of our app is not what we think. So maybe the user is getting out of our web app for a couple of minutes. But the user is then recording a video with a phone. And when the user go back to your web app, your web app is restarting.
[00:04:07] Because it was killed from memory, it was discarded from memory. So, well, in that case, you could save the app's state somewhere and restore that state when the user goes back, so the user experience will look like if the app was never discarded, okay? So cached assets. So to improve performance and also to do some kind of complex algorithms, you can cache assets client side and then you can play with those assets client side.
[00:05:11] Again, these are just ideas that I'm throwing you, so they may trigger some bells in your brain to see if you find a use case, okay, for everything that we're going to see today. Authentication tokens, this is probably something that is really useful in case you have authentication in your website.
[00:05:31] So if you are using OAuth, typically you have a token, you need a place to store that token. Cookies today, we will mention cookies in a minute. But it's not a good place to store data for many reasons. But that cookies are getting really, really complex because they are the problem, they are the cause for user tracking.
[00:05:55] And so browsers are making cookies more complicated every day, despite the API is terrible for storing data. So we want another way to store data. Analytics, so instead of sending HTTP request or beacons to a server, every time you have analytics, you can just store the analytics client side.
[00:06:43] So browsers manage implementation and security details. So we don't manage that, okay? So we don't know where the data is going to store in the user file system. We don't manage that. We don't manage which format the data is actually going to be stored physically in the OS.
[00:07:01] Yeah, we have an API, we have an interface, we use the interface. But we don't know what happens behind the scenes, okay? And that's okay, we shouldn't know. So every browser stores that data differently. And we should always treat the data as something that may disappear anytime. So we will talk about all the situations that may trigger that.
[00:07:25] But from my phone drops in the toilet to wherever, okay, I'm resetting the phone from factory, so there are many situations where the data might not be there. So we should always treat it as something that may disappear at any time, okay? The whole idea is that data will persist between browser sessions.
[00:07:55] So if I store something there, that data may be there in a year as well, okay? If nothing happens, the data will be there later, tomorrow, this afternoon, in a month, in a week, or in a year, okay? So on most APIs that we are going to see, probably 95% of the APIs that we will cover, there will be no permission from the user required.
[00:08:24] So the user will never see a dialog or something saying, hey, this website is storing data client side. So this is completely transparent to the user, okay? So it's good in one way, but also that will mean that there are some challenges, okay? Because the browsers probably won't want us to overuse that, okay?
[00:08:50] Because we know the space is limited, at least disk space, okay? But have in mind that, so there are a couple of exceptions that we will see later. But we won't require an explicit permission from the user to store data client-side. And everything that we're going to see today works for websites, web apps, progressive web app, installed progressive web apps.
[00:09:15] Installed progressive web apps from the app stores, and also hybrid apps. Hybrid apps are when you have a native shell and then you have a web app on top of the native shell. For example, Apache Cordova, also known as PhoneGap, or Capacitor from Ionic, or Electron on the desktop are frameworks, libraries that will help you creating hybrids.
[00:09:40] So some of these API's may have a different implementation when you're using those frameworks. And those hybrid framework may offer you alternative APIs as well for data storage. But typically, everything that we're going to see works there as well, okay? And data, by default, is not shared to the server, okay?
[00:10:03] The only exception to that is cookies. Yeah, it's an API or it's a kind of a storage that is client-side, but it's the only one that is automatically shared with the server. So a cookie is automatically shared with your server on every HTTP request, okay? In the HTTP request headers, all your cookies will be sent to the server, okay?
[00:10:26] And also, data is not shared with other web apps, okay, at least with a web app in a different origin. We will talk about that in a second.