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.
Related
First of all, I know that nextjs has support for .env files... and this is great.
However, I do not wish to write secrets to disk, ever, becuase they might wind up in a docker image in an amazon ecr repo and someday get read by a hacker... so I won't write them to a yaml or a .env file. This is our company policy: we integrate with hashicorp vault.
Now, my idea was to get these secrets, and store them in nconf. Nconf is just a memory-based storage engine for organizing config... nothing special. I had planned to eject from nextjs cli and use a custom express server (with typescript). Fine... I can do that. But it's a little bit of a pain because it seems like people aren't doing that as much as they did 3 years ago when I used nextjs last.
That is probably because they don't want to miss out on the automatic static rendering, and neither do I.
But basically what I want to do is to make a global variable available server-side in nextjs on every page: my nconf config. I want to run things on the server and not in the browser (no secrets in the browser).
For instance... what about middleware? Can I run middleware without setting up a custom express server and ejecting? I feel like we're going to need middleware at some point, we're make an enterprise app. So I'm kind of using nconf as a litmus test. But hey, if there's a good way to handle secrets, LMK.
Am I missing something in the nextjs docs? Are there events or hooks I can tap into? Or is the whole thing kind of "nextjs way or the highway?" Because in that case I will need to eject. (I grew up in Drupal, where there were tons of hooks and you could do what you needed to with the right hook.)
Thanks for your help.
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:
Originally I ran a local server on my PC in order to make my django REST api available for my React Native app to reach out to through my computer's ip. So I had a base url hardcoded into my js network utilities as http://10.0.0.xxx:8000/api/ which I used as the basis for all my network calls. Recently I deployed my backend to Heroku so that I could demonstrate my app when away from my computer. So for now I just made a second hardcoded base url of https://my-cool-app.heroku.com/api/ which I manually flip back and forth between in my js code depending on if I want to use my local server (for debugging while devving) or the remote server for demonstration (and by "manually flip back and forth", I mean I literally change my code to point to one or the other).
I understand this is a terrible way to go about things and that I'm missing some major pieces to the puzzle that probably apply not just to RN projects but to most full stack projects where the frontend and backend are not hosted on the same server. I know I can look for the __DEV__ flag to see if I'm working in a debug or release version, but then would I have to keep two versions of the app on my phone somehow? Also, does it even make sense to keep my base urls hanging around on the front end, or should they be dispensed from the backend in some way instead?
I personally use :
https://github.com/zetachang/react-native-dotenv
for my environment variables like my backend api and other configs based on the env.
Since it's similar to many backend libs like django or laravel, i absolutely love this library for managing environment variables :)
I want to reset CloudFlare's Rocket Loader, so that it acquires the latest JS from third party scripts that have been updated.
Pressing Purge Cache does not seem to affect the Rocket Loader JS.
Toggling Rocket Loader's modes does not reset the cached version used in the Automatic mode.
How do you force Rocket Loader to serve the latest versions third party scripts?
Rocket Loader just uses the scripts currently on your site. It does not maintain any kind of cache of scripts.
If you are seeing some type of issue I'd suggest opening a support ticket with CloudFlare directly so our support team can review your account settings.
p.s. I work at CloudFlare, and spoke with the developer that maintains Rocket Loader.
"I was trying to update the third party script (that I also to control) but the page continued to serve the old script, until I turned Rocket Loader off. I would like to force RL to serve the updated script"
This actually seems more like an issue with caching of that script than Rocket Loader. Are you using any other caching plugins or services on the site? Our purge cache option should work on the file (purge cache or single file purge), but you could also be seeing caching related to another service you may be running on the site.
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.