#FiveThings About Service Workers

#FiveThings About Service Workers


>>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.

Author:

One thought on “#FiveThings About Service Workers”

Leave a Reply

Your email address will not be published. Required fields are marked *