Service Workers & Cache Storage

[00:00:00]
>> Service workers and cache storage. So does anyone know what a service worker is here?
>> A background JavaScript cache, I think, that can run.
>> It's a background JavaScript cache. Let's say, it depends on what you mean by background. It's not a cache, but the service worker can use a cache.

[00:00:28]
So it's a use case more than what's a service worker. So we have a service worker and then we have the cache storage. What you said is the service worker using the cache storage, not exactly what the service worker is. So a service worker is a JavaScript file.

[00:00:44]
I think I have the original definition here, but the service worker, it's a middleware written in JavaScript between your progressive web app or website and the servers and the cloud. It can be more things, it's actually a different thread, it's a worker, that's why it has its own life cycle.

[00:01:06]
There is a lot to talk about service workers, and I recommend you two workshops or courses in Frontend Masters. One from Kai Simpson on service workers, specifically. And the other one, the same I mentioned before on JavaScript in the background, we also cover the service workers there. But actually, it's something that you can install in users' devices for your website.

[00:01:32]
And next time the user is visiting your website, the service worker can actually act like the server. In fact, let me make you a quick and dirty definition of a service worker that is not 100% accurate, but you will get it pretty quickly in case you haven't heard about it before.

[00:01:52]
A service worker is a web server written in JavaScript that we install in user's device. So we are creating a web server and we are installing that web server locally in the user's device, in the phone or in the computer. So next time the user is accessing our website, instead of going to the real server, that is, in the cloud, that has the latency because the latency is here.

[00:02:22]
When we are going to the cloud, to the network, that's the latency. If we stay here, we are within the boundaries of the device. We are not going to the network, we don't have the latency. So the service worker is written in JavaScript and can serve files to the browser.

[00:02:39]
>> So you can also simplify down just being a caching middleware as well?
>> Yeah, you can, in this case, using that API, you have control of the cache. Instead of relying on the browser's cache, now you can have your own cache and serve your own files locally, okay?

[00:02:58]
If I hear, you have one use case, one design pattern for using service workers and cache storage. So you have a PWA or a website, remember a PWA has a website, that makes a request to the server, but there is a service worker installed. So the service worker will say, okay, let me search first in the cache.

[00:03:18]
The cache is a local storage available in the browser. If it's a cache hit, we respond to the browser with that response, if not, we go to a network. So if you think about this, this is similar to what I wrote over the browser's cache. It's kind of the similar algorithm, the difference is that this is written by us.

[00:03:40]
We have control of this algorithm, we write this in JavaScript. And a service worker will not help the first initial visit of your user, but it might help the next visits. Because the next time the user is getting into our websites, we can serve the files locally. It's like a local host on users' devices.

[00:04:06]
Do you have any question on that? It's kind of a new paradigm on the web that has been for a while now. Compatible with all the browsers, we are probably three or four years with all the browsers supporting service workers. But we are still far away from a lot of websites using it.

[00:04:29]
It's still some kind of a scary part of web development getting into service workers. And it can help a lot performance because it can improve web bid off a lot if we don't need to go to the network every time. Of course, there will be a lot of use cases where we still need to go to the real server on the network.

[00:04:52]
>> So it's not sending just a more compressed version to the same network, it's just not even touching it at all?
>> It's not even touching the network, and that's why using service worker, it's an API that will let you make an offline web, an offline capable web.

[00:05:07]
Because then even if you don't have connection, you can still serve the files locally. Okay, so it's a huge deal, that's why you have here in Frontend Masters a full course just on service workers. And there are also courses that are taking that topic.
>> Why do you think the adoption of service workers has been so slow?

[00:05:30]
>> I think the adoption of service worker is slow, first, because it's a new paradigm and it changes the whole scope. It's also not simple to implement, actually. So it's a low level API, so you actually need to understand what you're doing, or use library. In fact, Workbox is, for example, one of the libraries.

[00:05:57]
I still find myself getting a lot of developers that don't understand, maybe some of you that you didn't know what. I mean, you know that they were there, but I don't know exactly what that is, okay, haven't used it. So because it's so different from what we were used to use in the web space, it's a completely new paradigm.

[00:06:22]
I feel it's one of the reasons of why it's still slow. Also debugging with service workers, it's really painful, because now you are not hitting directly the server all the time. So sometimes you don't know which version you're rendering, is the one that is locally, I mean, you can control that.

[00:06:44]
But it feels like it's not so simple as with just files on my server that users are getting, and that's all. It's like you are creating copies of your server on millions of users and you feel you're losing control of what's going on there. So it's hard work, yeah, that's probably one reason.