Use Case Brainstorming

[00:00:00]
>> Kyle Simpson: So caching is kind of the major use case that you start with, usually with service workers, is I wanna do something different with the caching behavior than what normally happens with my files. That's what usually motivates you to say I'm gonna writing some of this routing logic for myself.

[00:00:18]
But caching is certainly just scratching the surface. If we think about the idea that we can intercept requests. I'm just gonna start brain storming here, but let's just brainstorm, what are some things that I could do. Imagine, if I could code the browser itself and make the browser do whatever I want with my web page, what would that look like?

[00:00:40]
What are things that I could do? Did you have an idea?
>> Student: You could do offline computing. So you could do work and then when you connect it saves.
>> Kyle Simpson: That's exactly right, and we're gonna talk a lot about that. So you could enable this offline usecase, that's both caching and then there's another API that's called background sync which we'll talk about later today.

[00:01:00]
And you could enable those sorts of things to do, if you've ever worked with Google Docs and you've been editing a spreadsheet or something and you were completely offline and then you came back online and it was all of a sudden had, all the resources have been saved.

[00:01:15]
Or you were able to open up a spreadsheet when you are offline even though you didn't open it before when you were online all that sort of stuff. That's definitely we can manage sort of offline ability. That's a great use case. Yeah.
>> Student2: I sit on the board of this organization called One Village Partners and they have workers they go out in the villages in Sierra Leone and they do work with the local villagers and record data.

[00:01:43]
And wanna be able to do that and come back with it, cuz they don't always have good internet connection out there, and they use a software package that requires the internet.
>> Kyle Simpson: Yeah, so if that software package were employing a service worker then it could be storing that kind of information.

[00:02:02]
I want to make it clear that we've had the ability to store data in web pages persistently, for decades. We've had local storage, we've had session storage. We've had index dB, which we're gonna talk about later and other web database stuff. So the idea of storing some data that's been collected somewhere in a web page is not new and it's not new to service workers.

[00:02:29]
But particularly what's new at the same time as we got service workers, is we now have this caching API. And by the way the caching API is not only exposed to your service worker. You can actually access the cache API from your web page. You won't be able to do nearly as much with it in a web page, because you're not doing the same kinds of request intercept that you're doing in a service worker.

[00:02:54]
That magic part isn't happening. But you could literally look in the cash inside of your web page, and see whether or not something was already cached. And because you have access to the cache API from your page before an outbound request has even gone out. That's something you can't do with a normal browser cache.

[00:03:12]
You don't know if something's cached. You can just request it and either get it or not. But now with cache API we can tell what's programmatically in there. Those are exactly right, so storing data, storing web resources like our HTML and CSS files, storing those in this offline ability way, that's a major primary use case of service workers.

[00:03:32]
Yeah?
>> Student: So, back to your point that, that existed though, you could do it, but I think to me the part that I'm interested in is the set it and forget it part, where I can do that and I don't have to remember to come back and sync it.

[00:03:48]
One of the things, like I said, I work for the U, and we want to do some kind of an app for check in, if there's an emergency, which would obviously heavily impact services. So for people that are off site or somewhere around the world for them to be able to check in but as intermittent services come in, the app could be checking and registering location.

[00:04:14]
>> Kyle Simpson: Yep.
>> Student: Versus them sitting in there and waiting. And waiting and waiting, it didn't work, didn't work, didn't work and we try. So to me that's the piece that I'm looking for is that fill in.
>> Kyle Simpson: So there's a bunch of nuance in what you just mentioned, some of which I'll briefly touch on here and some of which we'll touch on as we come back towards the end of the workshop.

[00:04:36]
So number one you mentioned the idea of capturing somebody's location. Only the web page can do that. And only if the user has actively granted access to geolocation. So a service worker does not have access to your location, and it can't track your location in the background. So for example, if somebody had GPS connection but didn't have a WiFi connection for some reason, then you could have captured their current GPS coordinate, and then saved that into local storage or index DB or something like that.

[00:05:12]
And then at a later time when you detect that they're online and they have a WiFi connection You could ajax that off to a server. But that won't be the same thing as saying where are they currently now, it'll only be saying where were they eight hours ago or whatever?

[00:05:27]
>> Student: Yeah, I'm not looking for that, I'm looking for an app that they would check in, that they would do it, or actively do a check in.
>> Kyle Simpson: Yeah.
>> Student: But maybe they don't have access so they can't, it doesn't get to us.
>> Kyle Simpson: It's just that location data is usually kind of time sensitive.

