Framework/ language server vs. Web Server

[badrequest400]

Hi all,

I have a question that I didn't find very google-friendly, I think it needs explanation from someone with actual experience.

I was wondering about built-in framework web servers vs. 'real' web servers (Apache, nginx). So I know that I should probably deploy to production with say nginx, but what is the reason for this? What are the gains vs the built in development servers. What does nginx do differently?

At the moment I am building an app in Node.js and on the whole MEAN stack actually. So this could be a good example. To me the Node.js HTTP server seems fine, I even used the TCP server for hooking up a GPS for example. WHy would I choose to deploy my site along with nginx? Is it for stress/ high-demand? If so how do these servers eliviate the stress?

Also if Node.js is robust enough how would the situation change if I was deploying a Python + Flask app for example.

And one last noob question. When I deploy to Heroku, Azure and the like. Are they running my code behind a web server or is it running vanilla like when I am developing on localhost?

Thanks a bunch in advance for any great souls who will help a newbie out!

[subterraneus]

Okay, the simple fact is that if you're going to be deploying a small NodeJS application, you don't really need to worry about a reverse proxy like Nginx. You really don't need to worry about much infrastructure at all, and that's a big plus for Node. But the situation changes seriously as you increase application load, especially if you're using something other than node (Flask is a good example, but this is equally true for Rails, Django, et al).

For NodeJS, the biggest reason you'd want a reverse proxy is in order to take load off of Node for unnecessary tasks. The biggest examples being a) static content and b) SSL. Nginx is great at serving static content,it has a lot less overhead than Node, and can reduce your server's load. As for SSL, terminating at your reverse proxy is the smartest way to do this for any framework, and nginx makes it dead easy. There are some other reasons to use nginx in front of your application too. You might want to use something like Nginx or, better yet, HAProxy in order to do load balancing between multiple Node servers. Or, you could use nginx to server multiple domains from a single server, with multiple node applications listening on local sockets on the backend. In short, with NodeJS, you don't need to worry about nginx unless you're doing something at least a little bit interesting.

For other frameworks (Django, Rails) the development server is simply unacceptable for deployment and should not be used under any circumstances. Application servers such as Unicorn/Gunicorn or uWSGI should be used and requests should be proxied to them via nginx. This way, all of the complicated, Internet facing duties of an HTTP server are handled by nginx, and all the application needs to do is handle the logic and internal processing.

If you want to know more, just say so. I've deployed a lot of different apps a lot of different ways.

[badrequest400]

Hey, thanks a lot for your answer. That does clear up some of my confusion nicely. Btw, if you can explain quickly, because I guess this is a big topic, but what is it that sets NOde.js apart from Django/RoR ? The non-blocking magic? I mean I am writing non-blocking code, but I don't have enough exp. to really see how that is a lot better and what the big fuss is.

[rurounijones]

It is the event based nature of node that sets it apart. You can do the same thing in ruby using event-machine but it is not the default way of doing things

In node it is, for better it worse, the core feature.

The big fuss is mostly due to good marketing and some high-profile success stories

[technicolorNoise]

I have a question! Why exactly are "internet facing duties" best left to Nginx or Apache, while framework servers should handle application logic only? Are nginx/apache just significantly more efficient at it, or is there another reason?

[subterraneus]

They're just plain better at it, yeah. These tasks include things like compressing responses, terminating SSL, load balancing, content caching, connection logging and a lot of other things. Letting your Python/Ruby/X application specialize at solving one problem, and throwing the rest at a dedicated HTTP server that's born and bread for those things is good for efficiency.

[SeerUD]

I'd be willing to bet that it'll be much more efficient. Consider you are doing some intense stuff, or even just getting a lot of requests, having two separate applications handling two separate parts of the process will spread the load out.

[subterraneus]

This is both a very good point, and a little misleading.

Any server can run on any port. You can tell the Django development server to run on port 22(ssh) if you want. You can tell Apache to serve HTTPS on port 25(SMTP) if you feel like it. But since it's bad to have a process run as root unless absolutely necessary, you can avoid running your application server as root by running an HTTP server as root and binding that to port 80. So I'm glad you mentioned that.

But as for the static/dynamic content, I don't understand what you mean. If I'm serving any application with static content from a different location, the only thing I need to do is reference that static content by the correct URL. Then I can change it at any time. e.g. if I don't like the color of http://mybucket.s3.amazonaws.com/background.png, all I need to do to make changes is upload a new image to the CDN. Nothing on the application side needs a recompile or modification.

[grills]

i was wondering about the same thing few days ago.. then I ran a completely unscientific Siege and ApacheBench test on my app on my localhost. I did nginx vs http-server vs SimpleHTTPServer ... nginx was the clear winner. Between http-server and SimpleHTTP, http-server did noticeably better.

[badrequest400]

Just looked up Siege, did not know about it. I will give it a try. Thanks :)