[synergy20]

Considering nginx is really just good at serving static content(maybe CDN uses it a lot) and the rest are all proxying, and Apache can handle static and dynamic contents at the same time, this tells me many web server nowadays are no longer simple http+cgi, but with app servers(e.g. django, rails,etc) running behind a (nginx) proxy so nginx's number takes over apaches.

[weird-eye-issue]

You can serve dynamic content from nginx too. You don't need Apache in your stack at all.

[watermelon0]

You can proxy requests from nginx to backend application servers, but you cannot host those applications on the nginx.

Whereas with Apache2, PHP/Python/etc. interpreters can run directly in the Apache worker processes. Similarly, you can also run Nodejs/Ruby/Python web application as part of Apache with Passenger module.

[mort96]

Is it really an interesting distinction whether PHP is handled via dlopen of mod_php.so or via UNIX sockets to php-fpm?

[franga2000]

Yes - it matters a lot who is in control of the code execution. The traditional way was to run the code from or as a child process of the webserver process. FPM, WSGI, etc. move that into a completely separate and unrelated process. Crashes, hangs and security issues are a much smaller problem in the latter case.

[mort96]

So because FPM isn't running in-process, nginx "nginx is really just good at serving static content"...? That makes literally no sense to me.

[franga2000]

> Considering nginx is really just good at serving static content(maybe CDN uses it a lot) and the rest are all proxying

The English is a bit broken in the top-level comment, but both static content and proxying are clearly mentioned as "nginx things", which is entirely fair. If you don't consider proxying to be included under the term "serving" (which is entirely reasonable and not uncommon) this is entirely true - the only kind of "serving" nginx is good at is static files, the rest of what it's good at isn't "serving" but proxying to other servers that render dynamic content - PHP-FPM is one such server (it just happens to not speak standard HTTP).

I don't see why people always get mad when this gets brought up - I've always considered that to be a good architectural choice for nginx. Running application code in the webserver process isn't a good idea anymore so the focus on good static and proxy performance is actually what I think made it ultimately "win" over Apache - the industry has moved on from the old ways and Apache fell behind.

[hu3]

I wouldn't read too much into that.

nginx is good at serving dynamic content too. Simple setup with uwsgi for Python and php-fpm for PHP.

[franga2000]

I think both fpm and wsgi would fall under what OP called "proxying to application servers", despite using a different protocol. Yes it's technically "serving", but so is proxying and literally anything else a "server" does. Maybe "hosting" is a better term: both can serve any content, including dynamic, but apache can often host it as well (without an external server), which nginx can't do nearly as well.

[hu3]

No, I'm addressing this point where OP says nginx is only good at serving static content. See "really just good" here:

> Considering nginx is really just good at serving static content...

That's not correct at all. Regardless of how the request handled, serving dynamic content on nginx is trivial.

[franga2000]

What about the rest of that sentence? The way I read it (admittedly, the English is broken, so it isn't entirely clear what they meant) was that nginx is only good at "serving" static content, while the rest of what it does is proxying, not "serving". In that case, where a distinction is intentionally made between "serving" and "proxying", taking request for dynamic content and just shooting them off to an application server like uwsgi wouldn't be considered "serving".

Taking this logic to the extreme, socat is also very good at serving dynamic content:

  $ socat TCP-LISTEN:80,fork,reuseaddr TCP:127.0.0.1:8080 # Make sure Gunicorn is running on port 8080 to handle incoming requests