Progressive Web Applications and Offline Introducing Service Worker

Transcript from the "Introducing Service Worker" Lesson

[00:00:01]
>> Steve Kinney: And with that epic buildup, I bring to you Service Worker. So far today, we've worked with a web worker. We've acknowledged the existence of shared workers, right? Just to remind you, a web worker is one frame or page per web worker. If you had multiple tabs open and you spun up a web worker, they would each get their own.

[00:00:20] A shared worker is a worker. If you have multiple tabs open to the same origin, they can all share that worker. Service Worker is a little bit different, right? And we've kind of danced around it, we've laid a bunch of building blocks. And now, we have arrived to really what makes most things that make a progressive web app a web app start with Service Worker.

[00:00:45]
>> Steve Kinney: Cool.
>> Steve Kinney: Service Worker
>> Steve Kinney: We spawned, could say a word, we spawned those web workers. And we spawned them and we could terminate them, right? In our main thread. The main thread was still the boss. Service worker, I think the verb I want you to think of is installed, right?

[00:01:04] And instal, if you think about other platforms, mobile platforms and applications, install should seem really interesting to you. I install stuff all the time on my phone. I install apps. Interesting. Now, that's an interesting thought to think. On that note, let's talk about caching. So how does it normally work?

[00:01:24] We can check with a server, right? And here, we can have a web application where there's an index dot HTML and it's super simple and it calls an app dot js and an app dot CSS and it has a fancy logo. And the problem with caching these resources is that they could've changed, right?

[00:01:41] You could've made some, let's say you had an app that had a shopping cart that was lie, and you decided to implement it, right? It would be cool if users had that feature, right? Or your important bug fix, or anything along those lines. So problem is app dot js, that app dot js could be something different, app dot css could be something different than it was before.

[00:02:03] We don't really know, right? So we have a bunch of ways that we can check. We can be like hey, check with the server to see if it's new, right? Let's see if it's like last modified tag is if it's after the one I currently have. There's all sorts of ways.

[00:02:16] And a lot of this involves just completely talking to the network a whole lot, has anything changed? I have this file, is it still the right file? I don't know, can you tell me? I'm feeling very insecure about this. And so we keep talking to the server, we keep trying to find out, the browser has cache, is that still the one we should use or not?

[00:02:35] That's one way. Another way that you'll see it a lot of times, and if you've worked with the Rails application, you'll see it. You saw it in web pack files, is what we do is we look at the contents of the file and we give it a unique name, right?

[00:02:51] So this HTML file is looking for app-ab4182c dot js. If Mike makes no changes, right, to that file, and we generate it again, it will be the same file, you will get the same fingerprint on it. You'll get ab4182c. Which means if your index.html was told for looking for app-ab4182c.js, it hasn't changed.

[00:03:13] Cuz it changed, it had a different number. If your index.html says go look for cdf, making up fake numbers on the fly is hard, 486, right? Well, that's a different file. We know not to load the one from cache. We're not even asking from the one you have in cache.

[00:03:29] Go get this fresh one, right? So every time the content of a URL changes, we know that is a different resource than it was before. And so, we can say stuff like hey, browser, hold on to this for a year. Now, you're getting the promises the browser will listen to you.

[00:03:45] But can tell the browser to do whatever you want. So we'll say hold on to this for a year. And as long as I'm asking for app-ab4182c, get me that one again, right? If you already have it stored locally, use that one. Don't fire a network request. But that all revolves on the index.html being the keeper of truth, right?

[00:04:07] The index.html has to say all right, I'm no longer asking for that original one. I'm now asking for a new one. Which means you know what you can't cache?
>> Speaker 2: Index.html.
>> Steve Kinney: Index.html cuz it is the keeper of truth, right? And I don't know a lot about the web, but I do know that you need to load an HTML file in order to have a web page, right?

[00:04:28] So there's some problems here as well. But if we have the page, we know that the resources exist. And again, as we saw before, we bake that checksum in there. These can be limiting, right? Timestamps and version change notifications are not enough.
>> Steve Kinney: There's no way for us to figure out what to do.

[00:04:47] We're basically saying hey, if I put everything this certain way, will you please behave the way I expect, right? And that is the theme we'll see at the very end of this workshop. Again, with a friend of no one called appcache, where you just say cache these things forever no matter what.

[00:05:07] And there is a narrow set of use cases where that works for you. And a large minefield of areas where it could accidentally blow up for you, right? Because okay, actually, we needed to change index.html, and appcache is like hold on to the one you have forever.
>> Steve Kinney: No longer forever, right?

[00:05:28] I didn't mean forever when I said forever.
>> Steve Kinney: Cool, and yeah, we'll talk a little more about Appcache in a little bit. Now, a few years ago, there was this idea of the extensible web manifesto. And the whole defined it which is hey, web standards people's. Rather than sitting on ivory tower and trying to come up an API that's gonna help us lowly developers, why don't you give us lower level access?

[00:05:57] We know the apps that we're building. Give us the kind of tools to figure out how to do stuff ourself and we will make the best decision for our applications, right? So to really, to think about offline can mean totally different things depending on what your application is.

[00:06:14] Like what parts should be offline? What parts should fail if there's no network? Maybe you don't say I charged your credit card if you literally didn't talk to the bank server, right? But you wanna put stuff in the cart for later? Into it, right? Offline can mean different things.

[00:06:27] And to have this one size fits all rule for how offline works, didn't work, right? So what we need is a high degree of customability, right? We have different needs, we need to do different things. And we need to do it based on not some bespoke new syntax, some bespoke manifest that is totally different from the things we're used to using.

[00:06:52] We have a really, really powerful programming language with some really, really powerful asynchronous constructs in it. Why don't you let us use that to access these lower level things to build the tools that we actually need? And again, the answer for that is our good friend Service Worker.