State of Browser APIs

[00:00:00]
>> Before actually going and call some data storage APIs, let's talk about those APIs and the state of those APIs, so we understand what we can use today. So, this is the current list of APIs that are still available at different levels, at different browsers, okay? So, Cookies, Web Storage, WebSQL, Application Cache, IndexedDB, File and Directories, Cache Storage, and Filesystem Access.

[00:00:34]
So, let's go one by one, Cookies. Well, Cookies, I already spoiled you on this one, Cookies is not a good way to store data because the API is not really good, actually. Also, it's very limited in terms of the amount of data that you can store, the structure of that data is a string-based.

[00:00:56]
But the worst part of Cookies is that they are being sent to the server. So if you store 5K of data on every HTTP request that is made to your server, every one, every image, every JSON, every CSS request, every JSK file, on everyone though, the 5k will travel to the server, okay?

[00:01:19]
And that will impact performance, so it's actually a bad idea. Web Storage, barely, you haven't heard about Web Storage as a name, Web Storage is the name of the spec, but actually it's session storage or local storage, okay? We will get deeper with those, but let me spoil you this, we shouldn't be using these APIs anymore, even local storage, okay?

[00:01:46]
We will see why in a second, but Web Storage then is an umbrella term that includes session storage and local storage. WebSQL, okay, that I'm not sure, have you ever used WebSQL before? No? Lucky you. Anyway, actually it wasn't so bad, and I'm talking about the past, wasn't.

[00:02:08]
So, we shouldn't be using WebSQL, and I will explain in a minute why? Application Cache, indexedDB, File and Directories, again, Cache Storage, and FileSystem Access. And, FileSystem Access has some kind of a subset API known as Origin Private File System. Let's try to go one by one. Cookies, we are not going to use them, okay?

[00:02:32]
So it's grayed out, no, we are not going to use it for data storage, we already mentioned that. So Web Storage, WebSQL, let me show you this, Cookies, not suitable for data storage, okay? So, we are taking that out, so Web Storage has problems, so I'm not saying don't use it 100% of the time.

[00:02:57]
We will try to avoid using Web Storage, okay? So, let me give you a quick idea of why? The main reason, but not the only one, but the main reason is performance, local storage or session storage APIs are synchronous APIs. That means that they take the thread until they're done, so that when you save data, it takes the thread.

[00:03:25]
And the thread is shared, it's the main UI thread, it's shared between you, your code, the local storage manager, and the rest of the browser that is occupied rendering the website. And also, managing events over that website, okay? So that's why it's a very bad idea to use local storage.

[00:03:48]
Because even if it's, I mean, if storing data takes 40 milliseconds, it might impact in the performance of your website for a while. So you're not keeping 60 frames per second in your animation for example, okay? So, we will see the API anyway really quickly, we will do a quick sample on it, and that's all.

[00:04:10]
We will try to replace it, okay? So if you're using Web Storage, local storage in your websites, have in mind that it's time to replace it, okay? So, Cookies, not suitable for data storage, Web Storage is kind of yeah, we will try to replace, that WebSQL is deprecated, okay?

[00:04:29]
So it's actually marked as deprecated, we shouldn't be using anymore in there is a big warning saying that, hey, we shouldn't be using this. So actually, just to give you a quick idea of what it was, it was a SQLite client, client side. So actually you could create SQL queries, tables, and run inner joins, and everything that you know from SQL, from ANSI SQL at least.

[00:04:55]
I mean it was fine, and then we'll explain you in case you really want to still use SQL, which options do we have? So, we are also ready for using SQL if you actually need you to do that, if you need to do that, why? Maybe some corporate applications, they are really heavily based on data, and you're relying on SQL queries for counting, making some math operations and so on.

[00:05:24]
Application Cache is also deprecated for good. Application Cache, also known as App Cache, was a way before to actually make your app available offline. And I'm talking about ten years ago, okay, kind of ten to 15 years ago. So I used that many times doing web apps into cell phone eight, cell phone nine, okay?

[00:05:51]
Today it's deprecated, that means that on some browsers it might be still there, okay? You will see a warning in the console if you use that, and fortunately we have better ways to do that. So, have in mind, it's deprecated, don't use it, okay? We need to find another way.

[00:06:08]
IndexedDB, yeah, that's our first green, if you have ever played with IndexedDB before, maybe you have weird face here. Because, many reasons, buggy implementations or many browsers, the API, it's kind of awful, terrible, we don't want the API, okay? But we'll see how to make it better anyway.

[00:06:34]
And also, it wasn't clear how it was working, okay? Anyway, today we are using IndexedDB 2.0 that has a better API, it's still not the API we want, okay? But we will do something on top of that anyway. The bugs for normal operations are gone, okay? So, it's safe to use most of indexedDB these days.

[00:07:02]
What's IndexedDB? It's a no SQL database, it's an object-based client side database. So, it's kind of fun, kind of a MongoDB client side of course, much simpler than MongoDB but client side, okay? Files and Directories API, it's also kind of deprecated, it's about to be deprecated, you have a question?

