In production, our static files are served via Akamai (but on our domain), including our service worker.
By default we're caching the service worker but it doesn't seem to always be getting updataed.
What is the right strategy here? Should we set the service worker not to be cached ever and take a hit for every call in the service worker to pull the new service worker each time?
The service worker, if there's a new one, should be updated at least every 24 hours, even if you set 'max-age' to a value greater than 24 hours: https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md#updating-a-service-worker
The browser will check if there's an update on every page load, but will obey the cache. So you can use 'max-age' to decide how often you want the browser to check for updates.
Related
I'm playing with the service worker API in my computer so I can grasp how can I benefit from it in my real world apps.
I came across a weird situation where I registered a service worker which intercepts fetch event so it can check its cache for requested content before sending a request to the origin.
The problem is that this code has an error which prevented the function from making the request, so my page is left blank; nothing happens.
As the service worker has been registered, the second time I load the page it intercepts the very first request (the one which loads the HTML). Because I have this bug, that fetch event fails, it never requests the HTML and all I see its a blank page.
In this situation, the only way I know to remove the bad service worker script is through chrome://serviceworker-internals/ console.
If this error gets to a live website, which is the best way to solve it?
Thanks!
I wanted to expand on some of the other answers here, and approach this from the point of view of "what strategies can I use when rolling out a service worker to production to ensure that I can make any needed changes"? Those changes might include fixing any minor bugs that you discover in production, or it might (but hopefully doesn't) include neutralizing the service worker due to an insurmountable bug—a so called "kill switch".
For the purposes of this answer, let's assume you call
navigator.serviceWorker.register('service-worker.js');
on your pages, meaning your service worker JavaScript resource is service-worker.js. (See below if you're not sure the exact service worker URL that was used—perhaps because you added a hash or versioning info to the service worker script.)
The question boils down to how you go about resolving the initial issue in your service-worker.js code. If it's a small bug fix, then you can obviously just make the change and redeploy your service-worker.js to your hosting environment. If there's no obvious bug fix, and you don't want to leave your users running the buggy service worker code while you take the time to work out a solution, it's a good idea to keep a simple, no-op service-worker.js handy, like the following:
// A simple, no-op service worker that takes immediate control.
self.addEventListener('install', () => {
// Skip over the "waiting" lifecycle state, to ensure that our
// new service worker is activated immediately, even if there's
// another tab open controlled by our older service worker code.
self.skipWaiting();
});
/*
self.addEventListener('activate', () => {
// Optional: Get a list of all the current open windows/tabs under
// our service worker's control, and force them to reload.
// This can "unbreak" any open windows/tabs as soon as the new
// service worker activates, rather than users having to manually reload.
self.clients.matchAll({type: 'window'}).then(windowClients => {
windowClients.forEach(windowClient => {
windowClient.navigate(windowClient.url);
});
});
});
*/
That should be all your no-op service-worker.js needs to contain. Because there's no fetch handler registered, all navigation and resource requests from controlled pages will end up going directly against the network, effectively giving you the same behavior you'd get without if there were no service worker at all.
Additional steps
It's possible to go further, and forcibly delete everything stored using the Cache Storage API, or to explicitly unregister the service worker entirely. For most common cases, that's probably going to be overkill, and following the above recommendations should be sufficient to get you in a state where your current users get the expected behavior, and you're ready to redeploy updates once you've fixed your bugs. There is some degree of overhead involved with starting up even a no-op service worker, so you can go the route of unregistering the service worker if you have no plans to redeploy meaningful service worker code.
If you're already in a situation in which you're serving service-worker.js with HTTP caching directives giving it a lifetime that's longer than your users can wait for, keep in mind that a Shift + Reload on desktop browsers will force the page to reload outside of service worker control. Not every user will know how to do this, and it's not possible on mobile devices, though. So don't rely on Shift + Reload as a viable rollback plan.
What if you don't know the service worker URL?
The information above assumes that you know what the service worker URL is—service-worker.js, sw.js, or something else that's effectively constant. But what if you included some sort of versioning or hash information in your service worker script, like service-worker.abcd1234.js?
First of all, try to avoid this in the future—it's against best practices. But if you've already deployed a number of versioned service worker URLs already and you need to disable things for all users, regardless of which URL they might have registered, there is a way out.
Every time a browser makes a request for a service worker script, regardless of whether it's an initial registration or an update check, it will set an HTTP request header called Service-Worker:.
Assuming you have full control over your backend HTTP server, you can check incoming requests for the presence of this Service-Worker: header, and always respond with your no-op service worker script response, regardless of what the request URL is.
The specifics of configuring your web server to do this will vary from server to server.
The Clear-Site-Data: response header
A final note: some browsers will automatically clear out specific data and potentially unregister service workers when a special HTTP response header is returned as part of any response: Clear-Site-Data:.
Setting this header can be helpful when trying to recover from a bad service worker deployment, and kill-switch scenarios are included in the feature's specification as an example use case.
It's important to check the browser support story for Clear-Site-Data: before your rely solely on it as a kill-switch. As of July 2019, it's not supported in 100% of the browsers that support service workers, so at the moment, it's safest to use Clear-Site-Data: along with the techniques mentioned above if you're concerned about recovering from a faulty service worker in all browsers.
You can 'unregister' the service worker using javascript.
Here is an example:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.getRegistrations().then(function (registrations) {
//returns installed service workers
if (registrations.length) {
for(let registration of registrations) {
registration.unregister();
}
}
});
}
That's a really nasty situation, that hopefully won't happen to you in production.
In that case, if you don't want to go through the developer tools of the different browsers, chrome://serviceworker-internals/ for blink based browsers, or about:serviceworkers (about:debugging#workers in the future) in Firefox, there are two things that come to my mind:
Use the serviceworker update mechanism. Your user agent will check if there is any change on the worker registered, will fetch it and will go through the activate phase again. So potentially you can change the serviceworker script, fix (purge caches, etc) any weird situation and continue working. The only downside is you will need to wait until the browser updates the worker that could be 1 day.
Add some kind of kill switch to your worker. Having a special url where you can point users to visit that can restore the status of your caches, etc.
I'm not sure if clearing your browser data will remove the worker, so that could be another option.
I haven't tested this, but there is an unregister() and an update() method on the ServiceWorkerRegistration object. you can get this from the navigator.serviceWorker.
navigator.serviceWorker.getRegistration('/').then(function(registration) {
registration.update();
});
update should then immediately check if there is a new serviceworker and if so install it. This bypasses the 24 hour waiting period and will download the serviceworker.js every time this javascript is encountered.
For live situations you need to alter the service worker at byte-level (put a comment on the first line, for instance) and it will be updated in the next 24 hours. You can emulate this with the chrome://serviceworker-internals/ in Chrome by clicking on Update button.
This should work even for situations when the service worker itself got cached as the step 9 of the update algorithm set a flag to bypass the service worker.
We had moved a site from godaddy.com to a regular WordPress install. Client (not us) had a serviceworker file (sw.js) cached into all their browsers which completely messed things up. Our site, a normal WordPress site, has no service workers.
It's like a virus, in that it's on every page, it does not come from our server and there is no way to get rid of it easily.
We made a new empty file called sw.js on the root of the server, then added the following to every page on the site.
<script>
if (navigator && navigator.serviceWorker && navigator.serviceWorker.getRegistration) {
navigator.serviceWorker.getRegistration('/').then(function(registration) {
if (registration) {
registration.update();
registration.unregister();
}
});
}
</script>
In case it helps someone else, I was trying to kill off service workers that were running in browsers that had hit a production site that used to register them.
I solved it by publishing a service-worker.js that contained just this:
self.globalThis.registration.unregister();
I'm recently implement a service workers on our site with workbox. Due to the structure of our project we're implementing a service worker for each page for instance:
/foo/XXX/
/foo/XYZ/
/foo/XXY/
This is causing that we're creating a service worker for each page.
On the other hand, we're using precaching in our build process in order to precache css and js assets.
I know workbox creates two caches, one for precaching and the other one for the runtime. Becuase we have several service worker our customer have a new cache entry when they visit a new page
workbox-precache-https://www.example.com/foo/XXX-https://www.example.com
workbox-precache-https://www.example.com/foo/XYZ-https://www.example.com
workbox-precache-https://www.example.com/foo/XXY-https://www.example.com
I know workbox provides an option to set the name for the cache.
workbox.core.setCacheNameDetails({
prefix: 'my-app',
suffix: 'v1',
precache: 'custom-precache-name',
runtime: 'custom-runtime-name'
});
My question is, can I use this option to set the cache name as unique ? My approach is that all assets are in the same cache so workbox will be in charge to delete duplicated and manage the cache. Does it make sense?
Thanks a lot
If you call workbox.core.setCacheNameDetails({suffix: 'my-suffix'}) at the very start of your service worker script, and you do that for each service worker registered on your origin, that would be enough to have all of the service workers use a common cache for their precached assets. (Normally the scope of the currently service worker is used as the suffix, to prevent collisions and ensure that each service worker got its own cache, so you'd be overriding that behavior.)
But... I'd be hesitant to actually do this, or at least to test thoroughly before you do, as you're opening yourself up to possible issues. Some things that I'd worry about:
Normally, the install and activate service worker lifecycle events are used to trigger downloading new assets (install) and deleting out of date assets (activate). The activate step will, by default (unless you're using skipWaiting) not fire until after all tabs with active clients are closed, to ensure that nothing is deleted which is still being used by a tab. If you have multiple service workers, each with their own scope and their own lifecycle events, managing the same cache using precaching, then one service worker's activate event might fire while a tab is open still controlled by a different service worker. This could cause entries to be deleted from the precache when they still might be used by that second tab.
I'd be worried about any relative URLs in your precache manifest, as each of those relative URLs would be resolved using the location of the current service worker as the base. If each of the paths of your site have different URL structures, or if /foo/XXX/app.js is fundamentally different than /foo/XYZ/app.js, then an entry of ./app.js in a precache manifest will end up being pretty dangerous if you share a single cache.
What I'd recommend as an alternative, if you really can't go with a single, higher-level service worker, is not to force all the precached assets into a single cache but instead maintain separate, potentially smaller precaches for each service worker, and then use runtime caching with a common cacheName parameter to share the resources that you know are common. I think that's much less likely to be error prone.
Suppose I provide a push notification service used by different websites. This service requires a service worker to be installed on my customers' sites. I want the architecture to have a few properties:
Completely static resources. The process of installing the service worker files and configuring the JS snippet, etc. only needs to be done once.
The ability to update the service worker at any time. I want to be able to update the service worker at any time to fix bugs, deploy improvements, etc.
Satisfying both of these constraints is difficult because the browser only installs a new version of the service worker if the content of service worker script itself changes. (That is, without considering dependencies specified via importScripts().)
If you can't change the contents of service worker itself, consider creating a "new" service worker by appending a hash to the service worker URL. This will cause the browser to install the "new" service worker every time the hash changes.
That is, replace code like
navigator.serviceWorker.register("/sw.js");
with
navigator.serviceWorker.register(`/sw.js?hash=${HASH}`);
When the "new" service worker is installed, the browser will re-check all imported scripts. (This applies even if the "new" service worker is byte-for-byte identical to the "old" one, because the URLs are different.)
How to generate the hash?
There's a few different ways to generate the hash. A completely random HASH will lead to the browser updating the service worker on every page load, which is unlikely to be what you want.
Two different approaches:
(Best) You know when the imported script changes. In this case, only change HASH when the imported script changes. Ideally, HASH would be a hash of the contents of the imported script itself.
(Okay) Derive the hash from the time. Math.floor(Date.now() / (3600 * 1000)) will cause a "new" service worker to be installed every hour, which will also result in the dependencies being checked. (You'll probably also want to apply some jitter to avoid all clients updating at the same time.)
Suggested architecture
If you provide a service-worker backed service to other websites (e.g. a push notification service), you can provide a completely static service worker and JS install snippet to your customers which allows you to control and trigger updates completely from your site.
Code for customer.com (all static):
JS snippet for customer to include on all HTML pages their site (static):
<script src="https://provider.com/register-sw.html?customer_id=8932e4288bc8">
</script>
Service worker for customer to install at https://example.com/sw.js (static):
importScripts("https://provider.com/imported-sw.js?customer_id=8932e4288bc8");
Code for your site (can be dynamic):
Service worker registration code on your site at https://provider.com/register-sw.html?customer_id=8932e4288bc8 (dynamic):
const HASH = hash_of_file("imported-sw.js");
navigator.serviceWorker.register(`/sw.js?hash=${HASH}`);
"Real" service worker on your site at https://provider.com/imported-sw.js?customer_id=8932e4288bc8 (dynamic):
// when service worker is updated, all clients receive
// update because service worker itself is "new"
self.addEventListener(...);
NOTE: The byte-for-byte requirement is in the process of being changed so that this check extends to imported scripts by default (not just the registered URL itself), but as of April 2017 no browser implements this behavior.
I am using service worker to implement web push notifications. Whenever I change some code of service-worker, that change is not reflected in service-worker on browser unless I delete cookie/cache.
Is this normal behaviour or I have to add some function to update service-worker?
Service worker files are cached for a Max of 24 hours if the cache header is sent with the service worker file.
First step is to set the cache headers to 0 to not cache.
When a browser finds a new service worker it will download and install it. It won't take affect until all pages that are currently controlled by the service worker are closed. For a normal user this isn't a problem. During development in chrome you can use Ctrl+ shift + R to do a hard refresh which forces a page not to be controlled by service worker, allowing your be service worker take control on the next refresh.
Final option is to use skip waiting in install step and claim in the activate step to force a new service worker to instantly activate and control any pages. If earn against this as it's easy to get into weird scenarios.
Update: Browsers are changing this default behavior - Firefox will now ignore the cache header and other browsers are likely to implement the same behaviour
To answer your specific question: yes, the behaviour is intentional and yes, yo can call an update function. Use update() method on the service worker registration. From MDN:
The update method of the ServiceWorkerRegistration interface attempts to update the service worker. It fetches the worker's script URL, and if the new worker is not byte-by-byte identical to the current worker, it installs the new worker. The fetch of the worker bypasses any browser caches if the previous fetch occurred over 24 hours ago.
Notice it says the SW fetch will bypass any browser cache if the previous fetch is older than 24h so you should disable caches while developing service workers.
I have deployed a Rails app at Engineyard in production and staging environment. I am curious to know if every HTTP request for my app initializes new instance of my Rails App or not?
Rails is stateless, which means each request to a Rails application has its own environment and variables that are unique to that request. So, a qualified "yes", each request starts a new instance[1] of your app; you can't determine what happened in previous requests, or other requests happening at the same time. But, bear in mind the app will be served from a fixed set of workers.
With Rails on EY, you will be running something like thin or unicorn as the web server. This will have a defined number of workers, let's say 5. Each worker can handle only one request at a time, because that's how rails works. So if your requests take 200ms each, that means you can handle approximately 5 requests per second, for each worker. If one request takes a long time (a few seconds), that worker is not available to take any other requests. Workers are typically not created and removed on Engineyard; they are set up and run continuously until you re-deploy, though for something like Heroku, your app may not have any workers (dynos) and if there are no requests coming in it will have to spin up.
[1] I'm defining instance, as in, a new instance of the application class. Each model and class will be re-instantiated and the #request and #session built from scratch.
According to what I have understood. No, It will definitely not initialize new instance for every request. Then again two questions might arise.
How can multiple user simultaneously login and access my system without interference?
Even though one user takes up too much processing time, how is another user able to access other features.
Answer to the first question is that HTTP is stateless, everything is stored in session, which is in cookie, which is in client machine and not in server. So when you send a HTTP request for a logged in user, browser actually sends the HTTP request with the required credentials/user information from clients cookies to the server without the user knowing it. Multiple requests are just queued and served accordingly. Since our server are very very fast, I feel its just processing instantly.
For the second query, your might might be concurrency. The server you are using (nginx, passenger) has the capacity to serve multiple request at same time. Even if our server might be busy for a particular user(Lets say for video processing), it might serve another request through another thread so that multiple user can simultaneously access our system.