Cache Storage Overview

[00:00:00]
>> The next one is cache storage. Cache storage is part of the Service Worker spec but it's not tied to Service Worker, okay? So we can actually use this storage also from the window, from the global option. The idea here is that we can create different storages known as caches, okay, under a name similar to a database on IndexedDB, okay?

[00:00:25]
It's a name. Every cache store HTTP responses that includes headers and the body. So cookies, content type, every header that is coming from the server is stored as well as the body, so the meat. So exactly what we are saving, define, HTML, JavaScript, PDF, whatever, video files, whatever.

[00:00:49]
And the key is the HTTP request, okay? Typically we simplify that with a URL. So even we can use a simple key that that's just the URL, but it can be the URL plus other headers as well, okay? The API is asynchronous and by default, since it's beginning, promise based.

[00:01:13]
So we don't need to wrap the API, okay, to get promise and async await syntax. There is no permission needed from the user. We can store, update, delete, and query responses by URL or by request. While we typically use it within a Service Worker, it's also available in the Windows scope.

[00:01:36]
And now we're going to see an example of that, okay? So we are going to cache files. Common scenarios, so why do we have this API? By the way, before this API was available, we were using IndexedDB to store assets as well, like images, because we can store bytes.

[00:01:55]
So that's why we were using IndexedDB, but now we have cache storage. We can pre-cache assets, so we can pre-cache files that we will need later, web fonts, it can be sprites of a game, textures, whatever, anything. We can cache assets on the fly. So as soon as we are requesting an asset, we're also caching the asset.

[00:02:20]
So next time, we will have the assets ready. So we're not pre-caching, we are caching on the fly. We can serve these assets from a Service Worker, and that will improve performance and also offline access. I will explain that in a minute in case you are new to Service Worker.

[00:02:40]
And you can query assets available for offline usage. For example, this is an interesting use case of the cache storage API. You can store HTML files. Let's say you don't have a single page application, you have a multipage application, Wikipedia, okay? And let's say every article that you see is saved in cache storage, okay?

[00:03:03]
And then you go offline, okay? So how Wikipedia homepage knows which articles are available offline? Does it makes sense, because I'm the Wikipedia homepage. I'm offline. So I cannot offer the user all the Wikipedia articles, only the ones that were saved. Well, I can use this API to query about the HTMLs available and then I can do something with CSS or only put on the screen links to the articles that I know for sure that they are cached.

[00:03:39]
Make sense? Different use cases, we can create an offline page. Like I mentioned before, media, websites when you're offline, they give you a crossword. Well, where is that crossword? It was cached in the cache storage. Not just the HTML, the JavaScript, the fonts, the images, everything needed to render that content.

[00:04:02]
To serve resources, okay, typically we use the Service Worker, because the Service Worker can respond for every request the PWA make. I'm not sure if you know that. Have you ever played with Service Worker? Yes, yes, yes. Kind of a no. So the Service Worker, I will show you a diagram in a minute but actually sits in the middle between the network and the PWA or the website, and it can respond on the name of the server.

[00:04:33]
And because it has access to this API, it can go and grab it from there and serve it from there, okay? So it can serve from the cache, it can forward the request to the network or the Service Worker can even synthesize a response, can create a response on the fly.

[00:04:50]
Anything is possible here.