0% found this document useful (0 votes)
42 views51 pages

Service Worker Internals: (@saket - KMR) & (@piyuesh23)

This document summarizes a presentation on service workers and caching strategies. It discusses how service workers can enable offline functionality, push notifications, and background processing for progressive web apps. It then covers registering a service worker, the install, activate, fetch and message lifecycle events, and basic caching strategies like caching the app shell and responses from the network. Finally, it discusses tools for debugging service workers and common use cases.

Uploaded by

myalexis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
42 views51 pages

Service Worker Internals: (@saket - KMR) & (@piyuesh23)

This document summarizes a presentation on service workers and caching strategies. It discusses how service workers can enable offline functionality, push notifications, and background processing for progressive web apps. It then covers registering a service worker, the install, activate, fetch and message lifecycle events, and basic caching strategies like caching the app shell and responses from the network. Finally, it discusses tools for debugging service workers and common use cases.

Uploaded by

myalexis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 51

Service Worker Internals

~{@saket_kmr} & {@piyuesh23}


Who we are?

@piyuesh23 @saki007ster
Technical Architect, QED42 UI/UX Lead, QED42
Agenda
● Mobile Web Vs Mobile Apps

● PWA & Service worker introduction

● Service worker dive-in

● Basic Caching strategies

● Tooling & debugging

● Demo
Mobile
Web V
S
Mobile
Apps
67% 33%
?
Tabbed Experience
Offline Enabled
Notifications

Simple
Notifications

Push
Messages
Branding
And Many More...
The Web is Dead

● 08/2010

● http://www.wired.
com/2010/08/ff_webrip/
The Web is Not Dead

● 02/2014

● http://www.wired.
com/insights/2014/02/web-
dead/
Progressive Web Apps

● Good Experience on flaky network


connections

● Fast Loading

● Obscure branding via splash screens

● Installable

● Push notifications

● 1-click away from accessing content


Introduction to
Service Workers
Features

Programmable
cache
Offline Web

Geo-fencing

Functional in
2G
Background
case of slow
processing
connections
EDGE
Push
Notifications
https-only
Pillars of SW
Working With
Service Workers
No service worker

Installing

Activate Error

Idle

Terminated Fetch / Message


Step 1: Registering a service worker
Check for Browser Support if ('serviceWorker' in Navigator) {
navigator.serviceWorker.register('/sw.js', {
scope: './'
}).then(function(reg) {
Scope for serviceWorker to
// registration worked
operate upon.
console.log('Registration succeeded. Scope is ' + reg.scope);
Default scope is set to the
location of sw.js file. }).catch(function(err) {
// Registration failed.
console.log('Registration failed with ' + error);
Navigator.serviceWorker. });
controller specified the }
worker controlling a page.
self.addEventListener('install', function(event) {
Install: pre-cache & app-
console.log('[install] Kicking off server worker registration.');
initialization
event.waitUntil(
// pre-fetch app-shell & perform initialization steps
);
App-shell: minimal HTML, });
CSS, and JavaScript powering
a user interface
self.addEventListener('activate', function(event) {
// Anything needed to be done before activation. e.g., cleanup old

Activate: Mostly useful in cache.


case of SW updates. });
Cleanup of old cache.
self.addEventListener('fetch', function(event) {
// Intercept requests going to Network.
// Mostly useful to return data from cache or cache
// network response.
});
Basic Cache-ing
Strategies
● Most useful for single page websites or
places where data/app are separate.
● Cache content offline while installing
service worker.
● Request gets served from Service
worker cache(when offline).
● Request served from internet(when
online) - caching response.
{
var cacheName = 'DCON NOLA';
var staticResources = [

App-Shell '/script.js',
'/style.css'
];
self.addEventListener('install', function(event) {
event.waitUntil(
Wait before activation until cache.open(cacheName).then(function(cache) {
app-shell is cached. return cache.addAll(staticResources);
});
);
})
self.addEventListener('fetch', function(event) {
navigator checks for the event.respondWith(serverFromCache(event.request));
network. returns true or });
false.
function serveFromCache(request) {
respondWith() receives caches.match(request).then(function(response)) {
only a valid response
return response;
object.
}).catch(function(err) {
return caches.match('/offline.html');
})
}
function serverFromNetwork(event) {
Fetch response from network &
update cache caches.open(cacheName).then(function(cache) {
return fetch(event.request.url).then(function (response) {
cache.put(event.request.url, response.clone());
Response object is a readable return response;
stream object & can be }).catch(function(err) {
consumed only once(either to return cache.match(event.request.url).then(function
update cache or respond back). (response) {
return response;
});
If something goes wrong with
the network fetch, respond back });
with a stale copy from cache. })
}
Got another custom scenario/Handling cache
busting...
Break down Css & Js assets var jsBucket = 'JS';
into different cache buckets. var cssBucket = 'CSS';

