Is it possible to update a route,model or controller.js file without restarting the Node.js Server?.
I'm currently dealing with a client who wants constant changes to the application in a very frequent event. And the application deals with user session etc.. Whenever we make any changes to the application it requires a restart for the update to get reflect, which is very expensive in-terms of an high traffic situation.
I have seen some server application providing a feature called Rolling Restart but again I'm not sure whether it is a good way to maintain the user session across the restart event. Or do we have any other solution to deal with this kind of situation.
You can restart a server without downtime yes, I recommend you take a look at PM2 https://github.com/Unitech/pm2
You can have multiple instances of node running and when you set a restart it does it gradually, making that you don't have downtime, it also distributes load to the different instances running so it speeds up your app, hope this helps :-)
Nodemon is what I have used before and I was very happy with it.
Install
npm install -g nodemon
then run your app with
nodemon [your node app]
Done
Related
So I am running a service in node which has a node js cluster usage meaning I am running the service with node js clusters... now I want to use pm2 and I use the pm2 cluster mode.
I wonder if it's a good thing to use both of them at the same time or should I use only one of them for better performance and stuff like that...
Any help would be appreciated
To take the complexity out of your architecture I would recommend to use PM2. It lets you efficiently manage multiple processes. It has many features including:
Auto restart an app, if there is any change in code with Watch & Reload.
An easy log management for processes.
Monitoring capabilities of the process.
An auto restart if the system reaches max memory limit or it crashes.
Keymetrics monitoring over the web.
As the processes are separated, now can start/stop/restart them with your pm2.config.js, i.e
pm2 start pm2.config.js // start all processes
pm2 stop app // stop app processes
pm2 restart smsWorker // restart smsWorker
I have a React app and I am saving some simple data to LocalStorage. All works well across refreshes, etc.
But when I run yarn build to refresh the built web after pushing a change, this will clear somehow the local storage.
I have a server setup with nginx and a reverse proxy, my web app being served through pm2.
Is this something expected to happen? Why does it happen and can it be avoided?
Thanks!
Actually when you use yarn to run your code on browser it basically create a fresh session on browser on every refresh. therefore you loosing your data.
Thanks to #Aslam_khan reply I found the solution:
Use npm run build instead of yarn build if you want to prevent LocalStorage to be cleared up on every new build.
I have a simple CLI application written in Javascript using Node that is for internal use by a small team. It runs in the Linux terminal as a CLI app. The app consists of a single ".js" file and requires a few Node packages. The problem I face now is how to deploy it to our internal team using a simple method that fits with our routine process of keeping end user computers updated.
Our app needs to be installed once per workstation / laptop and to be available to all users on that computer. Any user should be able to open a terminal and enter the command to run the app.
It seems a lot of people have discussed using Javascript for shell programming, but this issue of deploying the completed app is not widely discussed. I have not found anything on the topic. So far I have been recommended solutions that are appropriate for either development environments or web servers.
This app is not a web app and it is not deployed on a server. It needs to run offline. I am also not asking about developing or maintaining the app on a development workstation.
The installation process should ideally be as about simple as installing a shell script in /usr/local/bin and setting permissions so all permitted users on a computer can run it. We are looking for an installation method like this:
copy the Javascript file only once to each computer (to a location on the $PATH) and make sure the Node packages are available globally on that computer.
I specifically want to avoid having to do an npm install for each user account on each computer.
I also want to avoid having to update Node packages for each user account on each computer.
A developer will keep the app updated so it is always compatible with the latest version of the Node packages, and all computers it is deployed on will always have the latest versions of those packages installed.
One specific problem I encountered is discussed here, but the answers assume a different set of requirements (such as the need for "multiple applications running on different package versions").
For those requirements, if the actual problem is solving the EACCESS error (you should edit the question to include that information), then you should look at the permissions of all directories, and make sure that the user account that manages node packages on each computer has correct permissions.
One way to do that is to give /usr/local a special group, set the sticky bit with chmod (see man chmod), and use chgrp -R on the existing tree.
Then make the installing account a member of that group, and don't use sudo for npm install -g.
(Never using sudo for installations into /usr/local has the additional advantage that you can't accidentally install something somewhere else, for example because you didn't set paths in this local package source correctly.)
We are using these two approaches for similar deployments:
the programs live on a specific network mount. All users can run the same package from there. The developer only updates this package. No copying to local machines.
we use a simple deployment script which runs on all machines on logon. It pushes and copies the latest version to the local machine.
nodeJS file — main.js
Have a website with button which can call function from main.js. I not know how restart nodeJS script correctly. Now I run process.exit() in main.js and then, with nodemon trying restart application but nodemon tell me “[nodemon] clean exit - waiting for changes before restart”. So how correctly restart application?
Clean exit means exit code 0, which means, "Everything is okay! I intended to exit." Usually, programs that exit normally don't specifically intend to be restarted. nodemon is choosing to consider that the end of the program's operation, which isn't a totally insane thing. However, nodemon being a process manager for daemons, probably ought to just restart it anyway. I would suggest using PM2 instead, it is what most people use in production and it will correctly restart the process since its whole job is to keep services running.
Aside from all of that, I want to note that allowing a browser to restart your app is probably not a good idea. If you have carefully designed your app to be stateless and handle random shutdowns and it is clustered, etc. then maybe it is fine. But generally I would not recommend it. At the very least, make sure the request is authenticated and authorized.
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.