Web Server

Explanation

Web servers come in two forms: static file servers (serve HTML, CSS, JavaScript, images directly from disk without executing code — nginx and Apache in static mode) and application servers (execute code to generate dynamic responses — a Node.js/Express app, a Django app, a Rails app). In production, these are often layered: nginx sits in front as a reverse proxy, serving static files directly and forwarding dynamic requests to the application server. The core request lifecycle: a DNS lookup resolves the domain to an IP address, a TCP connection is established (TLS handshake for HTTPS), the client sends an HTTP request, the server processes it (routing, authentication, database queries, rendering), and sends an HTTP response. nginx can handle thousands of concurrent connections efficiently by using an event-driven, non-blocking I/O model (similar to Node.js's event loop). nginx's common roles in production: reverse proxy (forward requests to an application server while hiding its internal address), load balancer (distribute requests across multiple application server instances), static file server (serve files from disk with maximum efficiency), SSL termination (decrypt HTTPS and forward plain HTTP to the application server), caching (serve cached responses for frequently-requested content), and compression (gzip responses before sending). The distinction between web server and application server is blurring: Next.js in standalone mode is both; Node.js/Express is both. But understanding the traditional layered architecture (nginx → application server → database) explains why production deployments look the way they do and how nginx configuration affects your application's behavior.

Code Example

# nginx configuration: reverse proxy to Node.js app

# /etc/nginx/sites-enabled/myapp
server {
    listen 80;
    server_name myapp.com www.myapp.com;
    return 301 https://$host$request_uri;  # redirect HTTP to HTTPS
}

server {
    listen 443 ssl http2;
    server_name myapp.com www.myapp.com;

    ssl_certificate     /etc/letsencrypt/live/myapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.com/privkey.pem;

    # Serve static files directly (no app server involved)
    location /static/ {
        root /var/www/myapp;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # Forward dynamic requests to Node.js app on port 3000
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Why It Matters for Engineers

Understanding web server configuration is essential for production deployments. nginx configuration errors cause 502 Bad Gateway errors, broken HTTPS, security misconfigurations, and performance issues. Knowing that nginx is a reverse proxy (not your application) explains why req.ip in Express shows 127.0.0.1 unless you configure X-Forwarded-For header trust. The reverse proxy pattern is also fundamental to microservices architecture: an API gateway is a sophisticated reverse proxy that routes requests to different services, handles authentication, and aggregates responses. Understanding basic web server operation provides the mental model for these more complex patterns.