 So, before we get into the meat of my talk, I just returned from a city called Boston, where my office lives. So I work for Duck Yard, and yeah, I've been there for the past four weeks. I arrived there during the Orlando shootings, so this is pretty much the first thing I saw when I was in Boston. I brought some snacks for my Duck Yard people, but not everybody understood how they worked. The reason I was in Boston was Wicked Good Ember, which is our own version of an Ember conference, which was great, and the after party was awesome. Sorry, Tom. During my stay, I sampled over 100 different brews, which are great. And I've been to the Fourth of July parade and the Fourth of July fireworks, so I feel really American right now. I've been well-watching, and of course, I went to a ballgame, go Red Sox, but not everything was fun and games because, well, in America, likely the bets are too short. And a bird pooped on my Ember Kong swag bag. So into a political approach to service workers. So yeah, raise your hand if you know what service workers are, and I'm going to assume about everyone knows, has heard of them. And so keep your hands up, so if you know how they work a bit, like, you don't necessarily have to have worked with it, but like how they, if you have heard of it, have worked with it. So now keep them up if you actually wrote some service worker code. So there you go. Most hands. Okay. And who runs a service worker in production? So that's one person and one half. Okay. So that's not a lot. So let's see if we can improve that by making it just easy. So I'll define a service worker. And I got this from the W3C spec, so the words on the screen are probably gibberish. So it enables applications to take advantage of persistent background processing, which actually just means it runs separately from your document that you are seeing and it does not have or it can live longer than your browsing session. And it's an event-driven web worker which responds to events dispatched from documents and other sources, which roughly means that when you browse, things happen and the service worker can respond to it. And that's all it does. It's not like a program that's running in the background, it just responds to things you do in the browser and some external things. So which events are there? So you have install, which is when the service worker is first loaded. It goes to the install event. It gives you a chance to do things when it's installed. So you can, for example, download all the essential files for your app and cache them somewhere. The next time, it's quicker to load stuff. Then you have activate. And activate is when your service worker is installed and it's being used by the browser to handle events. And that last part is a distinction you need to remember when you're working with service workers. Then you have fetch. Fetch is when you make an HTTP request. So for example, Ajax and loading files like images all go through fetch when a service worker is active. You have message, which is actually post message, which gives you a generic way to communicate with the service worker and the other way around. You have push, which is one of the external events. So your backend server can send a message to your service worker to wake the service worker up and handle that notification from the server. And then you have sync, which you can use to synchronize data that you have stored locally in your user session when he comes back online while he wasn't before, for example. So let's look at some examples. So let's just take the Dockyard blog or the website, actually. So when you open it the first time, it installs the service worker. And when it's done, and for our website, it then just loads all the static assets and puts it in the cache. So when it's done downloading those files, it will activate. And when it's activated, then it will handle events. So for example, when you browse to another page, then it will send a request to the service worker. And the service worker can then forward the request to the backend server. It can cache it and then respond with it. And yeah, well, respond with it. So when a service worker is not for specifically one page, but if you have multiple things open at the same time, then the service worker will handle all of those things that are open at the same time with one service worker, not multiple ones. So that's also a thing to remember that there only is one service worker active at one time. So in the background, when you don't have anything open, you can send push notifications. So your server sends a push notification to your service worker. And then you can make a notification out of it. The other way around, when the browser is closed, but you were offline and now you get online, then you can do some tasks in the background. And that's, well, really handy for when someone is out in the city but has bad coverage and you don't want to waste his 3G data. So you say, like, when he's on Wi-Fi, just send over this super large file because we don't want to make his bill higher than needed. So a service worker enables you to build the next level of web apps, also known as progressive web apps. I recently learned that that's a Google store and I like this one better, instant web apps. So progressive web apps let you compete with native without a handicap, which is a good distinction to make. It's like the first time we actually, so without any handicap, we can build apps so we can do push notifications, we can do everything native apps can do and then a ton of more things that the web does better than native already. So yeah, if you're not convinced, my boss, Brian Cardorella, gives a talk about progressive web apps but then for the value proposition of it and his conclusion is PaaS will save you money. So I think he meant PWAs. So service workers in an AmberJS app, so there are a lot of ways to do it. So the first one is you can roll one by hand but roll one by hand is, yeah, not always ideal because your company can build one version but the other company builds another one and so everybody comes up with their own recipe and that's not really what you want. So the next one is Broccoli Service Worker. It was built over a year ago by Jay Klein's Meet and John Klein's Meet. It's a wrapper around Google Service Worker Toolbox which is just a bunch of code that does all the things you want to do with caching for you and you are configured by doing some stuff in the convict environment. So for example, you can say which URLs you want to pre-cache, which things you want to not cache, things you want to do network-first and though this seems really great, it's actually in my opinion not ideal because as you can see, if you want to do anything more than that the Service Worker Toolbox does, you have to add a file in SW, include files and then you're back to rolling your own thing and we are like magical unicorns. We always want something different. So I am introducing Ember Service Worker, which is a pluggable approach to service workers and what that means is that it does not have any batteries included and a good way to figure out or when you install Ember Service Worker, what you get is just a lot of boiler plates, things that will set up the Service Worker for you and have some middleware that helps you make better service workers but in the end when your app boots up and you start doing things, if you only have Ember Service Worker installed, nothing happens. So if you want something to happen, then you have to install plugins. So for example, you can Ember Install Ember Service Worker Assetcatch and my naming strategy for these things is really horrible but well it's simple. So Assetcatch just finds all the things in your desk folder, lists it out and on the install event it downloads all of them and puts in the cache so if you have a lot of assets then right now it's not that helpful because it will just download 20 megabytes of things in the background so I can improve that but yeah. So you can also, another one I made is the cache fallback so that's when something that's not cached it will first try to do a network request and then cache it and then the next time if you're offline or whatever then it has it in the cache and you can reuse it. So I'm going to make a prediction so with what I'm building so in a while I'm predicting that the ecosystem that's going to be built around it if it takes off so that's still a question that 90% of the use cases you have with service workers will be covered with little to no configuration you just do a few Ember installs and maybe one or two lines of configuration and you're done. And then the other 10% can be achieved by building private plugins but the thing is that when you build private plugins they are built on top of a lot of boilerplate codes so you don't have to write that for yourself and all those things are tested and work nicely of course. So a while ago like a little over a month I tweeted if I were to believe the daily Ember tips mailing list building an Ember JS app is no more than running some Ember commands on the terminal which back then I was like yeah that's stupid but then Lauren commented or replied you mean you don't Ember install my app and call it a day in which I said here I was writing all this code by hand turns out you just run a few Ember commands and you're done. So when it came around to when I was done with the proof of concept of Ember service worker I submitted a pull request to the dockyard website and this is all I had to do it's three lines in packages JSON so Brian responded whoa that's all needed and that's all that you need. So and this is not because I am awesome but this is because the dockyard community or the Ember community is awesome because yeah all things with Ember CLI and Ember itself we can just build things really quickly and ship them and tell everybody to Ember install your awesome thing and you're done so give yourself a round of applause. Yeah so in a year your UX designers in your company will just be building Ember apps with Microsoft front page so how do you build a plugin for Ember service worker well you start off with building or making a add-on and then you add the Ember service worker plugin keyword to package.json and after that you make a folder called service worker and in that service worker you add some code and if that can be just five lines or a lot of lines doesn't matter and after that you just do Ember release and MPM publish and then everybody can just Ember install your plugin and use it so that's quite easily so but right now it's not ready yet I'm sorry I wish I could tell you like to do try this all at home right now but instead I have to tell you do not try this at home yet and that's because well while implementing these things you get trolled by one of the classic computer science problems which is cache invalidation so I still need to tweak that a little bit and then I hope like in a month or a few months I can tell you like all just use this and we're going to build progressive web apps in five minutes so well I should have shown you that one so what's next what am what am I planning to do to make everything awesome so first right now you just write flat files there's no the Bible transpose transpilation no concatenation no module system so I'm planning on adding that first and if I'm done with that then I want to add some middleware and this middleware will help you overcome the problems with service workers so for example the fetch event once you call respond with no when something else calls respond with after it it will error in your console and well that's it's making race conditions for you so you want something that prevents you to do race conditions when when building isolated pieces of code so you need a little bit of middleware for that and thirdly I want to make something that makes service worker testing easy because it's not like right now it's like even harder than testing an ember app in the pre 1.0 series so the strategy I'm betting on is is like a very ambitious one which is trying to get q-unit to run within the service worker and then having it post message back to the q-unit in the document that you're viewing so it will tell the service worker to run this test and then the test will run in the service worker itself and then it will post message back it failed or passed so that's pretty ambitious if you ask me but I think it's the best way and that's why I think we should do that so well raise your hand again so Gavin raise your hand again if you work with service workers so I need you to help me build build this because I can't do this alone and everybody else who is interested not only Gavin is always welcome to help me out especially if you're interested in these things so my goal is to have at least a production ready solution before safari ship service worker so that's not too ambitious but it's at least achievable so that's all folks and yeah I hope I can help a lot of people build awesome apps soon