node js common practices

Question

I've been reading up on a few node tutorials but there are a couple of best/common practices that I would like to ask about for those out there that have built real node apps before.

1. Who do you run the node application as on your linux box? None of the tutorials I've read mention anything about adding a node user and group so I'm curious if it's because they just neglect to mention it or because they do something else.
2. Where do you keep your projects? '/home/'? '/var/'?
3. Do you typically put something in front of your node app? Such as nginx or haproxy?
4. Do you run other resources, such as storage(redis, mongo, mysql, ...), mq, etc..., on the same machine or separate machines?

Answer 1

Visit the following links::

nettuts

nodetuts

lynda nodejs tutorials

Answer 2

Here's what I think:

1. Using separate user for each app is the way I'm doing this.

2. I keep it in /home/user/ to make sure that only user (and root of course) has access to the app.

3. Some time ago I've created my own reverse proxy in Node JS based on node-http-proxy module. If you don't want to use reverse proxy then there's no point in putting anything in front of Node. There's even more: it may harm the app, since for example nginx can't use HTTP/1.1 (at least at the moment).

4. All resources I run on the same machine. Only when I actually need to distribute my app between separate machines I start thinking about seperate machines. There's no need to preoptimize. App's code is a different thing, though.

Answer 3

1. Best practice seems to be to use the same user/group as you would for Apache or a similar web server.

   On Debian, that is www-data:www-data

   However, that can be problematic with some applications that might require higher permissions. For example, I've been trying to write something similar to Webmin using Node and this requires root permissions (or at least adm group) for a number of tasks.

2. On Debian, I use /var/nodejs (I use /var/www for "normal" web applications such as PHP)

3. One of the reasons I'm still reluctant to use Node (apart from the appalling lack of good quality documentation) is the need to assign multiple IP Ports when running multiple applications. I think that for any reasonably sized production environment you would use virtual servers to partition out the Node server processes.

   One thing that Node developers seem to often forget is that, in many enterprise environments, IP ports are very tightly controlled. Getting a new port opened through the firewall is a very painful and time-consuming task.

   The other thing to remember if you are using a reverse proxy is that web apps often fail when run from behind a proxy - especially if mapping a virtual folder (e.g. https://extdomain/folder -> http://localhost:1234), you need to keep testing.

4. I'm just running a single VPS for my own systems. However, for a production app, you would need to understand the requirements. Production apps would be very likely to need multiple servers if only for resilience and scalability.

Answer 4

I am guessing this question is mostly about setting up your online server and not your local development machine.

1. In the irc channel somebody answered the same question and said that he uses a separate user for each application. So I am guessing that this is a good common practice.

2. I mostly do /home/user/apps

3. I see a lot of nginx examples so I am guessing that is what most people use. I have a server with varnish in front of the a node.js application and that works well and was easy to setup. There are some pure node.js solutions but for something as important as your reversed proxy I would go for something that is a little more battle-tested.

4. To answer this correctly you probably have to ask your self. What are my resources? Can I afford many small servers? How important is your application? Will you lose money if your app goes down?

   If you run a full stack on lets say one VPS then if there is a problem with that VPS then only one of your apps is affected.

   In terms of maintenance having for example one database server for multiple apps might seem attractive. You could reason that if you need to update your database to patch a security hole you only need to do it in one place. On the other hand you now have a single point of failure for all the apps depending on that database server.

   I personally went for many full stack server and I am learning how to automate deployment and maintenance. Tools like Puppet and Chef seem to be really helpful for this.

I only owned my own Linux servers for the last 3 months and have been a Linux user for 1.5 years. So before setting up a server park based on these answers make sure you do some additional research.