I'm deploying a web app using react-redux soon and I was wondering if it was possible to let the user using the production version to modify a config file so that he can set his own initial settings.
Is it possible, after I run npm run build, to have a config.js file in the build folder that the user can go and directly modify?
If not, is there any better way to accomplish that using another strategy?
Thank you
If I understand correct you want to expose a API to change some of settings in config for end user and then somehow restart your API servers to apply those changes.
Always a dangerous way of doing things. You can expose functionality to change few of fields of config for end user and when applied restart the node process. There are few ways to restart node process from code itself or writing a hot script which monitors changes in source directory.
But beware its risky thing to do. Hope this helps.
Related
Some things to know:
I understand how to make a HTML / CSS / JS website.
I understand how to make a Node JS app and host it on Heroku
I encountered a problem that was very confusing and I still working it out. I am making a firebase project using their latest tree-shaking V9 SDK
import { initializeApp } from 'firebase/app';
I understand Node JS is meant for backend (it can't be run in a browser) so how am I supposed to "build" this into something that I can reference in a script tag? I've heard of webpack but that requires you to run npm run build so how is that practical in any way? That would mean every change I make I would have to build it?
Developer Testing:
How would one live preview this Node JS app on a localhost if Node JS can't be run in a browser? I would live to be able to preview this Node JS app and quickly make changes if that's possible.
I've heard of webpack but that requires you to run npm run build so how is that practical in any way? That would mean every change I make I would have to build it?
Yes, that's the general idea. You make changes to script files on your local machine (or network), and then in order to see the changes take effect, you rebuild the app so that a new bundle is generated. This bundle can then be hosted on your web server or development server, and once it's there, you can refresh the page to see the differences.
But almost all of this can be automated, resulting in it not really being much of a chore at all.
Nodemon is a popular tool that watches a directory for changes and can run Node scripts when a change is detected. With it, you could, for example, make a change to a file, and then it'll automatically rebuild your app.
For Webpack in particular, there's webpack-dev-server, which can automatically refresh a page when the app gets rebuilt.
So, during development, the workflow can be as simple as - make a change, then alt-tab to your browser (hosting the app on localhost) to look at the changes.
Bundles built for the purpose of eventually hosting them on the front-end can easily incorporate Node modules - the build process can take the code from the module, and the bundle produced can include that code. This sort of thing is extraordinarily common.
I am reasonably new to angular (5), and have noticed that the javascript files (vendor.bundle, main.bundle, etc) are being reloaded each time I visit a page.
Is there anything in particular I should be doing to make sure that these are held in a browser cache after the first time they are loaded?
I guess I would need to add a cache-control header, but am not sure where to put it in the code, or whether this is something that the Angular-Cli could generate
Angular have lib called Service workers, which simply can be installed in cli project by below cli command
ng add #angular/pwa --project *project-name*
Note: project name can be obtained from angular.json
This command do the most required configuration but still some other stuff is needed, Which can be found on the flowing link service-worker confi. but some of this configuration already done by previous mentioned command. but also more configuration may be needed in "ngsw-config.json" file.
But unfortunately i tested this inside spring war and still the big files still downloaded every time without any caching but if i deployed on http server direct it work perfect.
Inside Spring War Result
For More Info. Please Check the blob of Angular Service Worker - Step-By-Step Guide for turning your Application into a PWA
I'm currently trying to overwrite or change a value in my package.json from another file. Basically, package.json has a "homepage" value that gets built when I run npm run build. I wish to be able to change that value from my config.js or config.production.json files. I want my environment values all in the config files so it is easier to modify. However, when I run npm run build, it still loads my homepage value from the package.json.
package.json
{
"homepage": "/company/portal"
}
config.production.json
{
"configPath": "/newCompany/portal"
}
Thank you for your help
If you mean in general how to write a file in the client machine through a script in the browser, it isn't a thing allowed so easily and you will have also a lot of cross browsers issues implementing it by 0.
You could try to take a look to this library which seems quite good:
https://eligrey.com/demos/FileSaver.js/
You can also think to start an AJAX request to a node.js application for example which will write you the file easily on your system or provide a download, or in general to server side which will provide a file to be downloaded to the client.
But, from the case you explained, you just need to change the config file in your system, so considering you are using node.js, the easiest way is using node.js
It is usually strongly discouraged to put your env variables values inside a JSON file. It can seem that you keep things in order but most probably your code will be pushed somewhere and so opening the JSON file, anyone can see all your values of the env variables. And this is not a good thing.
In my opinion you should think to write your build script in order to take arguments when called, and then call the build passing the parameters. For example:
npm build --production
npm build --development
Depending on the parameters, you will set up the right configuration on the fly.
I hope this helps
I am writing a nodejs application with Angular as my front end.
For this I am having Git as my code management server.
For client, I am doing minification and it is ready for production.
But I am not sure, how to prepare server side files for production.
Do we need to just copy all the Git folders into production server?.
Let me know the best way to deploy nodejs server application.
You could use pm2 as your daemon to keep your nodejs app up all the time.
Try not to include node_modules in the repo, cause different machines have different setups/installations, you cannot tell if one package would work before you run it unless you npm install them.
If you are familiar with Docker, use it, pre-bundle all (include node_modules) files into the docker image, and you do not need pm2 here, Docker itself can restart automatically. This is the ideal approach.
It really depends on how you (or your company) want to organize the workflow and the size of the project.
Sometimes I too use a GIT repository, because then is really simple to update: just a git pull and (if server files got edits) a pm2 restart N command.
In this way, you dont have to install the whole development stack in order to compile (and minify) the bundles - I guess you work on your local machine where all the development tools are installed.
Keep in mind to use the --dev flag while installing packages that are only required in development mode, so you can keep the production server as slim as possible.
A good practice I found is to add some random tokens inside the final bundle filename (both for js and css) that get then injected inside the final html static files, to avoid the refresh the page loop.
Once you have the bundle files on your dev machine, just upload them to the server (ftp, git, rsync, sshfs mount, whatever you like) and (if server files got edits) restart/reload the node process (Im using pm2 for this, its really great). If you only edited client files, no reload is needed.
Starting from here, there a lot of ways more or less sophisticated to do the job, like git pipelines for example.. but depends on the situation.
Edit: this is a good article about task runner (gulp vs grunt vs vanilla npm), while may be a little off topic, it analyze some aspect of the common deployment process
I'm working on a Windows Store App (JavaScript/HTML/CSS) that will be deployed directly to devices in our enterprise.
I want to keep the datasources (urls to Restful web APIs) as part of the configuration rather than built into the app itself so that I can set them during deployment (e.g. to set test urls and prod urls).
More generally I want to store text variables in config that is external to the app and can be pulled in by the app somehow.
I thought I could set some environment variables or something but Windows Store Apps can't read them it seems.
Any ideas?
You could certainly make an HTTP request from the app on startup to retrieve a configuration file, but that of course assumes connectivity which may or may not work in your scenario. For a Store-acquired app, this is really the only choice.
In your scenario, however, you'll be doing side-loading through a Powershell, correct? (This is implied in installing directly to devices.) In that case, the Powershell script is running in full trust and will have access to the file system during the process. This means that the script can easily deploy a configuration file into the app's local appdata folder, which the app then picks up when it runs. The app package should also contain a default configuration file that it copies into that appdata folder if such a file doesn't exist on startup.
The documentation for the add-appxpackage script that does the install is here: https://technet.microsoft.com/en-us/library/hh856048.aspx.
Another option you might be able to use is to build different versions of your packages for test and production deployment. It is possible to configure the build process in Visual Studio to selectively bring in different versions of a file depending on your build target (e.g. Debug or Release). I have a blog that describes this technique on http://www.kraigbrockschmidt.com/2014/02/25/differentiate-debug-release-builds-javascript/. This would allow you to package different versions of a configuration file into the package, which you'd then read from the package install location at runtime or copy to appdata if you wanted to make changes at runtime.
I mention this method for building different packages because it's something that doesn't need you to do anything other than change the build target. It accomplishes what you would do with #ifdef precompiler directives in other languages, which aren't available for JavaScript.