Does Koa need Forever? - node.js

Koa has implemented not having a web server shut down when one page has an error. My question.... is this error handling behaviour robust enough that one no longer needs to use Forever when hosting a node site?

You should still use forever (or nodemon, a bit easier to use in some cases) to keep your server running. There are other things that can cause it to crash in a production environment, not just bad requests.
In development, I've seen insane uptime on some koa apps without using forever/nodemon, but I would not do this in production. It's asking for a 3 am phone call :)
If you're using Linux/Unix, you should also consider using tmux to keep it running in a separate terminal session, or it can timeout with your terminal session. (Type tmux new -s koa to get started). Here's an article on using tmux with upstart: https://bowerstudios.com/node/953

Related

Compute Engine and NodeJS, keep online

I have a website already developed with node.js and sails.js on "Compute Engine" but to start it, necessarily I have to write "node app.js" in the SSH console of browser. But there is a problem (since I am new to Linux and Google Cloud :)), if I want my Node app it keep online, the SSH window must be open, if I close, the Node application will terminate, like Ctrl+c. So it makes no sense to have my computer turned on, just to have the active window. So, how to keep my NodeJS app online without being in the presence of SSH console?. I know the question is illogic to some, but I would appreciate if you help me. Thanks
First of all it is not related to Compute Engine nor Node.js.
You mention that the application will terminate if you press ctrl+c and that's correct because you are running your application in the foreground instead of background. To run your application in the background you can either launch your app like this:
node app.js &
Or you can launch with node app.js and then press ctrl+z.
But just sending the application to the background wouldn't help. As soon as you disconnect from your ssh session, all programs started (background or foreground) will receive a HUP signal, in node.js you can handle that signal but the default behaviour is to close:
On non-Windows platforms, the default behaviour of SIGHUP is to terminate node
One thing that you can do to ignore the SIGHUP signal is running your app as follows:
nohup node app.js &
If you do this, your application will continue to run even when you close your ssh session. Another way to achieve this is by using the screen.
This will help you on very early stage and for development but I don't recommend using neither of these things for production. Eg: if your application crash it should be restarted. The recommended way is to use a service manager that comes with the OS: upstart, systemd, init, to name a few.
You can install forever module (https://www.npmjs.com/package/forever) to your Google compute engine using SSH window.
npm install forever -g
Then, in your node server directory, execute your server using forever.
forever start [YOUR_SERVER_FILE.js]
Now, if you close the SSH window, your node server is still on !!
Good luck!
The best solution would be using a module called forever:
https://www.npmjs.com/package/forever
You can use it this way:
forever start your_script.js

NodeJS Broken Pipe causing my Express api to stop working

I have looked for answer for this question and have to find anything quiet like what I experience!
I set up an Ubuntu instance on AWS, standard configurations, medium tier.
I ssh into the server, and then I have a script running in Node, which I launch with sudo nodejs server.js .
When it runs, it has a few REST endpoints which work just fine, and those write to a mongodb (which, also works just fine). However, if I leave my computer and come back the next day, I get the standard SSH broken pipe, which is fine. But! When I try to use my REST api at that point, the node server.js is clearly not running.
I am the only person consuming this api, so I don't think errors are bringing it down.
Has anyone experience anything like this? Perhaps there is a configuration I am missing?
A friend just answered it for me,
sudo nodejs server.js & > mylog.out
This makes it run in the background and print the stdout to a log instead of nowhere (nowhere due to broken pipe)

What are possible solution or script that can be used for server crash detection and trigger procedures?

I'm developing on the same server where I host some webpages, in this case with Ajenti, nginx and node.js installed on a Ubuntu Server, and I noticed that when I crash the server in a test, I need to log in to ajenti or ssh and restart the webpages.
This made me wonder if nginx or Ubuntu can detect such a crash like a 502 Bad Gateway Error and if there is also a command or tool to restart the webpages?
With this I could probably script it all up and get the webpages restarted, automatically, every time I do something to crash the server.
One solution might be to use something like monit which can (among many other things) check for (and optionally restart) crashed processes.

Way to connect Clojurescript Repl to running node process

I was wondering if there is a way to connect a cljs repl to a nodejs process that I already have running, that is say in debug mode and stopped at a breakpoint.
So I know there is https://github.com/bodil/cljs-noderepl, and I have this running fine, but it starts up a 'sandboxed environment' as it says in the documentation. I'd like it to connect to a node process of my choosing (e.g. node debug my_project.js).
I can use the normal node debugger, but that's plain old JS, not CLJS.
I also looked into nRepl, but that doesn't seem to be the solution.
Is what I'm asking for possible at the moment, or can I only do this type of repl in a browser environment?
Thanks
I know it's a bit late, but I don't think node has a way to communicate with a running enviroment. nREPL actually is a step there as it will listen in a nodejs app and let clients send it code, but I haven't seen a nREPL server for node.js clojurescript.
The best I've gotten is https://plus.google.com/112151928607622120183/posts/fNr5h8BgLEp

How to set up a node.js development environment/server (Ubuntu 11.04)

I am trying to set up a development environment for node.js. I assumed at first that it requires something similar to the traditional, "localhost" server approach. But I found myself at a loss. I managed to start a node.js hello world app from the terminal. Which doesn't looked like a big deal - having to start an app from the console isn't that hard. But, after some tweaking, I found out that the changes aren't shown in the browser immediately - you need to "node [appName here]" it again to run.
So, my question is:
Is there a software or a tutorial on how to create a more "traditional" development server on your local machine? Along with port listening setup, various configurations, root directories etc (things that are regular in stacks like XAMMP, BitNami or even the prepackaged Ubuntu LAMP). Since I'm new at node.js, I can't really be sure I'm even searching for the right things on google.
Thanks.
Take a look at :
https://github.com/remy/nodemon
it'll allow you to do - nodemon app.js
and the server will restart automatically in case of failure.
To do this I built a relatively small tool in NodeJS that allows me to start/stop/restart a NodeJS child process (which contains the actual server) and see/change configuration option and builds/versions of the application, with admin options available on a different tcp port. It also monitors said child process to automatically respawn it if there was a error (and after x failed attempts stops trying and contacts me).
While I'm prohibited from sharing source code, this requires the (built-in) child_process module, which has a spawn method that returns a child process I guess, which contains a pid (process id) which you can use with the kill method to kill said child process. Instead of killing it you could also work with SIGINT an catch it within your child application to first clean up some stuff and then exit. It's relatively easy to do.
Some nice reading material regarding this.
http://nodejs.org/docs/v0.5.5/api/child_processes.html

Resources