Check out a free preview of the full Build Progressive Web Apps (PWAs) from Scratch course

The "Serving All Assets" Lesson is part of the full, Build Progressive Web Apps (PWAs) from Scratch course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano walks through the cache first strategy, how to search for a request in the cache, and respond with a matching cached asset. If a matching asset cannot be found in the cache a fetch API request is then made.


Transcript from the "Serving All Assets" Lesson

>> So now our service worker is actually caching the files, but no one is using those files to serve them. So the thing is that here we don't have a simple straightforward API that says, go to the cache and serve that. So we each actually search into the cash manually.

So going back here, what we need to do for example in the case that is not the phase 0, we want to try and see if the request is cached. So to do that, we need to call the API manually. First, we need to open the cache. Remember that we were opening the cache with caches that open, that name we should create a constant for this name.

Then when I have the cache. I wanna search within the cache, so what I'm going to do is called much that's actually the name of the search function, match or match all. So match will try to find the first one. So we're going to match what, a request and the request is coming from event, request from our arguments.

So it's going to see if that request has an entry in the cache and that leads to another important piece of information. The cache storage API is a dictionary, with it's key being an HTTP request, and the value an HTTP response. So, in for example in local storage we save string, in index DV, we are saving ID object, here we are saving HTTP request, HTTP response.

So actually this is also a promise, so we get their response from the cache, we can call that cached response here. And if we have a response, actually, we can respond with that cached response. I'm not saying this code is correct, okay? But, I will try to guide you through the code.

In fact, this code is not correct. Let me explain why it's not correct. We cannot respond with in an async code, why is that? Because if the end of the function the fetch event handler is reached, then and no one has called respond with what will happen is that the browser will go directly to another network.

And if I tried to call respond with later I will get an exception. But if you remember, I mentioned that actually respond with accepts both a response or a promise of a response. So actually what I can do, I got both here so I can respond with this chain of promises.

And then I need to balance parentheses. So now, if I have a cached response and I will explain what that means in a minute, I'm going to return that cache responds to the promise chain, so actually, he will actually respond with that. Okay, it's a little weird. And here comes the part where I mentioned that it's a good idea, to actually be an expert in promises to actually understand better this code.

So, we're actually go into the cache and if there is a response, I'm returning with that response. So, the thing is, what happens if it's not in the cache so, I'm checking for a PNG file, and it's not there, so it's a cache miss. So in that case, we're going to receive an undefined object, so we are not going to receive the argument.

So it will go to the else. But some people will think that maybe we should capture catch like an exception? Well, that's not correct, because if I ask you to search for something in the library for a book in the library, and it's not there, so you come back and you tell me, hey, it's not there.

Actually, you could finish the process. You finished the operation, you search for the book and the answer is no, okay? That's different, than if you try to go to the library and it's locked with a key and you couldn't enter the room. In that case, that's a promise that fail, okay.

So in this case, it's not a failed promise. So it just the object is not there, and if it's not there, we return with a Fetch API. Be careful, this is not a fetch event, we have the fetch event and the Fetch API. This is the same API that we use to replace AJAX or XML HTTP request.

And we are going to fetch for that request that we have in event dot request. So in this case, if we are here, it's a cache hit. So it means it's in the cache, if not it's a cache miss, so we go to a network. This pattern that we have here, it's called cache first.

So, when the PWA or the browser needs a restart, we first check in the cache. If it's there, I will use that one. And if it's not there, I will go to the network so that's why it's called cache first, then network. Before actually testing this, something that I wanna add here when we are installing.

I mean this code works, and it will probably work most cases. But what happens, if you hear you're downloading a video file, that is one gigabyte. So, what happens with that? Mostly what happens? Because the service worker will actually be stopped after 40 seconds, so what happens if the videos are still downloading?

Well, we don't want that situation, so that's why typically we wrap this caches not open within a call to event. Wait until, so we can actually ask the browser to wait until something happens and we do that with wait until, that receives a promise. So it will wait until that promise is fulfilled.

In this case, it's asking the browser hey browser, please don't kill me because I will try to go on grab some fights. Again, if you don't have that, for most PWA's, it's not going to be a big deal because in 40 seconds everything should be lower. But just in case it's better to add event wait until So now we go back to chrome and we see if we have something different Back to chrome, I'm going to click update and reload the page but not the fake URL but the homepage.

I'm back here and yeah, I don't see any difference yet okay? So I should try the offline simulator and see if this is offline ready. So the question is what's the chance of getting a service workers tack on the client? So the thing is that it depends on the definition of or what can happen.

Actually if there is an exception in the service worker, what will happen is that everything will work without the service worker, so it will bypass the service worker. And that's why we're within the fallback. And, the only thing that might happen is that you are delivering a file that has some bugs.

We are backs, and the only the worst case scenario is that for a day, you will end up messing with your users. If you find that you have a problem and you upload a new version of the service worker to the server, it might take up to a day on some browsers, also known as Safari.

On Firefox and Chrome, it will take like a second reload to actually get that. But if you mess with the service worker file and the HTTP cache header, it may take up to a day, that's the longest that you can get that problem with you.

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