Service Worker Use Cases

[00:00:00]
>> Kyle Simpson: So let's turn our attention to service workers now that we have a good foundation with regular web workers. Quick note of housekeeping here. If you have not actually closed or stopped that server, you will want to do that before we start the next exercise and actually going to a Ctrl+C to kill that server from the previous exercise.

[00:00:24]
Okay, so what is a service worker? Well, a service worker is obviously a web worker. But as I talked about earlier, it's going to basically live on a different timeline or with a different sort of life cycle than your normal web worker. And in particular, what the service worker is doing, I think at some point, they contemplated calling it a network worker.

[00:00:53]
And that probably would have been a little bit more accurate. I'm not sure why they didn't go with that name. But a service worker is going to actually sit between your web application and the rest of the web. In other words, every single web request that happens, whether it's an image file in your HTML, it's a CSS file, it's a favicon.

[00:01:19]
Actually, technically, favicons don't in Chrome. That's a weird bug. But basically, every single request, whether it's a JavaScript file or it's AJAX calls, anything that happens. And that's not just to your own server, it's to anywhere, to any location. If there is a service worker installed, they're all gonna funnel themselves through the service worker first.

[00:01:44]
Now, the service worker doesn't have to do anything with any of those. If it doesn't listen for those incoming requests, then they just pass through untouched. So if you install a service worker that does not listen for outbound requests, then that won't interfere with any of that traffic.

[00:02:03]
But as soon as you start listening for those outbound requests, it's now entirely on you to make sure, if you want those to work, you have to make sure they get routed correctly. There's not really a way to tell the service worker, I don't care about this request.

[00:02:19]
You essentially have to act as a proxy. Once you start listening for outbound requests, your code basically has to act like a proxy that makes the request on behalf of the page. And when it receives the response, the response goes back to the page. So that basically ends up working like a pass-through, so you could do no logic around that.

[00:02:43]
But as soon as you install what's called a fetch handler in your service worker, all those requests are gonna funnel through your fetch handler and you're gonna have to add a minimum, make sure that those all go outbound. And there's an interesting little quirk here, which is if your page is requesting resources that are not on your domain, so they're not on your server's domain.

[00:03:06]
Your service worker is still bound by the rules of CORS, Cross-Origin Resource Sharing, which means if your service worker tries to do a fetch event, an AJAX call to a cross-origin location on behalf of a page. Say, in your page, you have an image tag loading to some image off some CDN somewhere.

[00:03:25]
That completely works normally on a normal image tag, regardless of what the CDN does or doesn't publish in terms of headers. As soon as that request is now routing through your service worker and your service worker is gonna try to make an AJAX call cross-domain to that CDN, now all of a sudden, that CDN has to publish CORS headers or it's gonna fail.

[00:03:47]
So the only way around that particular problem is you end up doing an opaque AJAX call, which is literally forwarding it and you don't get to see the response. And then it would allow it to go through the service worker machinery, but go back to the page without you seeing it.

[00:04:05]
So if you are going to send it and try to receive it back and do something with it, like cache it or any of that other stuff, then it has to be CORS-enabled for you to do that if its cross-origin. If you don't care about doing any sort of caching or anything in the service worker, you can do an opaque pass-through request, and then it'll go just fine even if it's in CORS.

[00:04:29]
But again, the setup, the mindset that we wanna have is that essentially, we are programming our own proxy that sits in the browser. As opposed to a proxy that sits on a server, this is a proxy that sits in the browser. You might ask yourself, why on Earth would I want to have a proxy for my website?

[00:04:51]
Those requests seem to work just fine for the last 25 years of the web. Why do we need to have a proxy involved? This is where your creative juices, you wanna get those going, because you wanna start thinking to yourself, what are things that I could do if I could program all of my network requests?

[00:05:11]
What are things that I might wanna do? At a bare minimum, and this is where we'll spend most of our attention here. At a bare minimum, a thing that you can do, and this is kind of the primary use case of a service worker, is to use an API that they added to the web platform at the same time as service workers, which is called the cache API.

[00:05:31]
And the cache API is a programmatic way of storing resource requests. Instead of relying upon the browser's underlying caching mechanism, this is a cache API that gives you complete control over what is or is not in the cache. You get access to what URL it's referred to. You can put contents in there.

[00:05:55]
You can make your own contents and stuff them into this cache, and then retrieve those from the cache, and later respond to them.