var cssResources = [
'/slides.css',
'/styles.css'
];

var jsResources = [
'/slides.js',
'/scripts.js'
];
self.addEventListener('install', function(event) {
Avoid overhead for sw.js check console.log('[install] Kicking off server worker registration.');
on each page using http cache- event.waitUntil(
control headers.
caches.open(cssBucket).then(function(cache) {
cache.addAll(cssResources);
});
caches.open(jsBucket).then(function(cache) {
cache.addAll(jsResources);
});
);
});
Activate fired after installing the self.addEventListener('activate', function(event) {
service worker and all the var cacheWhiteList = [jsBucket, cssBucket];
current versions of sw are
closed. event.waitUntil(function(caches) {
return Promise.all(
caches.map(function(cache) {
if (cacheWhileList.indexOf(cache) == -1) {
return caches.delete(cache);
Use event.replace() inside the }
install event for the installing
})
service worker to take effect
instantly. );
})
})
Browser Support

40+ 27+ 44+

Need to support a browser that isn’t


ready, Don’t worry we got you covered
Tooling
&
debugging
chrome://serviceworker-internals/
Local development without ssl-certificates

./Google\ Chrome --user-data-dir=/tmp --ignore-


certificate-errors --unsafely-treat-insecure-origin-as-
secure=http://dcp.16
Network requests
Chrome devtools
sw-toolbox: https://github.com/GoogleChrome/sw-toolbox
- navigator.serviceWorker.register('my-service-worker.js');

- global.toolbox.options.debug = true

// The route for any requests from the googleapis


origin
toolbox.router.get('/(.*)', global.toolbox.
cacheFirst, {
origin: /\.googleapis\.com$/
});
Common use-cases
Caching requests for authenticated users: fetch(url, {credentials: true}).then(function
(response){
// Request will be sent to the server with
cookies.
})

Caching cross-origin resources: fetch(url, {mode: ‘no-cors’}).then(function


(response){
// The response will be opaque i.e., we
would never know if
// the request was successful.
})
DEMO
Use-case:

- Drupal Camp Pune website


- Allow users to access the website offline
- Provide an app-like experience
- Allow users to add sessions to their schedule even when they are offline.
- Redirect pages that are not cached to an offline fallback page.
Drupal Enhancements: Cache-strategies:
● Offline first
- Custom route for returning lis to aggregated assets: /css- ● Network first
js-aggregated.json
● Slow connection:
- Custom route for adding/removing schedule flag: ○ Again offline first approach would fit in
/schedule/{entity_id}/{action}/{uid} here.
● Offline page:
- Rest endpoints for session & sponsor nodes: /sessions.
json & /sponsors.json ○ Redirect users to an offline page
showing some info about the event,
- hook_page_attachments_alter() to handle loading of
asking them to go online for viewing
service worker js & manifest.json(for PWA) files.
details
Resources



So How Was It? - Tell Us What You Think

Thanks!

You might also like