[00:07:27]
>> Yeah, you mentioned IndexedDB 2.0, I'm sure SemVer is different with browser vendors, but is it backwards compatible, is the API like similar to [INAUDIBLE]
>> IndexedDB 2.0 is backward compatible, it just added new ways to query data, a new way to work with it. So yeah, it's compatible with previous versions.

[00:07:49]
The thing is that previous version, I mean the first version was actually very limited in terms of how you can't transact with the query, only with cursors. And there were a couple of problems there, okay? So now it's better, and there's an IndexedDB 3.0 proposed also, coming, but it's not there yet.

[00:08:10]
File and Directories, this is to be deprecated, okay? So, what is that first? File and Directories API, also known as the File System API, but not to be confused with the other one that you see at the bottom. So the File System API or File and Directories API, today is Chromium-only, okay?

[00:08:30]
And the whole idea was to create a file system for our origin, that is not the actual real file system, okay? It's a built-on file system created for our machines where we can create files, directories, read files, write files, without any permission issue, okay? Because it's not the real user's file system.

[00:08:54]
But this is about to be deprecated, so you shouldn't be using that, and also it's Chromium-only, okay? Cache Storage is the other one that is green. The Cache Storage API actually is a cache storage interface, it's not its own API, it's part of the service worker spec. But anyway, it's not actually only available from a service worker, we are going to also use that API later.

[00:09:21]
So indexedDB stores data, typically JavaScript objects, IndexedDB. So when am talking about IndexedDB, so IndexedDB is storing objects, it can also store bytes. Cache Storage is storing HTTP responses, okay? So, assets that we can download from a server, but it's storing the whole response including Heathers on the body.

[00:09:51]
And then we have the FileSystem Access API. There is a new one that they wanted to call it the File System API, but there was already another one with the name File System API, so, they called that FileSystem Access API, okay? It's yellow because compatibility is still not 100%.

[00:10:13]
So, IndexedDB, and Cache Storage, and even Web Storage, we have 100% compatibility on every browser. Firefox, Chromium-based browsers, Safari, iPhone, Android, PWAs, Hybrids, everywhere. But the FileSystem Access API, it's a new one, okay? So it's a new API, today it's available on Chromium-based browsers. So that's Google Chrome, Microsoft Edge, Samsung Internet Browser, Opera Brave, and many others.

[00:10:44]
And it will let you open and work with the real File System, okay? The real File System of the user with user's permission, that's the only one from all the list you see here that will require user's permission. So you can open a folder, you can open a file, and you can read the contents, and you can write there, okay?

[00:11:11]
Web Kit Safari is not supporting the full API, but is supporting a subset of that API, known as the Origin Private File System. Okay, what is that? Actually, the same idea as the one that we mentioned before as File and Directories. So you can still use the same API but not for the real file system but for a built-on one, okay?

[00:11:37]
So Safari is supporting FileSystem Access API, but not for the use of real file system, but for a built-on one, okay? What's the idea? So why Apple did that? Because of Photoshop, Adobe portal Photoshop to the web, so it's a PWA now, Photoshop. Of course, they have the native app, but also they have Illustrator and Photoshop, they are PWA's.

[00:12:05]
They needed a couple of things, one of the things is they need to write temporary files in the file system, not just in memory. Because sometimes they work with huge files, so they cannot rely on just the RAM. So they needed access to the disk, even if it's not the public File System, just for temporary usage.

[00:12:24]
So that's why WebKit implemented the API but for Origin Private File System because of Adobe. But we can use it, okay? It's not just for Adobe, makes sense? So, that means that today we have like two API's. Only two API's that are safe to use, and are the two recommended API's, that's indexedDB and Cache Storage for different use cases.

[00:12:50]
And with some observations, you can still use Web Storage, try not to, or let's start the process to stop using it in the future. And FileSystem Access for some specific use cases, if [INAUDIBLE] Safari will actually implement the whole FileSystem Access soon. For now, it's just the Origin Private File System subset, makes sense?

[00:13:21]
Yeah, you have a question?
>> So, some roles have moved data that we would keep typically in Cookies into Web Storage, just, the hash, session state, things like that. I assume we're gonna discuss where that would go instead, right?
>> Yeah.
>> Okay, [INAUDIBLE]
>> But if you want the answer now, I can give you the answer now.

[00:13:41]
>> Is it IndexedDB?
>> Typically we move Web Storage to IndexedDB. In fact, there are a couple of wrappers on top of IndexedDB that will give you even a very similar API to Web Storage. But on top of it, but we will actually do that exact example in our project.

[00:13:59]
So we are going to use Web Storage first, and then we will upgrade that experience to IndexedDB. So we can see how we can do that, okay?
>> Great, thanks.
>> So at the end, we will care only these days about these four API's in terms of storage, okay?

[00:14:21]
To completely okay to use and to that they depends, okay? And Web Storage, let's say it's like, I don't wanna say it's going to be deprecated, but as a best practice, and let's say that today it's becoming an anti-pattern, okay? So it's becoming an API that we should avoid, okay?

[00:14:44]
We will cover it briefly anyway, just to get a quick idea, and that's all.