I'm confused about what should be my scope property in my web manifest file.
Say, if my start_url is set to https://www.example.com/, should my scope be "/" or the same as start_url?
I'm using Vue3.
Note:
The main issue that I'm facing is the service-worker not getting detected by the browser and it figures out setting an appropriate scope could solve the problem it.
The scope field in the web app manifest defines something different than a service worker registration's scope.
Setting scope in your web app manifest is not required to use a service worker or have it detected.
If you could provide some more details about how you're registering your service worker in your question, we might be able to help you further. Additionally, "The service worker lifecycle" documentation has a lot of best practices for using service workers. I did want to share this answer to at least clarify the difference between those two scope values.
Related
I am using Workbox to make a CMS site offline-capable. I have the service worker insalling and pre-caching site pages, assets, and offline page. The problem is, with pre-caching, there appears to be no way to update the cache without modifying the service worker. In my case, it's a CMS, so authors will not be re-building this service worker when updating site content. I assumed I could just use the StaleWhileRevalidate strategy but to my dismay, there is no way to provide a caching strategy to "precacheAndRoute()" or "precache()" and "addRoute()". This seems to be an oversight by the Workbox team, but just to be sure, I'd like any feedback on how one might implement this solution without changing the service worker any time a site page is updated.
Thanks!
Answered my own question. Will post here in case anyone finds themselves in a similar case.
According to https://developers.google.com/web/tools/workbox/modules/workbox-precaching#serving_precached_responses, the following information tipped me off to the solution:
The order in which you call precacheAndRoute() or addRoute() is important. You would normally want to call it early on in your service worker file, before registering any additional routes with registerRoute(). If you did call registerRoute() first, and that route matched an incoming request, whatever strategy you defined in that additional route will be used to respond, instead of the cache-first strategy used by workbox-precaching.
So I dumped "precacheAndRoute()" in favor of just "precache()". Then I did a registerRoute() with the StaleWhileRevalidate strategy matching those assets. The important part was specifying the cacheName as the precache:
new workbox.strategies.StaleWhileRevalidate({
cacheName: workbox.core.cacheNames.precache
})
Pretty simple in hindsight, but the documentation wasn't clear at first on what seemed like something that should be built right into preCacheAndRoute.
I posted another question as a brute-force solution to this one (Angular: fully install service worker before anything else) but I thought I'd make a separate one to discuss the use case for when a service worker is used as intended.
According to the service worker life cycle (https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle), the SW is installed but it's only active once you then reload the page (you can claim() the page but that's only for calls that happen after the service worker is installed). The reasoning is that if and existing version is updated, the old one and the new one do not mix states and caches. I can agree with that decision.
What I have trouble understanding is why it is not immediately active once it is initially installed. Instead, it requires a page reload unless you explicitly define precaching rules in the SW. If you define caching rules with wildcards, it's not possible to precache those so you need the reload.
Given a single page PWA (like Angular), a user will discover the site and browser around on it but the page will never be reloaded during that session. If they then want to use the site offline later, they need to have refreshed or re-opened the tab at least one other time. That seems like a pretty big pitfall to me.
Am I missing something here?
Your understanding of the service worker lifecycle is correct but I do not think the pitfall you mentioned is as severe as you think it is.
If I understand you correctly, the user experience will only be negatively affected if the user loses connectivity during the initial browsing of the page (before the service worker is active) and is missing an offline asset. If this is truly a scenario you want to account for then that offline asset can be pre-cached in the browser-side javascript. Alternatively, as you mentioned, you can skipWaiting() and claim() to make the service worker active without the user refreshing the page.
I have multiple pages in my application, for example, http://example.com/path/foo1.html and http://example.com/path/foo2.html. Can I register a separate service worker for each of these pages, or do they have to share the same service worker because they are both under ./path folder? In other words, does the scope setting specify a folder, or can scope specify a page? I tried separately registering service workers, one for each page, but what I am seeing is that both service workers are being loaded for each page. Is that expected, or am I doing something wrong?
You can register multiple service worker for different pages as long as the
scope specified is different. Since the root for both the pages is '/path',
everything after the path will be controlled by the same service worker.
For registering multiple service workers, you need the pages to be moved to different path. or atleast include something between root and html page.
path/samp/foo1.html and path/samp1/foo2.html
In above case, in foo1.html, you can register the service worker with scope as path/samp and in foo2.html, scope as path/samp1.
Enabling multiple service worker for the same scope is not currently available.
For more info: https://github.com/w3c/ServiceWorker/issues/921
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.
I've been doing some research on BPEL for about two weeks now and still don't quite get it.
I have deployed the HelloWorld sample in ODE and have also managed to deploy this other one.
My intention was to do something like the second example but with my own real WS deployed and working.
I'm now at the point of having a process with no errors and correctly deployed in ODE with the following structure:
I have started the project from a service definition importing my Multiply.wsdl. The Designer has composed the import tag into the MuktiplyProcessArtifacts.wsdl next to the PartnerLinkTypes all automagically so I assume all namespaces, etc are ok.
There is a few concepts I misundertand in order to make all of this work:
In my original Multiply.wsdl I have
soap:address
location="http://localhost:8080/WS-multiply/multiply"
but ODE tells me my soap:address must have the form host.port/ode/processes..
This doesn't sound reasonable to me since my WS could be implemented anywhere outside my ODE_HOME.
The second example I mentioned before explains how the Designer presumably creates a "Caller.wsdl", which in fact has the function I would desire, which is to implement a "wrapper" WSDL, providing the BPEL process with entry and exit points. The issue is the Designer does not generate that interface. Am I supposed to create it myself? Do I have to create it at all?
If that 3rd wsdl is really needed, is it the one I would have to call if I wanted to test the whole process?
It looks like your partner WSDL is associated to a myrole of a partnerlink. Partnerlinks and partnerlink types are a concept in BPEL that is used to define dual interfaces in a sense that if a partner A wants to communicate with a BPEL process as a buyer, it needs to provide a certain set of functionality that the process can use for further communications (i.e. sending a shipment confirmation to the buyer). Thus, a partnerlink maintains two roles, the myRole is the portType (aka interface) that the process itself provides, the partnerRole refers to a portType the process expects to be implemented by the partner. MyRoles must be of course implemented by the BPEL process and thus needs to have an endpoint that is exposed by the BPEL engine. PartnerRoles can be bound to arbitrary endpoints. This happens in the deployment descriptor, which is the deploy.xml in ODE.
I guess you can fix your process by assigning your partner WSDL to a partner role.
I hope http://thiliniishaka.blogspot.com/2012/10/develop-ws-bpel-process-using-wso2.html
and http://thiliniishaka.blogspot.com/2012/10/part-2-developing-ws-bpel-process-using.html may help you to resolve aforementioned queries.
Thanks
Thilini
Its mandatory to have Ode.war deployed at tomcat server, tomcat create a path like the picture, you need to config your endpoit with the complete path /ode/processes
c:\apache-tomcat-7.0.55\webapps\ode\WEB-INF\processes\BPEL_WS\