Deploy NodeJS server on production server with grunt - node.js

I'm currently developing a web application with NodeJS.
Grunt is used for deployment and I used to run the server using following shell command.
NODE_ENV="development" grunt
This automatically merges, minifies and starts the node server.
On production server, I run following command to start the server in production environment.
NODE_ENV="production" grunt
This starts the server, but when I disconnect from the server (from ssh), it stops after sometime.
Is it possible to keep the NodeJS server running using grunt-deploy npm?

You will have to daemonize the node process. There are a lot of ways to do this and a lot of libraries out there that will handle this for you such as forever and pm2.
As for how you do this specifically, it depends on many factors like what grunt is actually doing, the availability of libraries, etc. etc. You could use grunt-forever to use forever within Grunt (this seems to be an old library, though).
PM2 also has documentation on deployments. You can update the script to be /path/to/grunt and pass the tasks to run as arguments.
The simplest solution may be to use
nohup NODE_ENV=production grunt &
...but this has not worked consistently for me in the past.

Related

How to run a webpack application forever on a remote CentOs 6.8 server

I am about to deploy my first application on a centos 6.8 remote server. Actually this application is a react.js client which uses webpack for packaging. I have been able to copy the project on the server with file zilla, and can only run the application with npm start which is translated to nodemon src/server.js --ignore components using putty. The issue in this method of running the application is that the application stops running when I close the ssh client. Is there another way of running the application for an indefinite period of time remotely?
Actually you shouldn't do that, because looks like you are trying to use webpack development server in production.
You must generate production build with webpack and serve generated files statically with any web server.

How to deploy a socket.io from nodejs on Tomcat

Here's the thing, I have a folder, using Nodejs and socket.io(it's a chat) and I also have a server running Tomcat 8. I have worked with .war and .ear files before in Tomcat, but I'm new in this nodejs deployment thing.
Do you guys have like a tutorial or can you explain me how can I like package my app and then deploy it, or upload the folder, I don't know, something.
You don't need tomcat to run your node.js application. Just be sure node is installed on your server and the port you are using is allowed on your server's firewall and you are good to go. (Don't forget to install your npm packages through your packages.json of course)
Usually a node.js app is run like below;
node server.js
And that's all. If you'd like to keep it alive or restart in any case of issue you can use forever (https://www.npmjs.com/package/forever)
If you want to load balance with reverse proxy or if you want to configure ssl etc. you can use nginx or haproxy etc.
If you want to automate your deployment you can create a hook to your git source (github, bitbucket etc.) and write down a script to stop / start your node processes, fetch modified files, install npm packages etc.

Grunt: documentation on how to run these before main program

I want to run my app like normal:
node app.js
but before that happens, I want to ensure that a particular grunt task is run first.
I am having trouble finding documentation on how to automatically run (and complete) a Grunt task before starting a node command.
To be more specific, I have TypeScript files that I want/need to compile before running my node.js application.
Is there a way to always run the compilation (with Grunt or another way) before running node? Perhaps I could do a simple synchronous call in my app.js to run Grunt, but that wouldn't be cool would it?
You could use grunt to automatically compile typescript into a folder. Then you use nodemon in another window which is watching for changes in that folder.
Then when you change the typescript files, grunt runs (if you have set up grunt-watch) and after compile nodemon restarts the application.
You can run any scenario with Grunt. Here, you can use both grunt-ts and grunt-shell tasks to run your program/server.
First one compiles/transpiles your code. Second one allows you to run any shell command, such as node my_file.js.

What are the main differences of demeteorizer and meteor bundle?

Having gone through and used demeteorizer. I wonder what are the main differences between setting up meteor vs demeteorizer and running it via node; on own server?
meteor only
hot swappable code?
problem in maintaining packages similar from production and dev
same meteor versions running on prod and dev
hardcoded environment settings (i.e. mongo)
demeteorizer
platform independant as this auto bundles dependancies and uses pure nodejs
organise and maintain mongodb how you like (backup scripts etc)
I have been using demeteorizer (packaging->upload->running forever), but wonder if there are any performance or issues in the long run.
I have seen packages such as "authentication" running okay locally but very slow on the test server (hangs on submit, indicating sync problems?)
thanks in advance.
ref: https://twitter.com/SachaGreif/status/424908644590030848
Demeteorizer builds on top of meteor bundle with one small difference: Demeteorizer builds a package.json for you and deletes the node_modules directories.
Without demeteorizer you would have a bit of trouble deploying your app, particularly if it was on a different platform to the one you built your app on.
If you see meteor's own docs, you have to remove fibers and manage your npm modules yourself, manually. With a package.json you can run npm install and have them all installed for you, including ones from packages.
Why is this useful? For services like modulus it means you can upload an app and have it install all your dependencies for you without you having to think about it, as if it were an ordinary node-js app.
Everything that applies to meteor bundle will also apply to demeteorizer as it is still the same meteor bundled app, just with the package.json. So you can use forever, hard coded/environment based settings, etc the same way.

How to test node heroku tasks in local environment

How do I test a heroku node task on my local machine using the heroku runtime environment (foreman?)
I can successfully run my task like so: node my_task.js. Now I need to (a) make it an executable in the bin directory, which will make it dependent on the location of the node binary on the system, and (b) I need this specific task to use environment variables defined in my .env file, which I can't mimic by just running it with node unless I hard code them, but that would defeat the purpose.
Is there a way to use foreman or heroku cli to run a task as it would be run in the heroku environment?
I spoke with Heroku support and figured this out. I didn't realize you can use foreman to run other processes:
foreman run node bin/my_task works for me. That way I can also keep the shebang node path as app/bin/node instead of having to switch it to usr/bin/node for my Ubuntu box.

Resources