I have a VueJS application that is deployed to a local IIS 10 server for intranet use.
Trouble is, the index.html file is getting cached and a forced, manual clearing of the browser is needed to see updates. I understand there are ways on the server side to prevent this, but I'm unclear based on what I've read so far as to what the proper way of making sure the html file isn't cached is (js, css and the like are, of course, not cached since they have the additional value appended to the file name during build.)
I'm very much a novice when it comes to the server side of things, so any insight would be greatly appreciated. Thanks!
Which packaging tool do you use in your project? Generally speaking, Webpack/Vue-CLI has settings for prevent the file from caching in the browser on the client-side. In other words, it adds hash value to output files which could flag the version we build recently, this will result in the client browser to forcibly request the new version file.
In the Webpack.config.js
output: {
filename: '[name].[contenthash].bundle.js'
}
https://webpack.js.org/guides/caching/
See these links for more details.
Browser cache problems with webpack chunks and vue.js components
how to force clearing cache in chrome when release new Vue app version
VueJS/browser caching production builds
Related
Okay, I'm trying to publish my Nuxt.js app on my web host but I've run into some issues. I do not want a static site.
After running "npm run build" locally, I transferred the files to my web host with FileZilla. Then I'm supposed to fill in the statements shown in the picture below.
And this is where my problems begin. The app does not want to start at all, and i am nor sure what to put as "Application startup file". And according to my web host, the overall problem is that there is no startup file for Nuxt applications. I am completely new to Nuxt and do not have that knowledge and therefore I now turn to you, is it the case that there is no starup file for Nuxt?
The web host also mentioned that it is more difficult to get a Nuxt application upp and running on shared hosting, is that correct? Will I not be able to get my app up and running in this place?
My web host had received this error message when they tried to start my app. Maybe there are some clues in there to find.
ERROR Request failed with status code 404 15:58:38
at createError ({{my-adress}}/14/lib/node_modules/axios/lib/core/createError.js:16:15)
at settle ({{my-adress}}/14/lib/node_modules/axios/lib/core/settle.js:17:12)
at Unzip.handleStreamEnd ({{my-adress}}/14/lib/node_modules/axios/lib/adapters/http.js:260:11)
at Unzip.emit (events.js:315:20)
at endReadableNT (internal/streams/readable.js:1327:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Hope someone can help!
Without some more context, I can't tell you exactly what your issue is but I suspect it is to do with how the web server on your shared hosting is configured to serve files. When you visit a route, it's not correctly finding that index.html page.
A Nuxt static application deploys with a structure where each page route has its own rendered index.html page inside a folder - if I'm not mistaken.
Your web path may look like example.com/hello but in reality it resolves as example.com/hello/index.html. Some web servers will struggle by default with this structure if not setup correctly.
Honestly, if I were you I'd deploy the project to either Vercel or Netlify.
Both have incredibly generous free tiers that will let you host your application for (if it's not making any money) for a very long time at a good scale.
They both run on automatically scaling infrastructure so you don't need to worry how much resources your site is consuming or how many users you get. It will maintain responsive and reliable without any detriment to load speed.
They'll also automatically handle building and deploying the application on your behalf. All you need to do is connect the service to a Github repository.
They also provide CDN's and other optimisations such as compression for you as well to make your site much faster.
Nuxt has a dedicated page on Netlify deployment. I recommend you give it a read:
https://nuxtjs.org/docs/2.x/deployment/netlify-deployment/
When you do npm run build (or npm run generate), your final content will be available in the /dist directory (the console should tell it to you at the end). It contains an index.html file, this is the one that serves as entry point.
Btw, before going any further double check that this is working locally:
npm run build
npm run start (URL and port will be given to you)
If it works locally, you can proceed.
.nuxt is essentially used for development purposes, caching and so on. And should not be tracked by Git, nor deployed.
I'd like to advice against using FTP for deploys (especially if not secured). Prefer a more modern way, like pushing your latest git commit and let the platform handle the hook or fetching your new code and bundling your app for you.
As recommended above, Netlify is one of the best place to easily host your Nuxt app: simple, fast and headache-free. Also, check #jordan's link about the various platform deployments, you may find yours (if it's good/well known).
I may come here a little late, but this is the way I configure the "Application startup file" when deploying a Nuxt app in shared hosting using the NodeJS Selector app (that commonly you find in CPanel)
Since basically the startup file in NodeSelector is executed as if you would run node startup_file.js, you can create an app.js at the root of the project, and add the following code:
require('#nuxt/cli').run(['start']);
This is basically the same as nuxt start, which is basically the start script in your package.json
Hope this can help others having the same issue. I leave here the same issue posted in git:
https://github.com/nuxt/nuxt.js/issues/7192
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'm wondering, when building a Vue PWA app using the CLI and letting all config at default values, my built app is:
prefetching all chunks on initial load using the HTML prefetch links
precaching all chunks using Workbox's PWA mechanism
How do these two mechanisms interact and should I disable one of both?
Thanks!
Prefetch mechanism in index.html <HEAD>:
Precache manifest in service-worker.js:
They clash. The browser downloads them multiple times.
What happens most likely is this (I'm saying most likely because the prefetch link is a hint to the browser and different browsers might implement its use in varying ways and priorities):
Browser fetches the HTML
Browser sees the prefetch links
At some point, browser starts to download the links for later use
When Service Worker is registered, it precaches all the same assets
At later visits/reloads of the page, all of the assets come from the SW's cache and nothing is downloaded again
The double donwload happens because the SW's precache thing uses cache busting and tries to download assets like /realname.hash.js?bla=hash_in_the_manifest_file so even though your files already have the hash values in their names, the precache mechanic is not satisfied with it.
Actually, if you look at the documentation of the Workbox precache plugin you see that they suggest you to drop the revision (hash) checking if you already use hash values in the filenames.
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.
In the past I had problems with the browser cache serving older versions of the xap file.
In order to overcome this I dynamically add a query string parameter containg the last modified date of the xap file to the silverlight source parameter in aspx page. This guarentees that clients will receive the latest xap file and not a cached stale versions.
I am now using the DeploymentCatalog functionallity in MEF in a silverlight app to download some xap files.
Does anyone know how this works under the hood?
Will it use the browser cache or does it download fresh everytime?
If it does go through the browser cache, how can I prevent stale cached versions from being served? (as described above).
Thank you!
The DeploymentCatalog just uses the WebClient class to download the xap. Whether it is cached will depend on your browser. From the server-side you should be able to control whether the browser caches the file by using the HTTP Expires header. Here is a question with some information about this: Browser Caching in ASP.NET application