Google Chrome Dev Summit. Let's take a look at Service Workers!
Last week we attended Google Chrome Dev Summit. It is a conference hosted at the Google campus in Mountain View, CA. It is an opportunity for the engineers working on Chrome to showcase new features as well as receive feedback from the developer community.
The conference was a nice experience. I met a lot of interesting people and had a lot of fun. Actually it was my first time going to America and I really liked it. We we're staying in an older area of San Francisco with beautiful Victorian houses. The area is also famous for its graffiti.
I also had the opportunity to eat some really good food while there.
Two things in focus this year was Google's new design spec called Material Design as well as the new Service Worker API. Polymer, a JavaScript library used to create custom web components, was also discussed extensively.
I thought the Service Worker API looked really interesting so I will focus on that in this article. It is a new way to cache web pages to make them runnable offline. It can be used to cache the assets as well as the application data. Basically, it can be used to install a web application on a desktop computer or onto a mobile device.
This in conjunction with adding the web site to the Home screen can, as one of the Google engineers put it, make web apps more "appy". For native apps, being able to reach them directly from the home screen as well as running them offline is expected. Web apps, even if they really don't need an internet connection, often require one since the assets need to be downloaded.
Can I use Service Workers?
Actually, the API is still work in progress and isn't supported in any stable browser version yet. However, It's possible to play around with the API using the Firefox Nightly build as well as in Chrome Canary. Please see this page on how to activate service workers for your browser.
It actually didn't run very well in the latest version of Chrome Canary so I've been using the Firefox Nightly build while writing this article.
The API will be available in Chrome 41 which will be released early next year. This page shows the current state of implementation in all the major browsers.
How to create a Service Worker
The API is quite simple and using feature detection it can safely be added to an existing web application even though most browsers still don't support it.
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/my-app/sw.js', {
scope: '/'
}).then(function() {
console.log('Registration succeeded.');
}).catch(function(error) {
console.log('Registration failed with ' + error);
});
};
First we check if the Service Worker API is available. Then the navigator.serviceWorker.register() method is called to register the Service Worker. This method returns a promise. The first argument is a JavaScript file that will be downloaded and executed.
Using the Service Worker to cache assets
After the Service Worker has been registered an 'install' event will be triggered. So in sw.js we can listen for this event.
// sw.js
this.addEventListener('install', function(event) {
event.waitUntil(
caches.create('v1').then(function(cache) {
return cache.add(
'/my-app/',
'/my-app/index.html',
'/my-app/style.css',
'/my-app/app.js',
'/my-app/logo.jpg',
... // other assets that we might want to cache.
);
})
);
});
- The
caches.create(name)method will return a promise which resolves when the cache is created. The cache is named so when updating the application we can use a new version of the cache as well.
- Assets are added to the cache using
cache.add()
Using the cache
Now we've created a cache and populated it with all our assets. So how do we tell the browser to use our cache instead of doing a regular request to request the assets?
The Service Worker API also triggers a 'fetch' event when a resource is requested. The simplest way to use the caching is just to return the assets from the cache if they're present:
// sw.js
this.addEventListener('fetch', function(event) {
event.respondWith(
// this will respond with what is in the cache.
caches.match(event.request);
);
});
The caches.match() method returns a Promise that can be used to handle exceptions. In the following example the resource will be fetched with a regular request if it's not present in the cache.
// sw.js
this.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request).catch(function() {
return event.default();
});
);
});
It is possible to add resources dynamically to the cache as well. We can build up the cache gradually and save resources for when the application runs in offline mode. It's also possible to add resources from cross-site requests so we can even cache remote assets like content from a CDN.
Please see this page for more usage examples.
I think this is a nice API that's easy to use and gives us the ability to run web apps offline. As more and more native features become available we will be able to make more and more native-feeling apps running directly in the browser.
