Check out a free preview of the full Web Storage APIs course

The "Debugging Tools" Lesson is part of the full, Web Storage APIs course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano demonstrates storage debugging tools, including Chrome, Firefox, and Safari dev tools. A student's question regarding how the quota for IndexedDB is decided is also covered in this segment.


Transcript from the "Debugging Tools" Lesson

>> I want you to go to that URL, okay? Open that URL in your browser You have a QR code there on the screen as well, in case you wanna take it from there. Any browser will work. I'm going to use Chrome, because it has the best debugging tools.

So this is the website, it's an open source website, you have the GitHub repo in case you wanna look at that. By the way, this website was created by the Chrome team. And it's a way that we have to actually play with all these storages and see how they look like, okay?

For example, here you can see my quota, that looks like a lot, right? I will explain why is that in a minute, that this website has used 5 megabytes, or maybe bytes, here it says megabytes, but anyway. And here I can try, I can store 1 megabytes on IndexedDB, so I can see how it's moving there, okay?

By the way, you can hit Fill, and that's adding 1 megabyte per second, or even half a second. The quota is for the whole origin, not just for one API. So let's say that it depends on the browser. I'm in Chrome right now, and in Chrome, it's actually a percentage of your hard disk space, okay?

We will see that in action in a minute. So if you hit Fill, you will start filling your hard drive. And if you open DevTools, I'm going to probably dock this to the right, there is a whole section for storage in DevTools within Application. So if you go to Application, there is a whole section for storage, okay, so the storage.

And by the way, I'm not sure why there is first a summary for the storage at the application level. So I'm not sure why it's not in the storage. So it's Application > Storage, okay? So if you go there, you will see the current quota and how much is actually being used by IndexedDB, Cache storage, or Service Workers.

That should match the data that the qeb app is giving us, okay? From here, you can clear all the data at once. So these are developer tools,okay? So this is a storage summary that we have in Chrome. And also we have a section per a storage. So here I have local storage, so I can see the keys and values, indexedDB, so I can see my databases.

And the data store, this is a actually random data, so this website is storing random data just to fill my disk, okay? Web SQL, I mean, still here. Cookies or, well, tokens, this has nothing to do with the storage data anyway, okay? It's something that is a store-client side, but it's not a storage API, okay?

So if you're using Firefox, you have something similar. So if I open Firefox, let me copy the URL. So if I open DevTools, okay, there is also a tab for Storage. So I mean the Storage tab, okay, where you can see IndexedDB, where I can see my databases, this is a database and this is a data store, and then the data, cookies, cache storage, With the data, local storage and so on.

We are going to use this with our project, so we're going to see in action how the data we are storing appears there. And Safari has also tools for this, but not for cache storage. So they also have a Storage tab where you can see cookies, IndexedDB, local storage, and that's all.

From here, you can see Application Cache, that's the one that we don't use, it's deprecated. Databases, that's WebSQL, Local Storage, Session storage, IndexedDB. But we don't have a tool for cache storage, that's the new cache storage API, the Webkit Inspector does not include that. So if you want to debug that in Safari, the only thing that we have is an extension available in the App Store.

So there is a free extension that will let you see the Service Worker and the cache storage as an extension, as a plugin for Safari, okay, make sense? So we are going to make use of these debugging tools a lot to see if the data is there, how it looks like, if it works, and we can see the data.

Something important, as we have just seen, all the data that we are storing is public to the user, okay? So we need to have that in mind. At any time, the user can go, not just the user, the native apps in desktop devices at least, I mean, a virus something like that, can actually read the data that the websites are storing, because the browser has that data somewhere in your hard drive.

But it's public to the user, anyone can see and change the data. Because with just the console, so I can go to any website, for example, here, my local storage is empty, but I can go to the console and try to store something in local storage, like "learning" "Frontend Masters".

So key value, and I will take, say, setItem, so I'm going to set the item learning with the value Frontend Masters. So now if I'm going to storages, Now I have local storage I can refresh it, let me [INAUDIBLE]. And here I have learning Frontend Masters. And I can change also from here, I don't even need to write JavaScript, okay?

And from here, I can clear the storage as well. So any user from any browser can open DevTools and do this, can see and change the data. And changing the data means that they can also break your data, because they can delete some part of the data. If you have a JSON, they can make the JSON invalid.

So there are many situations that might trigger conditions in your app that you need to consider and treat properly.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now