Why I finally switched over to NGINX after almost a decade of using Apache

Background

I'm as much a creature of habit as anyone else. It's been a long time since I first interacted with NGINX and noticed the improved performance it offers, and still decided to keep Apache.

The reasoning behind this decision was simple enough, the real performance gains I would perceive in my applications would be on initial startup of the HTTP server I chose. And my projects rarely ever require that I restart the HTTP server.

Specially when speaking about production environments where deployments would happen once or twice a month as development cycles where completed, it seemed an annoyance to migrate over to another HTTP server solution just so that running sudo service $HTTP_SERVER restart would run in a few milliseconds rather than a few seconds.

Moreover I was very used to using .htaccess files all throughout my projects, even more so if talking about Wordpress sites, and NGINX refuses to allow support of in-folder config files.

Now NGINX has a very good point in this regard. Allowing config files to sit within site folders really degrades startup performance by requiring recursive traversing of n-depth for each configured site. But I certainly loved my .htaccess files, even more so for site-migrations, just copy and paste the site folder and all your Apache specific configurations are right there.

At development level I mainly focused on Wordpress sites and Ruby on Rails apps for quite some time with the occasional Node.js app popping up here and there.

In all three instances NGINX offered no gain over Apache. I could just as easily edit files and reload the browser to see my changes reflected instantly thanks to PHP's interpreted nature, Rail's dynamic class instantiation, and by using either Gulp or Grunt to watch over html/css/js changes on Node apps.

Present

Recently I've shifted away from PHP and Rails and focused mainly on Node.js, specifically on React.js development.

My usual server setup both on development and production environments consisted on having Apache proxying requests from port 80 over to my Rails or Node apps on other ports such as 3000 or 8000.

And as I previously mentioned, not a problem... usually. Except that now-a-days with React and Babel taking so long to digest my changes, specially when using JSX, I get a very frustrating error with Apache which NGINX does away with completely.

503 Proxy Error

You see, Apache's proxy module periodically checks whether requests are reaching their final destination or not. If a request does not reach the intended app, a flag is raised and the dreaded 503 Proxy Error page pops up on the browser.

Usually I would get this page after restarting Rails and immediately trying to access the app on the browser. If the proxy module had detected that the Rails app was unavailable, I would have to wait around 60 seconds for it to check again.

No biggie, right? But when you need to restart your dev server every time you make a change to force scripts to be regenerated, and this happens at least 2 or 3 times a minute, having Apache go AWOL for 60 seconds at a time seriously impacts development efficiency.

Now, the time it takes for the proxy module to re-check if a site is alive is configurable. But the less config the merrier I am. I want things to work out of the box. And NGINX does just that.

Out of the box NGINX treats each request atomically, no flags raised, each verifies whether the proxy route will allow a packet to reach its destination. Just beautiful.

I migrated all my sites to NGINX a week ago. Other than having to chase down all .htaccess files I had scattered around and translating the configs to NGINX equivalents, the process was actually a lot less tedious than I expected, and took less than an hour to get it all done.

So far the experience has been great with NGINX, so even after the React Transform project reaches maturity and allows me to have true hot-loading for changes in my React.js dev environment, I plan to stick to using NGINX.

Show Comments