3 ms·

Could someone clarify something for me? Is http.createServer robust enough for production? It is my understanding that running it as is in production is not a

Could someone clarify something for me? Is http.createServer robust enough for production? It is my understanding that running it as is in production is not a good idea. You want to at least configure nginx between node and the world. If that's the case, doesn't that undermine the whole "focus on your application, not the configuration" point he's making? Sure you can call startServer multiple times, but then you would still have to focus on configuration.

viscanti 15y ago
I don't want to sound like I'm over qualifying things, but it really depends on the situation. For most applications http.createServer will be robust enough for production. There are node based solutions for dealing with load balancing, that would make nginx unnecessary in almost all cases. It really comes down to tradeoffs. If your primary concern is the most simultaneous connections, then you'll need to find a special tool, and Node or most other non-haskell web frameworks probably aren't for you. Node makes it really easy to do some things. That focus makes some other things more complicated than they should be (because it's asynchronous, you end up needing to deal with flow control, often times using queues that mitigate some of the asynchronous advantages). It's like everything else with computers. There's tradeoffs. http.createServer can be used when it can be used (which happens to cover most use cases).
- deleted 15y ago
  [deleted]
jahewson 15y ago
To the best of my knowledges: yes. Using nginx in front of node seems to have originated as a non-root way of getting access to port 80, prior to node supporting setuid. A better way on Linux is just to use the kernel TCP routing, for example: sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080 However, if you're using HTTP virtual servers and you already use nginx, sure, place node behind it.
peterbraden 15y ago
it is robust enough in terms of scaleablity yes. Most people are just using nginx as a load balancer. This only addresses servers that you expose to the world though - I think one of the less publicised strengths of making creating servers easy is that it allows you to make internal servers for services trivially. And using a service oriented architecture is a great win.
2mur 15y ago
The one catch with nginx is that it doesn't support http 1.1 (ie. websocket support). So if you want that you have to reverse proxy with something that does like haproxy or node-http-proxy.

viscanti 15y ago

I don't want to sound like I'm over qualifying things, but it really depends on the situation. For most applications http.createServer will be robust enough for production. There are node based solutions for dealing with load balancing, that would make nginx unnecessary in almost all cases. It really comes down to tradeoffs. If your primary concern is the most simultaneous connections, then you'll need to find a special tool, and Node or most other non-haskell web frameworks probably aren't for you. Node makes it really easy to do some things. That focus makes some other things more complicated than they should be (because it's asynchronous, you end up needing to deal with flow control, often times using queues that mitigate some of the asynchronous advantages). It's like everything else with computers. There's tradeoffs. http.createServer can be used when it can be used (which happens to cover most use cases).

deleted 15y ago
[deleted]

jahewson 15y ago

To the best of my knowledges: yes. Using nginx in front of node seems to have originated as a non-root way of getting access to port 80, prior to node supporting setuid. A better way on Linux is just to use the kernel TCP routing, for example: sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080 However, if you're using HTTP virtual servers and you already use nginx, sure, place node behind it.

peterbraden 15y ago

it is robust enough in terms of scaleablity yes. Most people are just using nginx as a load balancer. This only addresses servers that you expose to the world though - I think one of the less publicised strengths of making creating servers easy is that it allows you to make internal servers for services trivially. And using a service oriented architecture is a great win.

2mur 15y ago

The one catch with nginx is that it doesn't support http 1.1 (ie. websocket support). So if you want that you have to reverse proxy with something that does like haproxy or node-http-proxy.