In react I am using the service worker for push notification service, so during a production release without noticing service worker config, it was pushed to live and the site data got cached indefinitely in many of user's browsers.
However now this issue is fixed, but the users who were accessed that specific rollout are still seeing the old version of the site.
Is there any solution for this?
Related
Whenever I deploy a new version in Google App Engine, and I transfer traffic to it, the previous version still consumes messages from our message broker. How can I make sure only the newly deployed version will consume messages without shutting down the old instances?
If you have multiple versions deployed while traffic is being migrated, you can check the current version using the Modules API and compare that with the default version.
Your check might look something like this:
from google.appengine.api import modules
def default_version = modules.get_default_version()
def instance_version = modules.get_current_version_name()
# you may additionally want to query the instances of the default version
# to make sure they've booted up and are actively serving traffic.
if default_version != instance_version:
# don't consume messages
In the code example above, the default version is the version traffic is being migrated to, and the current version is the version of the instance.
See also Using the Modules API.
Note: Services were formerly known as modules and the API methods still reflect that naming.
During the deployment of your service, you can use --promote and --stop-previous-version options.
https://cloud.google.com/sdk/gcloud/reference/app/deploy
However, generally it's best to gradually migrate the traffic. This is the case for both users and backend services. Since you can't deploy two services at the exact same time, imagine your GAE deployment is delayed by a few seconds. Do you expect the messages to be consumed by your running service that is getting replaced? So, it shouldn't matter if a few messages still got routed to the old instance while the traffic is migrating. That would be the right design.
Service workers require HTTPS ... If your production web server does
not support HTTPS, then the service worker registration will fail, but
the rest of your web app will remain functional.
quoted from the docs at https://create-react-app.dev/docs/making-a-progressive-web-app.
What does it mean the rest of your web app will remain functional, but service worker registration will fail? In other words, if my app remains functional, do I really care if service worker has failed? (what are the limitations?)
So your app would still work, but you would lose all of the functionality provided with the service worker. At the bottom of the "Why Opt-in?" section of the Making a Progressive Web App it states:
The workbox-webpack-plugin is integrated into production configuration, and it will take care of generating a service worker file that will automatically precache all of your local assets and keep them up to date as you deploy updates. The service worker will use a cache-first strategy for handling all requests for local assets, including navigation requests for your HTML, ensuring that your web app is consistently fast, even on a slow or unreliable network.
So you could use it as normal but you would lose:
Offline support,
Precaching of your local assets,
Cache-first approach for your local assets and navigation requests,
Performance improvements of your application in slow or unreliable network conditions.
Whether or not you care if it fails is directly related to if you value these features in your application. If they are critical to your application, you probably care a lot. If it doesn't matter to you either way or affect your end-user, it's probably not a big deal.
You can find out more about Service Workers and why they only work using HTTPS in the Service Workers API documentation
We just deployed our new website on the same domain but with a different stack. the old stack was create-react-app and it had service workers which is caching for offline usage.
Now after the new version is deployed, it still shows up the old version because of the cache. is there anyway i can force all users who visits the website to clear cache automatically?
I am implementing service worker caching of my static js app. Everything works fine but to notify a user that is using the app that there is a new version available I need to be sure that I update the service worker file so the hash of it will be different and the browser will installing the new one.
Once installed I can show a notification to the user that a new version of the app is available and invite him to update it.
My fear is to forget to edit the service worker file and leave the users with an outdated app until someone notice it.
Is there a good practice to automate this process? (updating service worker file on everybuild). Maybe using webpack?
I have been using GAE and Endpoints for a couple weeks now. I see when I make changes to my code, the devserver will automatically pick up the changes and I am able to sometimes run tests against my updated API in the local API browser. However, I have also noticed some instances where it appears the changes were not picked up automatically and my API browser was hitting old code.
What is the proper process for updating my application to test locally? Do I have to restart my devserver? Do I need to refresh my browser and build new request objects? Can I simply execute a previous request again? (from experience, the last question appears to be no).
Thanks.
While working with the Development Server, I have found that it is best to :
Restart the Server &
Refresh the browser to ensure that any updated services definition is picked up by the API Explorer.