Hacker News Reader

Comment by danpalmer | Hacker News Reader

Isn't this all better implemented in the nginx/apache server in front of the application?

I've just done a very similar thing for my Django hosted website, but didn't touch Python at all for it.

Edit: Here's a blog post where I detail the steps to set this up in Nginx - https://news.ycombinator.com/item?id=9256200

View on HN

Yes, I think is better to put nginx in front to handle this and sooner or later you will need some kind of reverse proxy as soon as your application grows. The reasons might be load balancing or just to map components of your app like "app.com" and "app.com/api" being different applications.

One big difference to note is that nginx link to the local openssl while node binaries embeds an openssl. If there is a bug in openssl I can apt-get update/upgrade and I get the patch very early.

Personally I think nginx is awesome. They are going to support JavaScript soon, but I have done things with LUA and is great too.

> They are going to support JavaScript soon

Whoa. Slow down. They have only confirmed replacing their custom configuration language with JavaScript and hinted at an official JavaScript module [1], as opposed to the existing third-party module [2].

Bundling a Node.js-like JavaScript api layer with their official module would be a logical next step, because nginx is an event loop anyway. But, I highly doubt JavaScript will be anywhere near the Nginx core.

[1] http://www.infoworld.com/article/2838008/javascript/nginx-ha...

[2] https://code.google.com/p/ngxv8/

Thanks for the clarification, that's what I though but my comment was quite vague

>Personally I think nginx is awesome. They are going to support JavaScript soon

Whaaaaaaat?

Can't find a better source but it was announced few months ago:

http://www.infoworld.com/article/2838008/javascript/nginx-ha...

Edit: added reply to 'vkjv' below as I have hit the comment threshhold and have been unable to reply to this account. Since HN seems to be somewhat unsure of node's concept of IO (why I imagine the downmods) and why it's significantly different to common Python and Ruby setup (Tornado and EventMachine excepted).

The main point of nginx is event based, non-blocking IO. That's why traditionally blocking languages (like your Python setup) use nginx for static content and their own engines for dynamic stuff.

However event based, non-blocking IO is also the main point of node. So most people using, say Express would use the express module's inbuilt 'static' middleware rather than add an entire webserver to replicate the built-in functionality.

Unless there's a compelling reason to do SSL elsewhere (for example, an AWS ELB would allow you to isolate & consolidate your SSL in a separate layer) then you'd want to avoid adding complexity.

Edit: reply to vkjv:

> it still needs to serialize that data from I/O to the request and that is both blocking and slow.

No. If the socket wasn't ready, node wouldn't block writing data there. streams are evented and that includes sockets. Hence the callback on socket.write() https://nodejs.org/api/net.html#net_socket_write_data_encodi...

    var socket = new net.Socket();
    socket.write(...)
    console.log('Yep sockets are non blocking too')

This is why both node and nginx have outperformed each other in different tests.

Agreed, if you're already using nginx for other reasons, eg, load balancing, you should use nginx for SSL. If you're not, think carefully before doubling the size of your stack without specific reason to do so.

While node.js is great at non-blocking IO, it's not great at the blocking kind. E.g., shuffling bytes.

While you are correct that node.js is happily not blocking the main thread while reading from disk, once that returns it still needs to serialize that data from I/O to the request and that is both blocking and slow.

I highly advise that you don't use node.js to service static content outside of a development environment. And if you are already using nginx in front of node, you might as well use it for SSL.

As a bonus, nginx does a great job proxying multiple node.js processes. You could also use the cluster module, but last time I checked, that was still marked as experimental.

I know that the parent replied already, but I want add that using node for static content is a good idea. I/O is what Node excels at. As long as you use the non-blocking API to load content, you should get good throughput. What Node is bad at is processing dynamic things. If your templates are CPU intensive, you'll block Node.

This is why I'm, to this day, confused about building whole websites on Node. Dynamic, templated web sites are computation intensive (without result caching). Sure you can have N-Nodes running for N cores. This will minimize blocking. I/O for DB is time intensive so Node will pickup other workloads while it waits. So everything averages out, but it still an interesting thing often overlooked.

> it still needs to serialize that data from I/O to the request and that is both blocking and slow.

That's incorrect. See edit to parent post (sorry I couldn't reply earlier).

I just recently was in this same situation (deciding whether to serve static via express' static middleware or nginx), and nginx proved to be a better choice - the response (on a non-loaded server) was faster, and less server CPU time was used up.

Wasn't a scientific test, but the results were consistent enough for us to decide to use nginx.

(FWIW, neither nginx nor node did SSL termination - we have haproxy in front of them taking care of that and the load balancing itself).

Back in November I spent a lot of time trying to get an A+ for my site throwpass.com. I couldn't get forward secrecy to work and found several places saying node.js doesn't support it. So I ended up forwarding through nginx.

Makes sense. This is likely the same PFS issue covered in the article.

Sometimes you're running a single application via AWS OpsWorks or so, and your application is handling the SSL because you don't want to pay for an elastic load balancer to handle the SSL.

Fair enough, I'm not familiar with that service.

Running a Node.js application without a reverse proxy in front of it sounds like poor practice though, particularly from a security standpoint.

Do you have any particular security holes in mind that nginx guards which node.js / io.js are open for ?

Separating your TLS server from your app server also shields your app server from leaks in your TLS server. See: Heartbleed.

True, however the higher the number of different software packages that participate in your application's operational environment, the higher the chances that one of these exposes security holes. You have to make a trade-off between complexity and increasing security by isolating pieces of your stack.

Not off the top of my head, although I know the recommendation at least used to be that Node was not run with full public access.

I think it makes sense to separate the security and low level details of serving a public site, and the details of hosting an application though. This is common practice with Django, using gunicorn and nginx, and I believe with Ruby as well in a similar manner.

Django and Ruby /can't/ serve static content at any speed as they block their main thread. Node and nginx use the same model for io, as does Tornado and Eventmachine (though the latter two are nowhere near as popular).

You can at least configure some basic sanitizations, so you'r app doesn't have to deal with them. Examples of the top of my head, are normalizing slashes and removing invalid headers.

Whether that's worth it is another question.

Reply on news.ycombinator.com