Service Worker & Offline

[00:00:00]
>> Mike North: Finally, let's turn this app into a progressive web app. So this is going to involve using a service worker. And a service worker, you can think of, as a second independent program that you install into your user's browser. When I say install, think like a mobile app.

[00:00:21]
It sticks there, and it'll live a long time. And one of the cool things about service workers is they can run in the background. They can intercept requests that your app makes, and potentially toss back some data. Or so they can give you a lot of options when it comes to caching strategies.

[00:00:43]
If you wanna learn more about service workers, Steve Kenny and I taught progressive web app course, that's available on Frontend Masters. And there's a new one coming out, a full day on service workers, that by the time this video is made should be available. Please send the raw video form.

[00:01:00]
So keep in mind these are powerful tools, but you can run into trouble sometimes. So you wanna think through it carefully or use a battle-tested solution that a large opinionated community has rallied around. And that is what we're going to do today. So step one is we're going to install a couple Ember add-ons.

[00:01:26]
First,
>> Mike North: ember-service-worker. And this is sort of a pluggable, a core functionality for service workers, that creates the right file and registers it and manages the service worker’s life cycle appropriately. We’re gonna install some plugins on top of this. So in order to cache the static assets that are present as a result of Ember's build process, and by that I mean anything that's in this dist folder, right?

[00:02:04]
This is what you would deploy, this is your build. We wanna install this plugin called ember-service-worker-asset-cache, right? So it knows which files were built, it knows how to download them, it knows that these files are meant to go together to form one cohesive app. We're gonna install ember-service-worker-cache-fallback,

[00:02:35]
>> Mike North: To cache API, get requests as we make them. Now we have a preference for fresh data, but if we lose our connection, we'll be able to pull stuff that we've already seen from this cache. Finally, we're going to treat index.html in a special way. Because as was pointed out earlier by one of your questions, a single page app in index.html, that requires some special treatment.

[00:03:02]
Because no matter, you can make a request in a variety of different paths, but they all have to kinda boot your single page app up. And the path portion of the URL is reserved for Ember's router. That is not a different HTML file, that's just a piece of state really.

[00:03:21]
So that's ember-service-
>> Mike North: worker- index. So we're gonna install all of those things and then we're gonna make a tiny tiny little bit of configuration. So you're gonna go to ember-cli-build, this is what defines your app's asset pipeline. And the only clue we have to give this collection of add ons is which URLs should it cache and fall back to if we lose Internet.

[00:03:50]
And those are gonna look like this. cache-fallback-
>> Mike North: And we'll say, patterns is anything that begins with API. I honestly don't know what syntax this is, I just know that this is what we want.
>> Mike North: So this looks like some Regex engine of some sort.
>> Mike North: Let's see what happens.

[00:04:22]
And I'm going to first show you Devtools and the service worker tabs, so we're going Application > Service Workers. Note that you don't see anything here, this is an indication that no worker is installed yet. So I'm gonna serve my app, it's gonna be served with fast boot.

[00:04:45]
>> Mike North: And we're gonna see as soon as the page loads, a worker gets installed, so this is activated and it's running. We can even take a peek into this cache storage, and see that the asset cache, it's holding all of the source maps, all of the JavaScript, all of the CSS.

[00:05:04]
So if I go and visit a couple of channels,
>> Mike North: So we'll visit Microsoft and everything at LinkedIn, and then if I were to go to this Service Worker tab and check Offline and Refresh the page, it still works. Now, these images didn't get cached, why? Because they're not part of that URL pattern where I said cache everything that begins with this URL.

[00:05:36]
Now, Dilbert got cached here, probably because of the normal HTTP caching that happens, that's sort of underneath the service worker. You could decide, well, realistically, we would host images in a predictable domain. But you could also decide that it's not critical enough that you need to render those.

[00:05:55]
Or you could have a fallback image that you always use, like always sends the standard 404 image, something like that. But we, because this is a single page app, we can change channels, we can go to the Microsoft team. So this app, if we were on an airplane, this would work.

[00:06:13]
I could even, tempting fate here, turn my WiFi off, and everything still works and I can load the page. Pretty nice, right? That's really easy for what typically it takes to set up a progressive web app. Yes sir.
>> Speaker 2: Doesn't localhost still work with WiFi off anyway?
>> Mike North: Local host-

[00:06:34]
>> Speaker 2: So that's not as much of a test as it looks like.
>> Mike North: Yeah. Good point.
>> Speaker 2: [LAUGH]
>> Mike North: Very good point. My API is localhost, but offline I trust that, that is really not letting us leave the browser.