It still surprises me that NGINX beat out Apache so quickly even though Apache had way more modules and was/is entirely free vs. NGINX which is more or less "open core" with some nice features requiring commercial licensing.
I also expect ngx_lua did a lot for adoption, the fact that you could always "shell out" to lua if you needed was a huge boon even just for peace of mind.
If I have one gripe about NGINX it's that its configuration is a still-half-baked DSL that has quirks you wouldn't expect and when they error you don't get great feedback.
Examples: You can have an if clause, but no else attached. You can't have an if clause with multiple conditions. Finally, "if [might be] evil." 1
You end up writing a bunch of partitioned control flow statements and you're never really sure at what level of config hierarchy they would best be applied.
I love the product but Apache's XML versus NGINX's semi-declarative, hierarchical blocks aren't night and day better.
1 https://www.nginx.com/resources/wiki/start/topics/depth/ifis...
I've seen these manifest in the wild as stuff like:
if ($thing ~* (match)) { $setWeirdVar = "Y"; } if ($otherThing = "value") { set $setValue "${setWeirdVar}E"; } if ($thirdCondition ~ (another|match)) { set $setValue "${setWeirdVar}S"; } if ($setValue = YES) { # do a thing here }
As clunky as that is, I've found it recommended in SO threads.
My dream web server has Nginx's capabilities and Lighttpd's Lua configuration files/scripts. Is that what ngx_lua does? I've heard of it before but never really gave it a look.
I would prefer a simple JSON file any day. Or some Lispy S-expressions. Or some TOML or well structured XML and XSD even.
NGINX makes you learn another lang only for one tool and for a config, which mostly (always?) does not need anything more than being declarative config.
<Perl>
# dynamic perl config goes here..
</Perl>(Unless you don't mean Apache webserver but rather some other Apache product)
Yes, this is what I meant. I originally wrote a SaaS app that was hosted through Apache and ended up putting NGINX on top of it for the aforementioned reasons. But eventually testing showed that removing Apache just made the whole thing a whole lot more manageable. I have friends with similar anecdotes. Just putting NGINX in front from the get-go would have saved a lot of tech debt.
However, for better or worse, a lot of the software people want to run on shared hosting come with a .htaccess file and documentation for how to configure it otherwise. So we gave customers a choice to put Apache behind nginx.
Unfortunately I left too early to learn what %age of customers ended up enabling Apache but they‘re still running this architecture today.
The exact same argument can be made to explain why nginx is undercounted. A lot of setups will run nginx behind proxies, so you'll count a proxy: a Varnish, a single nginx, cloudfront servers (are they running nginx?) while in reality there may be many nginx-es running.
Nonetheless: nginx is a gift and thanks go out to Igor, regardless of how good the spiders can count the number nginx instances.
In my case we scaled Drupal and Wordpress sites by using Varnish as a reverse proxy cache in front of Apache. But then we wanted to go HTTPS across the board, which Varnish does not handle. So we terminated HTTPS in Nginx and then passed the connection back to the existing Varnish/Apache stack. I know other folks just skipped or ripped out the Varnish layer and used Nginx for both HTTPS and caching.
At the time both Drupal and Wordpress (and other popular PHP projects) depended on Apache-specific features for things like pretty URLs and even security. Over time, the community engineered away from those so there was little reason to prefer Apache anymore.
Then everyone moved to ruby and python (and also perl) and mod_php stopped being an advantage.
Also the Apache that was beaten was Apache 1, which was fork-only, and that was the whole reason Nginx was written in the first place.
Then Apache did Apache2 with mpm modules and badly missed the mark. After that Apache was doomed. No async support == dead. It was that simple.
And post-FCGI's adoption, you didn't need to use Apache, so... why use it?
I've always felt like Nginx "just works" by default and creating configurations is relatively easy.
I used lighttpd for this, mentioned in another thread, rather than nginx, which was a similar breath of fresh air coming from Apache -- not only for the event loop model built around epoll and friends, but also the configuration and general deployment.
The syntax to configure is clear enough while not being super verbose…
This is why email is now more or less the domain of a couple of very large companies.