4 ms·
How to run Apache and Node.js together (the right way)
- ladon86 16y agoYou 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.
- wwortiz 16y agoIsn'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?
- tlrobinson 16y agoThe 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.
- bradleyland 16y agoIf 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.
- aaronblohowiak 16y agoApache 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.
- bretthoerner 16y agoWHM cPanel? Seriously?
- JonnieCache 16y agoA lot of us have no choice when at work.
- steveklabnik 16y agoYet you're able to run Node.js in production?
- JonnieCache 16y agoI 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.
- steveklabnik 16y agoGotcha. Never ceases to amaze me how some parts of the world work...
- JonnieCache 16y agoI 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.
- steveklabnik 16y ago
- Rauchg 16y agoIn any case, if you only have one IP, it would be wiser to have Node.JS proxy to Apache, not the other way around.
- EGreg 16y agoWhy 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?
- tlrobinson 16y agoMost 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.
- EGreg 16y agoOkay 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.
- EGreg 16y agoIf 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.