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.
Related
I got a error; the worbox precaching my Static files，for example js or css；At this time I setted workbox.routing.registerRoute is don't work；
If I delete workbox precaching （must sure server worker cache file），After the refresh file is from cache；
Responses won't come from the service worker until the registered service worker takes control of the current page. Depending on how you're testing things, that might not happen until you've closed all of your previously open tabs for your origin.
You can learn more at "The Service Worker Lifecycle".
I'd recommend starting from scratch by using a Chrome Incognito window, going through the SW registration, and then reloading that Incognito tab. At that point, the newly registered SW should be in control of the page, and you should see your precached JavaScript being used to satisfy the subresource request.
In general, if you are using Workbox precache and runtime routing in the same service worker, and you list you call to precaching first (which is what you're doing), then precaching will take precedence.
In my service worker, I have to generate some text. The problem is updating service worker language when app language changes. The only idea I have is having a service worker for every language, which is not a scalable solution.
The client app that is registering the service worker is a Spring app, in which I get locale using pageContext.response.locale.language (not compatible with JS).
Are there any other approaches to this problem?
I'm not completely sure what you're trying to do, but I guess you need to communicate the change of the language setting to the Service Worker. You can communicate that from the application's regular JS code via the postMessage API. Using postMessage, you can send arbitrary messages from the page to the SW and vice-versa.
Then it's a matter of what your SW does after receiving the message. Maybe it then generates different text based on the chosen language. This way you only have one SW that knows how to generate different language versions of the text and it does so depending on the lang setting of the user.
I have a vue.js/Cordova app in which I want data coming from Rest web services to be available in offline mode, the trivial solution first coming to my mind is using local storage API by indexing each w.s response and make my frontend service return data from local storage in offline mode or in case of a slow internet connection. But I think doing this directly using local storage API is very tricky, and I thought maybe using service workers and pwa concept can do the task properly.
Now, my question is: in my use case, can service workers do the job? second, are service workers available in a Cordova android/iOS app ? Finally, what are probably the compatibility issues/usage risks when running on mobile devices ?
Unfortunately, if you are using Cordova to serve up files from either file urls or http urls, as you probably will do unless serving from a website, it will not work on Android, due to the fact that service workers only work in secure contexts. See https://www.w3.org/TR/service-workers-1/#secure-context.
However, on iOS there is a plugin that allows you to use service workers, even on older versions that have no native support.
Even without the lack of support in android, service workers won't be present in enough platforms to be useful as a core part of your app.
In your case, as you are already using Vue, I recommend using Vuex, Vue’s Application Data Store.
You also get some other benefits.
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.
What is the difference between Service Worker and Shared Worker?
When should I use Service Worker instead of Shared Worker and vice versa?
A service worker has additional functionality beyond what's available in shared workers, and once registered, they persist outside the lifespan of a given web page.
Service workers can respond to message events, like shared workers, but they also have access to additional events. Handling fetch events allows service workers to intercept any network traffic (originating from a controlled page) and take specific actions, including serving responses from a Request/Response cache. There are also plans to expose a push event to service workers, allowing web apps to receive push messages in the "background".
The other major difference relates to persistence. Once a service worker is registered for a specific origin and scope, it stays registered indefinitely. (A service worker will automatically be updated if the underlying script changes, and it can be either manually or programmatically removed, but that's the exception.) Because a service worker is persistent, and has a life independent of the pages active in a web browser, it opens the door for things like using them to power the aforementioned push messaging—a service worker can be "woken up" and process a push event as long as the browser is running, regardless of which pages are active. Future web platform features are likely to take advantage of this persistence as well.
There are other, technical differences, but from a higher-level view, those are what stand out.
A SharedWorker context is a stateful session and is designed to multiplex web pages into a single app via asynchronous messaging (client/server paradigm). Its life cycle is domain based, rather than single page based like DedicatedWorker (two-tier paradigm).
A ServiceWorker context is designed to be stateless. It actually is not a persistent session at all - it is the inversion of control (IoC) or event-based persistence service paradigm. It serves events, not sessions.
One purpose is to serve concurrent secure asynchronous events for long running queries (LRQs) to databases and other persistence services (ie clouds). Exactly what a thread pool does in other languages.
For example if your web app executes many concurrent secure LRQs to various cloud services to populate itself, ServiceWorkers are what you want. You can execute dozens of secure LRQs instantly, without blocking the user experience. SharedWorkers and DedicatedWorkers are not easily capable of handling many concurrent secure LRQs. Also, some browsers do not support SharedWorkers.
Perhaps they should have called ServiceWorkers instead: CloudWorkers for clarity, but not all services are clouds.
Hopefully this explanation should lead you to thinking about how the various Worker types were designed to work together. Each has its own specialization, but the common goal is to reduce DOM latency and improve user experience in web based applications.
Throw in some WebSockets for streaming and WebGL for graphics and you can build some smoking hot web apps that perform like multiplayer console games.
2022 06 Update
WebKit added support for the SharedWorker recently, see the details of the resolution in the issue link mentioned below.
2020 11 Update
Important detail for anyone interested in this discussion: SharedWorker is NOT supported by WebKit (was intentionally removed ~v6 or something).
WebKit team are explicitly suggesting to use ServiceWorker wherever SharedWorker might seem relevant.
For a community wish to get this functionality back to WebKit see this (unresolved as of now) issue.
Adding up to the previous great answers.
As the main difference is that ServiceWorker is stateless (will shut down and then start with clear global scope) and SharedWorker will maintain state for the duration of the session.
Still there is a possibility to request that ServiceWorker will maintain state for the duration of a message handler.
s.onmessage = e => e.waitUntil((async () => {
// do things here
// for example issue a fetch and store result in IndexedDb
// ServiceWorker will live till that promise resolves
})())
The above code requires that the ServiceWorker will not shut down till the promise given as the parameter to waitUntil resolves. If many messages are handled concurrently in that manner ServiceWorker will not shut down untill all promises are resolved.
This could be possibly used to prolong ServiceWorker life indefinitely making it effectively a SharedWorker. Still, do keep in mind that browser might decide to force a shut down if ServiceWorker goes on fo too long.