Service Worker Overview

[00:00:00]
>> So our PWA now works on iOS, it's still not working offline, but it looks good. So service workers, so far our PWA has As the heart man, not the brain, so we need to add the Service Worker. So native apps in the store or from the store, when you install an app from the store, you actually are downloading a big package, right?

[00:00:27]
So sometimes it's really big like a couple of gigabytes. So on that package, you will find all the resources place. Remember, I'm talking about native apps that you download from the store. Then that app can consume web services. And if you update the app, you need to update everything, the whole package again, that's native apps, okay?

[00:00:51]
And offline works because when you open an app, all the resources that are needed for rendering that app are actually on your device. That's why is tasked and that's why it's working offline. On classic web apps, in case you have experience doing websites and web apps, let me guess, you have, you download an HTML.

[00:01:12]
The user is typing a URL, clicking on the link and the browser downloads on HTML, then it downloads other resources on demand, mainly. And then the app can consume web services as you're used to. But offline doesn't work because if you're offline, there is no way to even download the HTML.

[00:01:33]
So you don't have ob=n device, all the resources that are needed to render in the app. So, but we are impressive web apps, we are in a different world. So in this case, it's a website, so we are still going to download an HTML, but that HTML will register something known as a service worker.

[00:01:59]
And that's a term that we have been mentioning many times during the day. That service worker can install client side resources. Then the browser will still download resources on demand as before. But now they can be served by the service worker also known as the local cache or by the real server.

[00:02:29]
Then the app can consume web services as usual, and now offline works, why? Because the service worker was installed. And the service worker installed all the assets, or at least many of the assets that are needed for rendering that app. That's why the service worker leads to an offline experience.

[00:02:52]
But what's a Service Worker? It's first a JavaScript file. So it's one js file. We can split that into several files, but we start with one. It has its own thread, so the code that we're writing in the file has its own thread. And it acts as a middleware.

[00:03:13]
So what's a middleware? A middleware is a piece of software that sits between two other actors. Like in this case, the server and the client. We have the browser, we have the web server. The service worker sits in the middle, and it's a middleware, meaning that I can remove it putting on everything should work anyway.

[00:03:37]
That's a view of middleware, it's like a plugin, if you want. So once installed, it can act as an installed local web server, or a web proxy. Let me repeat that. This is not like the official definition, let's say it's my definition. The service worker is a web server, web server that we installed client side.

[00:04:04]
So we install a web server but client side. Okay, so because it's a server, it can serve files so it's actually answering HTTP request as if it's a server. We're going to see this in action in a minute. But if you understand that idea, then you got the message of what a service worker is.

[00:04:28]
As well, let us serve all the assets or at least the assets that you want directly from the client. So it runs client-side within the browser's engine. So it's like a server, but anyway it's running in the browser's engine, which means if we will kill the browser's process, you're also killing the Service Worker.

[00:04:55]
HTTPS is required, so you cannot install or register as service worker if it's not a secure connection. The only exception to that is local host, and not just your local IP address, it must be the term local host in any port. So the service worker is installed by a web page, any HTML within for now, let's say your origin can install or register a service worker, the server.

[00:05:30]
It has its own thread and its own lifecycle, we're going to see this in action in a minute. And after it was installed, it can act as a network proxy, or local web server. In the name of the real server, this is also important. The service worker is kind of impersonating the real server.

[00:05:53]
So your webpage, your PWA, your JavaScript content will never know if the response is coming from the server or if the response is coming from the service worker, you don't know. And actually, you don't care, or you shouldn't care, because it's a middleware. If the service worker is there, it would probably enhance the experience.

[00:06:17]
And if it's not there, everything should work anyway, as usual. And the service worker has some abilities on top of what we know to run and execute code in the background. And the background means that you can close the app, you can close the browser stuff, but you can still execute code in the background, okay?

[00:06:40]
The service worker has its own life cycle with these abilities. Another thing that is actually important and if this is the first time you're hearing about service worker, it's a little scary. There is no need for user's permission, so when you get into a website that has a service worker, the service worker is installed silently.

[00:07:04]
You don't see any user permission dialog, it just works, it just been installed. Every service worker has a scope, a scope, it's a nourishing host and import, let's say a domain on a path. The path is optional, or it can be just the root folder, which means you can have the service worker owning the whole domain or owning just a folder in your domain.

[00:07:35]
Which also means you can have more than one service worker in your domain, if they areiIn different folders, that's the idea of the scope. So the service worker will manage all pages within the browser, I'm willing to install apps from that scope. So every HTML, every URL within your scope will be managed by that service worker.

[00:08:03]
So it can serve as server resources for that scope. Any page in the scope can install a service worker. So it's not like if I have indexed HTML and index to HTML. If index HTML is installing or registering a service worker, it will be for the whole scope, including index too.

[00:08:26]
After installed, then it will be able to serve all the files requested from the scope. So if the scope is requesting a PNG file, a CSS file or a web font, then it will be responsible. The service worker will be responsible for serving that resource in case it wants to, because it's a middleware.

[00:08:48]
If it's not there, or if the service worker says, you know what? I don't wanna deal with these requests, it will go to the real server anyway. Only one service worker is allowed per scope. But you can have more than one service worker in the same origin because in that case you have different scopes.

[00:09:11]
WebKit, that's Safari on the Mac, and also WebKit on iOS adds another layer of complexity here, I don't wanna get too deep here, but it has something known as partition management. With partition management, what happens is that, if you have iFrames, things are going to gets more complicated, okay?

[00:09:31]
The same happens with cookies and storage. So if you have been dealing with that, you probably know the deal. So the question is that if the service worker is replacing the server but client side, the answer is that it's one possibility. So it can impersonate the real server but client side, but you still need the real server, okay?

[00:09:57]
And so that's important, we are not replacing the server, okay? So it can go on top of the real server and like a middleware, and it can respond from in the name of the real server. But we always need the real server anyway. Because the service worker can make a different decision, or the service worker maybe has an exception, or is not working, or the user uninstalled the service worker.

[00:10:25]
And in that case, the request will go directly to the real server. So that's why I don't wanna say that is actually replacing it, okay? It's like working with, it's working with the real server to actually serve defies client side. So we have a question about installation. Can we defer the installation or registration of the service worker?

[00:10:50]
Or is this going to reinstall on the first load automatically? You decide when you register the service worker. So it's actually on a JavaScript API. So it depends on when are we calling the API is going to register the service worker immediately or later. So the most common scenario is to register the service worker as soon as possible, but there is no need for that.

[00:11:14]
And for example, when we have a large client side apps such as a big React app from a couple of megabytes, don't do that. But in case you have that, maybe we wanna defer the service worker registration after the app was loaded actually. Because you don't wanna mess with that already a slow process with the service worker registration