[00:05:41]
And the idea of background sync cuz you can't predict, it could be days or weeks before they were ever in a place where it just automatically kicked in. So the other thing about, so just just to make sure we're clear, there are use cases. In fact, the app that I was talking about that I built, I want to be able to track where my location is even if the app's not open.

[00:06:02]
That's a thing that you might wanna be able to do for convenience, not for annoyance or for privacy purposes, I just want, when I walk into a restaurant, I want it to pop up and say here's your notes from this restaurant. I wanna be able to notice my location and even if it's literally just me, I would like that option and that API literally doesn't exist right now.

[00:06:23]
Because of privacy concerns, your native apps on your Android or iOS devices, they have very limited capability of tracking your background location running in the background of various services. It's quite complex to build that and they haven't exposed that at all to the web layer, and they probably not ever gonna expose it to the web layer, cuz they're worried that websites will somehow abuse that sort of information.

[00:06:53]
So there are reasons why you might want to keep somebody's information about their location in the background, and that's just not possible right now. So from my app I'm considering having my web app have a helper native app that's installed that does the background tracking. And there's always a remote that data over to the web app or something.

[00:07:13]
But that's not a thing that the web platform has and may never have. People have asked for APIs like geofencing, which is saying, I don't wanna know exactly where somebody is, but can I pre-set some geometric coordinate that when they either enter or leave that area, I get notified.

[00:07:31]
And there was a proposal to have geofencing and then that was for all other privacy reasons also didn't happen that way. At least not exposed to the web layer. So understanding the limitations where somebody might be able to, it's not terribly common that somebody has GPS but doesn't have internet.

[00:07:52]
Usually if they don't have internet, they're not able to do the triangulation with the GPS. But if they're in that situation where for some reason they don't have WiFi but they do have a legitimate GPS coordinate, you could in theory store that, store it with a time stamp and then just the caveat that, hey, this data is three hours old, but at least we know three hours ago where they were, or something like that.

[00:08:15]
The other thing to understand about background sync, and we're going to get more into this again at the end, but in background sync that is basically saying to the service worker, I have a thing that I want to have happen and you can't complete it now. And it might be that we shut down the tab entirely, like the browsers, the tab is gone or whatever.

[00:08:36]
But in the background I want you to try to see whether or not I've come back online and make that request on my behalf even if the page isn't there. That's sort of the dream of this. Background sync is a spec and it's been in parts implemented in one browser.

[00:08:54]
It's not a reality across the web right now and it may never be, because there again or a bunch of potential ways that that could end up getting abused or whatever. But there's somewhat lesser forms of background sync like storing things persistently, so if they come back to it there data is still there.

[00:09:14]
And that's what we're gonna do, we're not gonna do background sync today. I just wanted to point out there are a bunch of caveats to this, I wish we had perfect everything. But we have to balance that against privacy and abuse concerns.
>> Kyle Simpson: Let me throw out some other ideas for what we could do if we were intercepting outbound requests from a website.

[00:09:35]
We can do transparent URL rewriting. So we can have a web page that's requesting an image from one location, maybe from one CDN, and the service worker might have decided that that CDN is down because another request failed, and it might rewrite it to a different CDN location.

[00:09:52]
And request it from there instead of from the place that was asked for. So then you didn't have to update the HTML, it was just sort of transparently load balancing the different CDNs. You can have programmatically created content that's responded to from the client. So for example, if you are offline and somebody makes an Ajax request to get some data, you might be able to just create an artificial JSON response from your code and your service worker and send it back to the web page and the web page won't know any different.

[00:10:26]
It'll think that it just got it from the server, but now it was data that was artificially constructed and sent back. Or you could have used a cached response to it like we talked about. So the idea of using cache means that when you're clicking around the user thing, it looks like I'm online, even if they're not online because they're still getting HTML and Ajax and all that other stuff back.

[00:10:49]
You can do even more sophisticated things. For example, if a web page requests a single file, let's say it requests a single image file, the service worker could say I know that because they requested that image file they're also likely to request these other things. So I'm gonna go head and request these other things on behalf of the page, get them primed and ready, so sort of a programmatic pre-fetching kind of thing that the web page doesn't even know is happening, but the service worker is doing in the background.

[00:11:22]
You could go even one step further. When they request a single image, you could actually force multiple resources to the page. So you could respond with the one image and then, because it's a worker, you could send a message to the page that tells the page to ask for more resources.

[00:11:39]
So that's like dependency injection. You've asked for this one thing, I know you need these other three things as well, so I'm gonna give you all four things even though you only asked for one. So, there's all kinds of sophisticated stuff that we can do when we have programmatic control over every outbound request from a page.

[00:11:57]
And there's probably a dozen others that we're not talking about here.