How to run Apache and Node.js together (the right way) | Hacker News Reader

How to run Apache and Node.js together (the right way)

gist.github.com

26 pointsstagas19 comments

Isn't the advantage of proxying something like node that you can serve the static files and a cache through the web server which works well for that?

If you're using Node as an app server in the context of a larger website with other components, yes. However, if your app is primarily Node.js driven, you may not want Apache standing in the way. Node.js is used to drive some really cutting edge services like WebSockets. I have no idea how gracefully Apache proxies something like WebSockets to a back end app server. I have a feeling the Apache worker process gets tied up for the duration of the socket session. That's not good.

If your entire website is run by your Node.js app, a better approach would be to use Node.js as your primary app/web server, and embed your static assets using a separate domain. For example, you'd use static.mydomain.com for all your static assets, which would point to Apache/Nginx, while your page requests are all handled by Node.js.

Apache doesn't handle large numbers of open/long-lasting connections like node (or nginx) does. Further, it will completely fail to reverse-proxy websockets (as will anything above layer 2 at this point.)

The best solution is to have your static files on a CDN.

The point is that putting a Node.js server behind a reverse proxy that uses threads (or processes) for concurrency is silly, since it quickly becomes the bottleneck, negating any benefits Node's asynchronous event-driven architecture provides.

If you want to do what you're suggesting you should use an equally performant web server like nginx, which is also asynchronous/event-driven.

WHM cPanel? Seriously?

A lot of us have no choice when at work.

Yet you're able to run Node.js in production?

I could if I wanted to. However if I disabled the control panel other people would FREAK OUT because they would no longer be able to administer the more simple sites without me around.

Edit: we have that parallels/ensim thing rather than cpanel but the point stands.

Gotcha. Never ceases to amaze me how some parts of the world work...

I hope I haven't made it sound like we're disorganised or we don't have any process. Its just that as lead developer my opinions are trusted, and if I am convinced that using node.js on a slightly more experimental site is a good idea, then people will believe me. I have some free reign to experiment, as long as I don't make things more complicated for our core business. I think it is a good balance.

As it happens I wouldnt use node.js in production right now, but thats not the point.

Yeah, no worries, I didn't mean to be condescending. That all sounds totally reasonable... I just forget there are people that don't live on the command-line sometimes.

You should also do it this way with nginx if you want websockets to work. This is because nginx proxy doesn't currently support http 1.1 or keep-alive.

If you are designing a new site, and you are concerned about performance, I would strongly suggest serving static (read: cacheable for a whole day) files which include javascript which talks to Node on a port. Then, who cares what the port is, as long as it works?

On the other hand, if you are integrating Node with existing code, say PHP, then use TCP sockets behind a firewall, or Unix sockets for communication.

Listening on an unusual port can be a problem for users behind various corporate, hotel and public wifi firewalls.

do you mean it's a problem for browsers or for the servers?

Why would anyone want to run Apache and Node.js? What is so special about Apache? Use nginx.

And what do you mean by "with"? Just have Node listen on a different port, what's the big deal about this?

Most people don't like their public web servers to be on ports other than 80/443.

If you want the resources served by Node.js and another webserver to be on the same domain/port you need some sort of proxy configuration.

Okay but I am assuming that most web servers are not run from users' private computer networks, but from dedicated data centers, or somewhere in "the cloud".

But yea I agree if you want node to listen on port 80 then you either forward certain URLs to it (using nginx this is easy), or or you just get another IP to point to the same machine, which is probably better.

In any case, if you only have one IP, it would be wiser to have Node.JS proxy to Apache, not the other way around.

Reply on news.ycombinator.com