I have an app that runs service worker. I'm using sw-toolbox library for dynamic caching of URLs, but I want to create wrapper over sw-toolbox that provides getters and setters to my application for URL caching.
As service worker runs in different thread and my application running in main thread, so just wondering how to create a wrapper in Javascript through which my application can communicate with service worker and cache resources on-demand?
So far the Cache api is available from content, that means you can use it directly from your Javascript code, no need to run in the Service Worker.
Check this thread to find the resolution: https://github.com/slightlyoff/ServiceWorker/issues/698 You will be able to use caches from the window object.
Meaning you have all range of Cache methods to play with the content: https://developer.mozilla.org/en-US/docs/Web/API/Cache
Just another reminder, from Chrome 46, you will be able to store stuff just in secured origins.
From the Documentation, Cache API/interface is exposed to windowed scopes as well as workers.
You don't have to use it in conjunction with service workers, even
thought it is defined in the service worker spec.
It depends how your worker caches data, it it just uses the standard "Cache" API than you can just query cache object which is attached to global scope.
In this particular case Cache.match() is your friend.
Related
When creating a react app, service worker is invoked by default. Why service worker is used? What is the reason for default invoking?
You may not need a service worker for your application. If you are creating a project with create-react-app it is invoked by default
Service workers are well explained in this article. To Summarise from it
A service worker is a script that your browser runs in the
background, separate from a web page, opening the door to features
that don't need a web page or user interaction. Today, they already
include features like push notifications and background sync and have
ability to intercept and handle network requests, including
programmatically managing a cache of responses.
In the future, service workers might support other things like
periodic sync or geofencing.
According to this PR to create-react-app
Service workers are introduced with create-react-app via
SWPrecacheWebpackPlugin.
Using a server worker with a cache-first strategy offers performance
advantages, since the network is no longer a bottleneck for fulfilling
navigation requests. It does mean, however, that developers (and
users) will only see deployed updates on the "N+1"
visit to a page, since previously cached resources are updated in the
background.
The call to register service worker is enabled by default in new apps but you can always remove it and then you’re back to regular behaviour.
In simple and plain words, it’s a script that browser runs in the background and has whatsoever no relation with web pages or the DOM, and provide out of the box features. It also helps you cache your assets and other files so that when the user is offline or on slow network.
Some of these features are proxying network requests, push notifications and background sync. Service workers ensure that the user has a rich offline experience.
You can think of the service worker as someone who sits between the client and server and all the requests that are made to the server pass through the service worker. Basically, a middle man. Since all the request pass through the service worker, it is capable to intercept these requests on the fly.
I'd like to add 2 important considerations about Service Workers to take into account:
Service Workers require HTTPS. But to enable local testing, this restriction doesn't apply to localhost. This is for security reasons as a Service Worker acts like a man in the middle between the web application and the server.
With Create React App Service Worker is only enabled in the production environment, for example when running npm run build.
Service Worker is here to help developing a Progressive Web App. A good resource about it in the context of Create React App can be found in their website here.
I'd like to use two service workers on my site: one to provide a classic offline cache (/sw.js) for my PWA and another for something like a local database "server" which uses background sync and push (/sw-db.js). Since the latter tends to do heavy work (blocking the event loop for a few ms) it's better to keep it separate.
Since the database sw is not used for fetch requests, I would give it a dummy scope, whereas sw.js is scoped for the whole domain.
Does the first, which responds to "fetch" events, also serve the code/URL for /sw-db.js (keeping it somewhat in-sync with site updates) or are service workers always updated via network.
The sw.js script URL that you pass in to navigatior.serviceWorker.register('/path/to/sw.js') will always be fetched bypassing any other service workers when it's time to check for updates. So to answer your question, the other service worker's fetch handler won't be triggered.
The HTTP cache does come into play whenever there's an update check for a service worker script. So you should make sure you're setting proper HTTP cache control headers for your use case.
Usually, a service worker update check is triggered due to a navigation to a page controlled by a service worker, but if you have a service worker with a "dummy" scope, it won't end up controlling any pages. That being said, when a service worker handlers sync or push events you'll also end up triggering the update check. I'm not sure if every sync or push triggers the check, or just a subset of them, such as the ones which cause a new service worker to spawn. But it will happen at least some of the time.
In progressive Web App using the service worker the request given is stored in the cache memory. If the content updated in the server whether the same content in the cache memory will updated, how it happens?
Check out Jake Archibald's article on caching strategies and service workers. I think this is exactly what you are looking for.
Also note that sw-precache, a tool for generating service workers, will hash your cached content automatically and likely solve some caching issues for you.
Is there any way I can access the chrome.* apis (specifically chrome.history) from a Web Worker?
If I pass the chrome.history or chrome object in with postMessage, it is not working because of a conversion error to Transferable type.
I can successfully query the history from my extension and pass the results, but I would like to leave the heavy lifting to the worker instead of the main thread and then pass the results.
Web Workers are meant to be light-weight, and do not inherit any permissions (not even host permissions) from the extension (besides, chrome is not even defined in a Web worker).
If you're doing really heavy stuff with the results of the chrome.history API, then you could pass the result of a callback to a worker for processing (with Transferables, the overhead is minimal). Before doing that, make sure that you profile whether the performance impact is really that significant to warrant implementing anything like this.
I have an ember application that I create like this:
window.App = Ember.Application.create({});
I want to do some background processing on a web worker.
How can I get access to the window object or some other global object in the separate web worker thread?
Short answer. You can't.
The only resources available to web workers are that which they load from JavaScript files using importScripts() or anything that is passed to them via postMessage().
You can however now pass Objects to them. They are serialized and de-serialized to JSON automatically.
Also, there is no access to local storage from the Worker.