Almost every production web stack has NGINX or something like it in front; knowing its role tells you what to configure there.
NGINX (pronounced "engine x") is an HTTP server and proxy. In practice it plays four roles, often at once:
- Web server: serves static files (HTML, JavaScript, images) straight from disk, very efficiently.
- Reverse proxy: accepts client requests and forwards them to application servers such as Node.js, Gunicorn or a Java service, then relays the responses. Clients only ever talk to NGINX.
- Load balancer: spreads requests across several application instances and stops sending traffic to failed ones.
- TLS terminator and cache: handles HTTPS so applications don't have to, and caches responses to reduce load.
Its architecture is what made it popular: a small number of worker processes, each running an event loop that handles thousands of connections without a thread per connection. Slow clients and idle keep-alive connections cost little memory, so NGINX shields application servers from them.
There are two main editions: open-source NGINX from nginx.org (with stable and mainline branches) and the commercial NGINX Plus with extra features like an API and active health checks. Most distributions and the official Docker image ship open-source NGINX. Everything in this course uses open-source NGINX configuration.
Example
# One NGINX in front of everything
# client --HTTPS--> NGINX :443
# |-- / -> static files in /var/www/site
# |-- /api/ -> app servers 10.0.0.11:8000, 10.0.0.12:8000
# `-- /ws/ -> websocket service :9000
curl -sI https://example.com | grep -i '^server'
# server: nginxRemember
- NGINX serves files, proxies, load balances and terminates TLS
- A few event-loop workers handle many thousands of connections
- Applications sit behind it and never face clients directly