 So you could write your own service worker code, but we've actually got a few libraries that can help you out with this stuff. So I think when you start writing service worker stuff, you end up writing a lot of boilerplate to a certain extent. Like there's common patterns that I think everyone wants to do. The first one is everyone will have just static assets they're going to want to catch. Yeah, stuff that might make up an application shell, stuff that might be just like images and CSS and icons and so on. Yeah, things like logos are a great example where you'd probably want to catch them up front because they rarely change and you've got solid control over them and they're just always there. So for the first thing for that pre-caching step, there is service worker pre-cache and basically what that is, is it's a runtime step and all it does is you can basically do one or two things. Well, no, you can do two things with it. One of them is just glob for a certain set of files. You pass in a path and then you can basically say a rejects of like, well, I want anything in these directories that ends in .js, HTML, CSS or whatever you want and that is just, it will go find them and it saves them. But it also does file revisioning. Yeah, so changes to your build process will also update your service workers. You don't have to take care of file revisioning yourself. Exactly. And the nice thing with service worker pre-cache is it's super efficient. Yeah. So normally like when I think I first wrote my service worker, what I ended up doing was just saying delete the entire cache and create a new cache with almost all of the same assets apart from one that had changed. So service worker pre-cache will only update that one that is old and needs updating. Yeah. Super cool. And it's got good best practices built in, works really well on its own, but also if you're using Gulp or Grunt or whatever have you, it plays well with those as well. Yeah, exactly, because it's just a node module. The other thing that it does is you can say for this end point, so you might say for the home page, you can also say it's built up of these individual files. So templates, that's also super nice because again, it will cache the home page, but it won't change it until it's updated. Yeah. And service worker pre-cache uses a cache first approach to tackling things, so you always get like your assets served really, really fast. Yeah. So service worker pre-cache acts under the assumption that basically once you've cached something, you'll only ever get it from the cache. That's it. Until you do a new build, you release a new service worker, then it will get updated. But it's configurable enough to allow you to go and switch that up to network first or another strategy if you want. Super cool. The one thing that I would say everyone should check out is an option called handle fetch, which is an option on SWP pre-cache. And basically while you're developing, if you set that to false, you're basically saying, build me a service worker, but just skip the fetch event. And what that means is while you're developing, nothing's going through the service worker, which sounds kind of counterintuitive, but once you've set up pre-cache and it works, you really don't want to be using service workers at all. You just want it to skip and then you check it at another later stage. So that's awesome. Cool. So we've talked about a helper, a build time helper for dealing with sort of your shell, your static assets. What about runtime and dynamic content? So that's where you have toolbox. And what toolbox is, is you basically define a path so it can be like an express style route or it can be a regex. And then you either pass in a caching function that toolbox has or you pass in your own callback. And basically what that allows you to do is things like this. So you'd go toolbox.router.get. You'd pass in a regex. In this case, I'm going to say forward slash and you might find home screen equals true as query parameter. And for that, I want you to do toolbox.fastest. And in this case, toolbox.fastest is try the network and try the cache. And then whichever one returns first, give that to the browser. And the nice thing with it is the network will, once it's come back, will be stored into the cache. Just super nice. So it's good for like large or infrequently used resources? Yeah, exactly. Toolbox comes with a ton of different caching mechanisms. There, mechanisms out of the box. Network first, cache first, fastest, blah. There's a whole ton of them. But it's entirely geared towards just runtime caching. And it's kind of nice because you end up saying, for this path, do this thing, for this path, do this thing. Which you end up writing in your own service worker if you just did it all yourself anyway. Yeah, I've heard a few people say service worker involves a lot of boilerplate or it takes longer to learn. That wasn't my experience personally. But like using pre-cache in Toolbox, I found that a lot of the time it takes like, less than 20 or 30 minutes to get things set up. It's usually pretty nice. Like I wrote my service worker from my site on my own. It ended up with a couple of like random, weird issues. But it was useful for learning. But afterwards I realized that I could replace pretty much all of it with like six lines of Toolbox code. Which is kind of depressing, but at the same time, it's kind of reassuring that it's vaguely on the right path. So yeah, I'd say people should just check it out and give it a go. Yeah, it'll definitely save you time. So yeah, check out SW Toolbox, SW Pre-Cache and follow the links. We've also got code labs coming up about these tools. So check those out as well. Hit any issues, then raise them on GIMP.