I am developing a PWA and I am shipping a lot of updates.
I have a service worker in the background as usual. But I cannot figure out a good update strategy.
By default the PWA update itself when all tabs are closed - for some users that might be never or months later, right? Does that mean breaking API Changes are impossible or how is that supposed to be?
Currently, I use the skipWaiting functionality which works fine, but in the InAppBrowser of Instagram, users get a blank screen each time the service worker forces the update.
What am I doing wrong? How are you guys solving the problems? Is SSR regarding this better?
Thanks :)
Alex
Related
My site works nicely as a PWA and I am trying to improve it. I have a couple of things going on and I am not sure if this is normal behavior or not.
Starting with offline.html. Right now I have a standard simple piece of text that say you are viewing example in offline mode. There is no header/footer or any other content. I'd really like to improve that but where and how much can I improve it? It doesn't seem to act like a normal page. I also find a problem on my child pages where when testing and looking at a waterfall chart, offline.html is coming back as a 404. I doubt this is normal.
Secondly, when I run a lighthouse test on a child page like example.com/childpage I get the following;
Current page does not respond with a 200 when offline
start_url does not respond with a 200 when offlineThe start_url did respond, but not via a service worker.
Does not register a service worker that controls page and start_url
I've tried to search for answers but I'm not having much luck. Any help or suggestions would be appreciated? Thanks.
I only understand from a VueJs perspective.
If your app isn't registering your service worker, then the service worker won't be able to intercept the http request, please see attached pic. basically you need to get that registered before you continue.
reference: https://www.sicara.ai/blog/2017-06-30-part-three-progressive-web-app-with-vue-js-webpack-material-design
you can add a <noscript> tag into your index.html which will catch when your JS doesn't load see: https://web.dev/without-javascript/
Going back to registering your service worker; You need to make sure your webpack, or like in my case my vue.config.js is actually registering your PWA correctly, including the service-worker.js
pwa: {
themeColor: '#2F1B55',
msTileColor: '#000000',
iconPaths: {
favicon32: 'static/favicon-32x32.png',
},
workboxPluginMode: 'InjectManifest',
workboxOptions: {
swSrc: 'service-worker.js',
},
navigateFallback: 'yourDir/public/index.html'
}
navigateFallback this is important to tell the browser where to start the JS from again when it falls over mid app.
Getting a service worker registered on build is your primary concern. Try reading the article from 1. to get a greater understanding.
Thanks for your input, I'll read tonight. That said,I can put my mobile device into airplane mode and my entire PWA acts just the way it did when I was online (unless its a DB lookup). This is why I'm a bit confused. Every page that I visited online is available offline. I only get these warnings from lighthouse. In devtools, there is no warning. Cheers.
Maybe someone knows what the cause of the error? I am trying to come and continue the activation of your NVP / SOAP API Apps, but the server responds with an error. Someone knows what's going on?enter image description here
UPDATE: It looks like over the weekend the app services went back online, so all should be fixed now. Let me know if you encounter any issues with it, and definitely very sorry for any issues this downtime caused you.
At the moment there are some issues at paypal-apps.com, which is affecting the site and ability to create new applications. The teams are working on the servers that are affected and will hopefully have more information soon. I'll update as soon as I have more details though.
After many support cases we are realizing the biggest problem we have with our GWT-based application is that users are leaving it open for weeks at a time. This means when we do a hotfix every week or two the RPC stubs are out of sync and cause silent exceptions to be thrown making the site look "broken". Does anybody know of a way to auto-detect and avoid this issue? A few ideas I have had are...
On catching an RPC mismatch exception refresh the browser.
When loading the host page inject the version number in source control the build came from, have a status checker/timer that check that the number did not change. When it does reload.
Reload on an arbitrary timer (perhaps twice daily).
Any ideas?
I'd like to present a fourth option.
Create an RPC Proxy and UI Object proxy that all UI requests and RPC requests are routed through. This way whenever this proxy detects that something is out of date it can dynamically load the widget or change it's expected RPC models.
This is pretty how Vaadin does things and it works great. Vaadin is a UI toolkit built on GWT in case you're not aware. We have several long running production applications using this over the last couple of years and we have made some tweaks in their UI Def language (UIDL) to add version mismatch.
This diagram is a good representation of what they do and if you don't want to build something like this yourself I'd of course recommend moving to Vaadin.
Implement security that logs users out after an hour of idle time. Assuming your releases are overnight or on weekends, the users are logging in after the release. No need to refresh the app.
this is viable especially if your site eventually needs users to login.
I've recently discovered the lift framework and have read that it's stateful.
Therefore, if I had a high-traffic site running on Lift - say something that was running a chat application that required users to be logged in - and I wanted to upgrade my app, would doing so kick everyone out of chat and make them have to log in again?
None of the previous answers are correct. Many of the artefacts held within the LiftSession are non-serilizable, so cant be stuffed into a database. You have two options for doing rollig upgrades of stateful applications:
1) Session bleeding. Basically you ween one of the deployments sessions away until their sessions have ended or X duration passes and then you remove the app from production whilst automatically rerouting traffic to another instance of Lift. Google around for rolling upgrades using HAProxy as this should help you from the cluster perspective.
2) If your state is fairly trivial (mostly primitive-style types: ints, strings etc) then you could think about using ContainerVar/MigratableSession and clustering the state using terracotta or similar. This comes with a range of limits though because it then uses the HTTPSession rather than LiftSession.
You might want to checkout chapter 15 of Lift in Action which details that latter solution in a fair amount of detail.
If you keep your state in memory and redeploy the web application, that state will be lost. You could save it to a database or a file before redeploying though and read it back from there.
Say I have a TODO list iphone app, that can be edited/viewed from both a web application and the iphone application.
When on the iphone, when a user views all his todo lists, or sub-items, I would think that each time the user views a particular list it shouldn't be hitting the web applications API every-time, but rather cache locally the values and only hit the web when things change.
What strategies are there for this type of scenerio?
I agree with you in your dirty-otherwise-do-not-contact-the-server point. And I think this point is pretty straightforward and easy to implement.
However, be careful in this scenario: it gets dirty but at the same time, the device cannot reach the internet. In this scenario, I suggest you check the internet accessibility on a frequent basis (even when your app is in the background), and try to reach your server and update whenever possible.
This is a tricky problem. I'm currently working on an app that needs to perform a similar synchronization, and I haven't decided how I want to handle it yet.
You're right in that you don't want to be hitting the web repeatedly. It would slow the app down considerably. Keeping a local cache is the way to go.
One drawback is that the user could change/add an item on the web and you wouldn't see it on the phone. You'd need to have a refresh button (like in the Mail application, for example) to allow the user to get the changes.
Then you have an issue with conflict resolution. Say the same item is edited on both the phone and on the web. How does the user pick which one to keep, or do they get duplicated?
I think the best way to do this is to replicated your server's schema in CoreData. Then load a given element from the local DB, and in the background go out and check that element for updates if the device has an internet connection. You're hitting the db each time, but the user is not slowed down by the process.
You should not query the internet everytime you view the list.
But when you make updates to it, or edit it, you should update the server as well. That will make your life a whole lot simpler. That way when the user updates an item that he deleted in the web server, the server will just throw that request out...