>> My son was singing this song this morning.
>> Yeah.
>> It's like, you're going to go record do,
do, do, do like, yes.
>> Do do do do do do do.
>> Hi, my name is John Papa.
>> I'm Craig Shoemaker.
>> Welcome back to Five Things.
This week we're going to about five things
about Service Workers. Craig.
>> That's me.
>> Yes. I almost called the camera man. Number one.
>> Number one. What are Service Workers?
>> What are Service Workers? Well, they are
a Javascript proxy that works within the browser.
>> Okay.
>> Operates independent of the UI thread.
So, it gives you an opportunity to kind of
deal with different fetch
requests that go out from the browser.
>> That's it?.
>> Well, I got more to say
in the next one. That's like the set up.
>> No. Number two,
why and when do I use these?
>> They're mostly used in
the context of progressive web apps,
and even than that,
you'll often find them used in offline context.
So the idea is that,
as you have a request that go out from the browser,
you can intercept that and then
return contents that you
might have cached in the browser.
As well as the technique of being able to keep
data in sync between different tabs
without an API like this is often very difficult.
So using service worker,
you can achieve things like that
and also, push notifications.
So you have an ability to allow
your web app to act a little bit
more like a desktop application.
>> So if I had a set of data that I commonly
use all over the place and then I really
don't have to enter the server every time.
>> Right.
>> Instead it's just storing a local variable which only
works in my current tab.
>> Exactly.
>> Like maybe a list of states or countries.
>> Right.
>> Get those, cache them,
then the Service Worker can say,
don't make, then recall, retrieve them.
>> Yes, exactly. The nice thing about it
is that there's restrictions about how
the Service Worker stays alive so that
you know for a fact that if you have multiple tabs open,
you're only hitting one version of the app.
>> Number three.
What about the life cycle of this Service Worker?
Like how does it stay alive?
How do you know when it's gone?
>> Well, the first thing that happens is when you
hit a page that registers a Service Worker,
it'll start installing the Service Worker.
At that point you enter into a phase where
it kind of waits to get a response.
You could reach out and grab assets like images,
CSS, Javascript, to cache on the browser.
You could hit like an Azure function and get
some compute happening and return data from there.
But whatever is happening
asynchronously, once it comes back,
then you'll be able to set it up and it will
be active and then it can take,
fetch requests from there.
Like I know on your website,
you've set it up so that
any image that's requested returned your head shot.
>> That's how we're doing this.
>> Yeah, that's right.
>> What if I want to expire the Service Worker?
How do I make sure of this new version I come across?
>> Well what you do is, you give it
a new key and then you
need to make sure that all the browser tabs are closed,
or you exit Chrome, or you completely
navigate away from the application.
Then once you come back to
it and it looks at the new key that comes in,
then you can install a new version of the Service Worker.
>> Okay. Sweet. Number 4.
What kind of restrictions
does a Service Worker put on my app?
>> The first one is it always needs to run
through SSL and that's
a really good thing because you can imagine that
with the type of power that's available here,
you don't want anyone getting in
the middle and getting up in your business.
The only exception to that is for localhost.
When you're developing on your local machine,
you don't have to worry about having
a local SSL client set up there.
That's the first part of it.
The next part is the second time
around is really when you're going to
see the Service Worker.
The first time you hit a page
that registers a Service Worker,
it's uncontrolled by the Worker.
So you need to navigate away or go
back to it in some other way and that's when
the Service Worker comes alive at that point.
>> Comes alive.
>> Coms alive. Just like the name in hindsight,
it's a worker so it exists in
a context that's away from the UI thread and so,
you don't have direct access to the dot.
Just like you can do with a web worker,
you're going to post and receive
messages between the two different items.
>> How can I make sure I set it up right?
>> One of the best ways is you can install Lighthouse
which is a browser extension that will go
through and analyze your Service Worker for a lot of
different aspects of the really progressive web app,.
>> Okay.
>> But it will hit much of what it has to do with
Service Workers and you can read
the reports and deal with it from there.
>> That's nice.
>> Yeah.
>> Number five. What about browser support?
>> Browser support is actually pretty good
even though it's a relatively new API.
All of your modern browsers
are going to include support for it.
If you go to Kause.com,
global support is reported at about 75%.
It's not the type of thing where we're going
to take for granted that everybody has it,
but the name of the game here really
is progressive web apps.
As long as your app works
without using the Service Worker,
that's a really good start and
then people can opt in the same.
Maybe they want to take your application off line.
Maybe they want to opt in to push notifications.
Depending on how you set up, it can work really well.
>> All right. Thank you.
>> Thank you.
>> My name is John papa.
>> I'm Craig Shoemaker.
>> We just learned five things about Service Workers.
>> He's got to go teething going on right now, right?
Which I haven't seen with one though before.
>> Yeah.
>> He seriously gets
self-conscious about looking like me.
>> Really?
>> Sorry. We did a talk together.
He put a wig on just to do it and see the difference.