I'm developing an application in ReactJS where I quite often push new changes to the the application.
When the users load upp the application they do not always get the newest version of the application causing breaking changes and errors with the express backend I have.
From what I have researched you can invalidate the cache using "cache busting" or a similar method. Although from all the questions I have seen on stackoverflow they have no clear consensus on how to do it, and the latest update was sometime in 2017.
How would one in a modern day ReactJS application invalidate the browsers cache in an efficient and automatic way when deploying?
If it's relevant, I'm using docker and docker-compose to deploy my application
There's not one-fits-all solution. Pretty common is adding some random hash to the bundle file, which will cause browser to process the file again from server.
Something like: app.js?v=435893452 instead of app.js. Most modern bundle tools like Webpack can do all of that automatically but it's hard to give you direction without knowing your setup.
Related
By default, when a React Application is deployed, the cached version will display, even if changes were made in the new build. This requires the end user to hard-refresh their page (Ctrl+F5) to see new changes. It is not feasible to have a user do this each time.
With the constant upgrades and speed of software evolving, there are many different ways to accomplish this. However, the answers widely vary due to different practices being used each year.
What is the best practice to accomplish this in 2022? Is there a short and easy way to do this?
Edit: I am using the create-react-app project template.
This has to do with broswer caching the old pages and not React, to avoid this you need to either force refresh as you mentioned or changing your build strategy with some sort of different file naming, this can be done by using webpack caching here https://webpack.js.org/guides/caching/.
This way your scripts will have different names with each new deployment and the browser will ahve to reload the new scripts when fetching the index.html.
I'm just curios about this situations creating app with React Js. Is there any way to build directly on the hosting Cpanel not on localhost during development? I don't know if this question is right I'm new about this but how about if were done developing on local then build and upload to server, if there is small changes of the application then you can't change directly on the server because the code is bundle and minified. I tried to search on google and watch tutorials but can't find it. I know there nothing wrong to build on local, however I like the point that while i'm building I know it works very well and see it on live then if there is small changes I could change directly.
Apologies to my curiosity. Thanks in advance for your ideas and correcting me.
I'm not sure if react requires bundling. It is not so big itself. One useful way that you can do it, just build your react app in local, then create a git repository, push it to there then from there you can pull it to your server by connecting your server with SSH.
This way may require some installations on server side again with SSH connection. You can search the details about the way I suggest you.
Appreciating your curiosity, I can think of two possible (not at all recommended though) solutions.
1. Dump jsx
React applications requires a build process primarily for JSX syntax. It is developer intuitive. If there is no jsx in your code no need to build. So, this jsx
return (
<h1>Greetings, {this.props.name}!</h1>
);
Should be written as this js
return React.createElement('h1', null, 'Greetings, ' + this.props.name + '!');
2. Setup development environment in Server
This is a risky one. There're possible security issues.
Its like have a centralized code base on the server that anyone with access can modify.
Here, you can edit files & run build task directly on server.
Notes:
Today's basic development flow is code -> build -> deploy. Better stick with it for serious applications.
What's the best caching strategy for React websites that use chunks (code splitting)?
Before using chunks I would just cache everything for one year in CloudFront, and I would delete the old files and invalidate the cache after a new version of the website was deployed. Works great.
However, after I started using chunks I started getting problems. One common issue is that after deploying a new version of the site I delete the old files and invalidate the cache. One user is already active on the old version of the site and his version of the site tries to load a chunk that no longer exists, so the site crashes for him.
One potential solution would be to keep all old files for a month or longer, and delete all files that are older than X months during the deployment process.
Is there any better solution to this problem. Am I missing something special from the service worker that CRA (Create React App) provides? If I remember correctly it provides some kind of cache busting.
Thanks.
I have a website on AppEngine that is 99% static. It is running on Python 2.7 runtime. Now the time has come to evolve this webapp, and since I have almost none Python code in it, I'd prefer to write it in Go instead.
Can I change runtime from Python 2.7 to Go, while keeping the project intact? Specifically, I want to keep the same app-ID, the same custom domain attached to it, the same SSL certificate, and so on.
What do I have to do in order to do that? I surely have to change runtime in the app.yaml. Is there anything else?
Bonus question: will such change happen without a downtime?
I'd be grateful for any links to documentation on exactly that (swapping runtime on a live app). I can't find any.
Specify a runtime as well as a new value for version. When deployed you'll have an older version that is Python and a newer version that is Go. There won't be any downtime (same as when deploying a newer version of Python).
Rather than trusting links/docs (that may be out of date or not 100% exactly what you're trying to do), why not create a new GAE-Std project for testing purposes and try it yourself. Having a GAE-Std test project is good for testing new function (especially by other testers who won't have access to the dev environ on your laptop).
The GAE services offer complete code isolation. So it should be possible to simply deploy a new version of the service, which can be written in a different language or even use a different GAE (standard/flex) environment. Personally I didn't go through a language change, but I did go through a split of a single-service app into a multi-service one, I see no reason for which the same principles wouldn't apply.
Maybe develop the new version as a separate app first, to be able to test it properly without risking an accidental impact on the old version and only after that bring the code as a new version in the old app. That'd be using the GAE project isolation. You can, in fact, test the entire version migration as a separate app if you so desire without even touching the existing app. I am using this technique - a separate app ID - to implement a staging environment for my app, completely isolated from my production app, see How to copy / clone entire Google App Engine Project
Make sure to not switch traffic to the new version at deployment time. This keeps the app working with the old version. Test first that the new version works as expected using Targeted routing. Then maybe use Splitting traffic across multiple versions to perform A/B testing with just a small percentage of the traffic going to the new version. Finally, when happy with the results, switch all traffic to the new version.
You need to pay special attention to the app-level configs (dispatch, cron, queue, datastore indexes), shared by all services/versions. They need to be functionally equivalent in the 2 versions. The service isolation doesn't apply to them, only project isolation can ensure no impact to the old version.
There should be no need to make any change to the app ID, custom domain mapping or SSL config. The above mentioned tests should confirm that.
A few potentially interesting posts related to re-working services/modules:
Converting App Engine frontend versions to modules
Google App Engine upgrading part by part
Migrating to app engine modules, test versions first?
Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
I have recently moved from a web context into a mobile context (building a React Native app). One of the most powerful processes in the web world was Continuous Delivery. I would like to recreate a continuous delivery pipeline, into production, for the React Native mobile context. My understanding is that this is possible so long as only the javascript bundle gets updates rather than the underlying native components.
I have been finding blogs such as:
https://hiddentao.com/archives/2017/02/17/continuous-integration-for-react-native-with-testfairy-testflight-deploy/ and it appears that fastlane is the most common solution for Continuous Integration in the mobile ecosystem, but posts about Continuous Delivery are a little thin on the ground.
Is this because it is impossible? Is the promised land of "just update the js bundle" a lie? And if it is not impossible, how would I configure fastlane to push directly to production? Or would I use some other tool? Is it generally considered an anti pattern in the space? If so why?
It IS possible to update the javascript portion of a React Native app.
Fastlane is a great tool for building and deploying mobile apps but it is not itself a continuous delivery tool. However, used in conjunction with some other CI tool (Jenkins etc) it can make it easy to configure app store or beta releases triggered at some set interval or based on a certain trigger.
Fastlane is primarily designed to solve the issues associated with building and deploying native applications and as such it is very useful for building/deploying the native RN app to the app store but is likely not the best tool for managing your JS pushes. There are a few tools that are popular for pushing the JS code:
https://deploy.apphub.io/
and
http://microsoft.github.io/code-push/
are two popular mechanisms specifically built for this purpose and provide command line tools for deploying updated javascript. These could be configured in Jenkins (or another CI server) without necessarily needing to use fastlane.
As #john_ryan specified you could use CodePush for application updates. Nevertheless, it is worth taking into account some features of this solution:
You can't use hot updates if you need to add some native modules.
It strictly not recommended to use hot updates if you updated React Native version. In most cases, the consequences will be sad.
New users will get outdated built-in version at first app launching. Actual version will be presented on second run only.
Given all of the above CodePush is best for:
To decrease app update time for critical bugs. Of course you must release native update as soon as possible in this case also.
Non major updates. For major updates in most cases you need to update screenshots, app description, release notes and draw the user's attention about update. Hot update for major changes does not fit because of "second run update" cycle.
Testing stability of new update on a small part of users.
A/B testing.
You should use fastlane in any case. It really cool for custom builds, updating stores meta info, screenshots etc. For beta builds delivery I recommend Crashlytics Beta.