We use grunt build to build an angularJS application.
After the built application is published on the live server, how to let users know that there is a new version of the JS application available? Because their browser will still have the previous combined javascript file.
Also the backend, which is PHP (Symfony2) might change, so if user doesn't refresh the page, some API calls might not work. Keep in mind that the backend changes will be very rare. Versioning the API as v1, v2... might be a small solution, but in the long run everyone would end up using the newest API, so keeping the old versions is not required for longer period of time.
I was thinking to make use of Angular's $interval service and make a checker every minute to a simple web service, which would return the version number of the new application. If version is newer, angular should display a message and let user know to refresh the page or force refresh it. Is that a good solution?
Just try to add a unique version_id to the file itself using grunt.
src="name_of_your_file.js?v=INCREASING_VERSION_NUMBER"
e.g
src="name_of_your_file.js?v=2
Related
I have a react-js app and I use capacitor to leverage with native mobile API's (eg: BLE). My objective is to live update the app upon a minor change (eg: adding a new label) without going through the whole appstore submission process. I know Ionic has AppFlow that could work well with Capacitor, but it is way too expensive for me. Thus, I saw some are suggesting writing a script that pulls in the JS perfectly from somewhere like the S3 bucket, and when you build the app you build in all of the native code and replace the HTML scripts with one that comes from a remote source (But I have no idea how to do it)
Is this how most people handle live-updating webview apps or is there a better way ?
If so what are the steps to achieve this objective using scripts and so on (with code examples)?
Hey I'm the Maker of Capacitor-updater, the only alternative to ionic AppFlow.
The updater allows you to manage update by yourself, store your zip update where you want and use the download method.
How to start
npm install #capgo/capacitor-updater
npx cap sync
Then in your main JS, this is required to let the updater know the update is valid
import { CapacitorUpdater } from '#capgo/capacitor-updater'
CapacitorUpdater.notifyAppReady()
And lately after checking yourself the current version need update:
const version = await CapacitorUpdater.download({
url: 'https://github.com/Cap-go/demo-app/releases/download/0.0.4/dist.zip',
})
await CapacitorUpdater.set(version); // sets the new version, and reloads the app
After many request of people didn't want to do that themselves, I started Capgo a business to manage all the update process for you.
All is open source and can be replicate on your own as well.
Doing things for Capacitor is now my main activity, I produce open-source plugin as my main channel of Marketing, I'm solo founder and bootstrapped.
Hope my tool will help you !
You need a subscription to Ionic's AppFlow, as of yet ionic is the only company that offers live updates.
I have a PWA built with Vue which hundreds of users use on a daily basis. There is, of course, a service worker which caches all of the static assets. Whenever a new release is pushed and deployed, a button appears which prompts the user to update their PWA to the latest version.
We're undertaking a complete re-write of this app and would like to use React + Next.js now instead of Vue.
Is there any sane way to make this transition smooth for our users? I would like for them to be served the new app whenever we deploy it but looking at how all the underlying files are going to be different, those who have the previous service worker installed will never get served the new, completely re-written app.
What about pushing an update to the existing version that makes the service worker do some kind of check to see if it needs to clear itself? Like check a hash, file, date, or something similar, to know when to invalidate/clear itself and load the new thing instead.
That way when you upload the new version, the old one will see the new one is up and can reload into the new one.
I have a website in GatsbyJS that has huge datasets of dynamic data fetched on load of a page via React fetch. The data displayed needs to be semi live (e.g. be refreshed every 5 minutes).
I am wondering how do I achieve SSR speeds with this, because dynamic fetch doesn't cut it. Is it cron scheduled rebuild and if so what happens during the replace of the build folder?
You can use a service like Netlify. They provide a WebHook URL that triggers a build upon querying. You could then have a cron, every 5 minutes, hitting this URL to trigger a rebuild. Netlify handles the build for you, only replacing your site if the build succeeded.
If you want to do it yourself, you can maybe use Caddy - a webserver that has a plugin for deploying from git, similar to how Netlify works (only update site if build succeeds). Note: this is not yet supported by Caddy 2 (current version).
Another option is PM2, which also builds your site for your, handling failures gracefully (your site is always up, only replaced when the build succeeds).
I think a cron scheduled rebuild is probably your best bet. You may want to check out Gatsby cloud. They have recently added incremental builds, which means that only certain pages get rebuilt. If only a subset of your pages need to be rebuilt that could significantly speed things up. I think what happens during the replace of the build folder depends on where you host your site. Some hosting services like Netlify will probably use some sort of a URL swap to instantaneously replace your old deployment with the new one. If you host it on a regular VPS there will probably be some inconsistencies as the files are copied over/regenerated. Aside from the newly added incremental build feature I think what you're looking for is precisely Gatsby's Achilles heel.
I am new to React Native I want to know how is it possible to deploy react native part or code like javascript files and assets on server and then use it.
Currently it is showing as localhost
Please let me know how to deploy it on server also is it possible or not.
Do I need to update app on play store every time when I change something in react part of my code?
what exactly code push does and is there any way by which I can load my react native bundle from server and update app dynamically
React-native compiles down to the two native languages.
Effectively you have 2 applications, non of them web.
You could have an image assets remote on a server and use the URL in the react-native code combined with a cache (so you don't have to download the asset every time).
Considering JavaScript files, I would say no. Unless you create an server and request the functionality by API calls.
And no, you don't have to interact with the play store every time, but usually you do :)
I think you need to understand how React Native works in order to understand.
What RN actually does is to expose native API to your Javascript code base. Basically a RN App is composed by 2 things:
As you can immagine the Native part is everything that is written in Swift/ Objective-C/ Java and that is the part you can not update without going through the App stores.
Now the interesting thing is the JS part, remember we said that basically you are consuming native API with JS. If you notice when you run react-native run-ios or react-native run-android a server is instanced which serves a bundle to your emulator / physical device.
Now if you think about it basically when you open the App the bundle is downloaded an then run. When you update your codebase while the app is running on the emulator the servers sends a signal trough the socket to notify the client that an update is available. At that point the client downloads the bundle and the app is reloaded.
Now to answer your question, yes you can serve the JS Bundle on your server and make the app check when is loaded or resumed if a new version of the JS Bundle is available, if so to download it (OTA update). As you can understand only the Javascript part can be update in this way and not the native part as well.
Then again, there are a few services that already do this like codepush by MS.
You can use the code-push cli or appcenter cli to publish your Javascript code to the cloud servers (hosted by Microsoft), and use react-native-code-push to retrieve the updates in your RN app.
Alternatively, you can use Expo which comes with its own over-the-air (OTA) update functionalities.
Both of the above services manage their servers internally for you and do not allow you to host the JS bundle on your own server (though there's a feature request for it).
Note that only changes to the Javascript codebase can be delivered OTA. Any updates to native code (eg. Swift/Java) must still be delivered through App Store/Google Play.
Per default, Angular fetches the HTML templates from the server when the user navigates to a route. With that in mind, imagine this scenario:
User loads the Angular app. The main view has a subpage called "Order".
While the user is studying the main view a new version of the app is rolled out in production. The new version has a complete rewrite of the Order page with new Javscript and HTML.
The user navigates to the Order page. The Javascript is already loaded by the browser in step 1, so the user is on the old version until app is reloaded. But the new template gets fetched from the server on navigation. So now the Javascript and template are our of sync!
Is my assumption that the Javascript/HTML is out of sync, correct?
If so, are there any best practices related to this issue?
I guess one solution is the make Angular fetch all the templates on app initialization. But this could be a performance penalty if the app has hundreds of HTML views.
I've never wondered about that issue myself. One possible idea would be to reuse the pattern known as assets versioning, where upon new release, you rename all your assets.
For instance, instead of login.html you'd use login-xyz.html as a name of a template. xyz could be a random value, or a checksum of the file. Checksum might be a slightly better option because if the new release is small (i.e. you fixed just some small bug in one file), if user loads any page but the fixed one, he/she will not be bothered with a reload - all other files will have the same checksums, they'll work with no interruptions.
This way, when an outdated Anguar app tries to fetch a template, it'd get a HTTP 404 error. As an addition to that, you could write a simple $http interceptor, which would detect a 404 response, and reload page automatically (or offer user an option of doing so).
There are modules which are capable of renaming assets, such as gulp-rev - but I never heard of using that for Angular templates. You might implement something like that on your own, though.
Of course you might want to keep both the new and old versions of files to allow users to work without interrupting them with a refresh. Depends on what your requirements are. I assume you're trying to avoid that, though.
Sample 404 interceptor (CoffeScript, as I have it handy now):
m.factory 'notFoundInterceptor', ($q) ->
return {
responseError: (response) ->
if response?.status == 404
# Reload, or warn user
return $q.defer()
# Not a 404, so handle it elsewhere
$q.reject response
}
m.config ($httpProvider) ->
$httpProvider.interceptors.push 'notFoundInterceptor'
Thanks for good answers.
It turned out that this problem solved itself for us. Every time we roll out a new release all the users sessions gets deleted and users will be sent to the login page. This will trigger a page load and fresh JavaScript/HTML gets loaded.
I've read about this issue long time ago, and one option is to do versioning on changed pages and application.js file.
For example on your version 1 of your application you can on your html file use something like:
<script src="js/angular_app_v1.js"></script>
Inside your routes also version the templateURL
templateUrl: 'templates/view_product_v1.html'
So when you roll out a new version you won't be overwriting templates and users already working will have the old version until they reload the browser but won't have version inconsistences.
Versioning of the assets using the file names would become unmaintainable for even a medium sided app.
Although it is a heavy weight approach for web assets you could look into content negotiation. This is where the call for a resource, generally a REST api returns the version of the resource, Content-Type: application/vnd.contentful.delivery.v1+json.. On the client you can check that the version matches what it expects. So if the client only knows how to load v1.1 and the resource responses with v1.2 the UI would know it cannot process that and should reload the page.
Another possibility is to load all templates up front in the UI. There are build processes in Grunt you can run such as https://github.com/ericclemmons/grunt-angular-templates that will combine all of your templates into a single file for delivery and then load them into $templateCache so no requests ever get to the server.
If you have some sort of server-side language you can build a filter in (.NET, Rails, Java or whatever), and pass along a version number with your template requests. If the version requested by the client is older than what's deployed, you'd send an error to the client. Your client would watch for that error ($http interceptor) and force a page-refresh to pull down the newer javascript code. (Maybe show an alert to the user first so they know what's going on).
You can preload all your templates into a $templateCache and serve them as one templates.js file. There is a gulp task for this https://www.npmjs.com/package/gulp-angular-templatecache. Then your application will load all templates in a single request together with application scripts on start up, thus they will be in sync. Read http://www.johnpapa.net/angular-and-gulp/ for more info.
It always makes sense to have a version number and use it when syncing resources. It's not only a good practice for the use case you described, but also for other situation, such as rolling back to a specific version or having two versions live and usable (for example in order to let some users preview the next version)