Anyone got a way they handle this..
1 you build and release the frontend to prod
2 users visit the site and use the app
3 you build and release to prod a bug fix to page A, the built chunks that were affected from the new code now have a new file hash (from webpack)
4 the user is still on your site, so no need to refresh, but clicks a link to page A, but hadn't previously been to page A. Now the app throws an error as it tries to fetch a link that requires
a chunk that doesn't exist anymore..
I'm configuring the pwa setup so the app will know when a new update is available... But it feels like this scenario will not be completely fixed with a pwa manifest alone. Also new to the pwa stuff.
Another idea i was toying with was to make use of the apps socket connections and push a message to all apps to refresh.. but this feels overkill
Make sure you check the Service Worker registrations. It sounds to me like this might be the issue.
Related
I've built multiple sites with Nuxt SSR, but never touched the static part.
As far as I know, upon build-time, Nuxt automatically executes all API calls and caches them.
If I want to make a blog with a static Nuxt site, how would I update the content? Is it only possible when I rebuild the app?
Seems unnecessary to rebuild everything every time I add a new blog post. With SSR I just reload the page.
Also wanted to note that I have a Strapi.js backend running on a VPS and I usually make changes weekly. Nuxt's docs state that I need to push my changes to the main repo branch but there's no changes on the frontend.
Does this also mean that the headless cms should be local only?
The whole point of having a static build is to have all the generated files with no additional server Node.js server needed. It reduces heavily the costs, removes a point of failure, discard any notion of server charge (amount of users at the same time on your app) and probably some other advantages yeah.
Downside, you indeed need to actually yarn generate the whole app again if it's something that was added/changed in the codebase. Usually it's pretty fast and there are also incremental builds if I do remember properly (you will not regenerate all the 99 old blog posts but only the 100th, the new one).
Headless CMS like Strapi usually work with a webhook: you add a new CMS article or alike, Strapi will notify your JAMstack platform to rebuild your app. Even if no front-end code was changed, you can force to build it with the new data coming from the headless CMS' API.
I've built a Microsoft Teams channel tab with SSO and I'm hosting the tab application which I've built with React via create-react-app.
The auth works well, and the app loads and runs.
But when I update my app on the web site, the Teams desktop client (Mac and PC) will sometimes cache the old app and will not pick up the changes. But then sometimes it will.
If I run the web client, it usually picks up the changes.
I've verified that I'm serving up new bundles with different names each time I update. But running the Teams desktop devtools I can see that Teams is asking for the old bundle, every time, so it's definitely caching the response from my app's URL.
I've read about the problems people have with the Teams desktop client has with caching Sharepoint content and not picking up content changes. I've tried the cache clearing techniques but they don't seem to work for this issue. And I can't reasonably have users do crazy cache clearing every time I make an update to the tab app.
What should I do? Some have suggested I need to update my version in the app manifest and redeploy to Teams -- that seems really brutal. Do I need to set some cache headers in a certain way to force the Teams client to pick up the new code?
Solution
Set a Cache-Control response header to no-cache (or must-revalidate) for your build/index.html.
Explanation
We had the exact same issue. Turns out it was because we cached our build/index.html.
According to the create-react-app doc, only the content of build/static/ can safely be cached, meaning build/index.html shouldn't be cached.
Why? Because files in build/static/ have a uniquely hashed name and are therefore cache busted on deployment. index.html is not.
What's happening is since Teams uses your old index.html, it tries to load the old /static/js/main.[hash].js defined in it, instead of your new JS bundle.
It works properly in the Teams web client because most browsers send a Cache-Control: max-age=0 request header when requesting your index.html, ignoring any cache set for the file. Teams desktop doesn't as of today.
This seems like an issue with the way your app is managing the default browser caching logic. Are service workers enabled for your app? What cache control headers is your web server returning?
There are some great articles that describe all the cache controls available to you; for example:
https://medium.com/#codebyamir/a-web-developers-guide-to-browser-caching-cc41f3b73e7c
Have you tried doing something like this to prevent caching of your page (do note that long term you might want to use something like ETags which is a more performant option):
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#preventing_caching
P.S. You can also follow the instructions here to open the dev tools in the Desktop Client to debug all this:
(How) can I open the dev tools in the Microsoft Teams desktop client?
And even force clear any cached data/resources for your app:
I have a Vue app that is used both in the browser and as a PWA. I would like to ensure users receive the latest version whenever updates have been pushed to the server.
I am using Nginx, Django and vue-cli along with #vue/cli-plugin-pwa.
Currently when I npm run build and then push the new version to the server, users get the old version of the app (in browser as well as PWA on their phones). To get the new version they do a hard refresh in the browser or for the PWA they close the app and reopen it again.
Is there a way to ensure a version check is done every time the app is loaded so that the new version is retrieved?
In the end I found this excellent article which covers how to display a notification when an update is available. The user is then able to click the notification which updates the app.
https://dev.to/drbragg/handling-service-worker-updates-in-your-vue-pwa-1pip
I was debugging my app in my personal Google play services account but the company I am working on has already got their Google play services account so I changed and DELETED (deleting api credentials and unpublished it) the game. I have managed to register a new android app but when I try to register a web app I get the error #4800004 (An unexpected error has occurred. Try again later).
What should I do?
It can take approx 7 days for your old package to be removed. You will not be able to add a new one until that happens.
Your options:
Wait 7 days and try again.
Rename your package.
Alternately: You cannot have two apps with the same package details. Are your two apps conflicting with each other?
From the github post, it was mentioned that you maybe re-registering an app with the same package name. You can check if your project was already registered in the console. Projects that you have deleted will take effect after the 7th day.
For further information, you can also try to check this page. It may also have something to do with SHA1 Signing Certificate Fingerprint from android studio.
You need to make sure that the LaunchURL that you provide includes the protocol (for example: http://) in addition to the domain. If you do not provide the protocol, google appears to automatically add https://, but this led to the error posted in the question for me.
The great thing about PHP is that if you have something like
clothes.com, clothes.com/men.php, clothes.com/women.php
Then if you only edit the men's page, only that particular "app" will be restarted.
But on rack/Sinatra I have to touch the restart.txt file to restart the ENTIRE website.
Is there a way around this problem, so that users browsing other parts of the site wont have any problems while another part of the site get edited?
(i'm using mod-passenger on Apache, not that it's important..)
This would be true in all cases anyway for editing (non-inline) views (not layouts).
Aside from that, if you're really worried about this then I'd suggest using versioned folders to hold the application code. When you do a deployment, change the proxy to point at the newer version. Those who had already made requests will remain on an instance of Apache and the application that is already running, as long as their request remains alive, and seemlessly (unless you've broken something with the code) move to the new code on the next request.
It's also a convenient way to rollback to the/a previous version quickly and easily.
Check out the sinatra reloader from sinatra contrib