[shanemhansen]

Apache has historically been a giant swiss army knife that will do just about everything you could want, from redirect databases to cgi to php interpreters to crazy auth setups. It did all that while still being a reasonably good workhorse for static file serving (when properly turned and using the right worker model, event rather than threaded or process).

Nginx seems to have a different model. It does support a number of features but from what I can see it focuses on composing functionality with HTTP rather than adding more plugins.

Nginx seems to do a great job at being a load balancer and cdn-lite, and it seems like that's what the market wants out of a web server.

[rgacote]

nginx is turning into much more than just a load balancer. Projects such as OpenResty (a full CMS built into nginx) and Kong (an API management service), are built right into nginx using Lua. We've done some minor nginx Lua extensions and are looking to offload activities such as JSON validation into the front-end nginx.

http://openresty.org/ https://getkong.org

[awinder]

Unless I've missed something for a while, openresty is more a distribution for building apps / apis or complex middleware on top of nginx, not a full-blown CMS. It's a pre-built collection of useful extensions & lua modules, more of an "app platform"

[hdhzy]

By JSON validation do you mean just checking if it's well formed or rather something like JSON Schema validation?

The latter seems tricky. It's validation inside the application a bottleneck?

[rgacote]

Yes, json validation against schema. Bigger picture, in future we're looking to do some upstream proxy redirects based on payload. Figured the first step is short-circuiting anyone not sending us valid json. Plus, back ends are written in a variety of languages -- not all of whom do json schema validation nicely.

[joper90]

I assume they mean JWT validation.

[joper90]

Kong is great, really like it

[scurvy]

OpenResty is not a full CMS...

[astrange]

> It did all that while still being a reasonably good workhorse for static file serving (when properly turned and using the right worker model, event rather than threaded or process).

event doesn't support HTTPS, or rather, it stops being event-based when you turn on HTTPS. So Apache can never be performant unless you have an SSL terminating proxy.

Its only advantage is that the config script is slightly easier to test, but it's still way too hard _and_ it's incredibly verbose compared to nginx config.

[xorcist]

> event doesn't support HTTPS, or rather, it stops being event-based when you turn on HTTPS

Have you got any reference to this? I think I should have noticed, having run Apache with fairly bursty traffic.

The only reference in the documentation was a four year old one, which said it was problematic six years prior to that...

I find the Event MPM to be very stable under pressure and unless you have some really specific need it's the only sane way to run Apache. It should have been the default ages ago (in the limited sense Apache even has defaults).

[astrange]

Hmm, it seems like it works now in 2.4. That's a reason to keep Apache but I still can't see a reason to run anything new on it.

[xorcist]

2.4 is only five years old. 2.2 is more likely, if it was fixed ten years ago. In the few cases I have built Apache I usually don't bother with DSOs, and I usually run only the Event MPM.

The basis you pick your web server on shouldn't be whether it's "new" or "old". It is what your software runs on, what support contracts you have, and what functionality you need. But don't use it if you can't configure it. Preferrably your organization should have knowledge about every piece of software in production.

[SmellTheGlove]

I think you're correct, and Nginx does a nice job within that scope. I decided I wanted to learn it a bit, so I picked it for a project. I hadn't even stopped to think that I was reliant on WebDAV for editing that static content!

Long story short, I decided not to use any of the partial WebDAV implementations for Nginx and just use sshfs instead. It's so true that Apache is a swiss army knife, though.