9. Master the Basics, Break the Web: Server & Deployment Basics — Final
1. What Is a Web Server?
A web server is software that receives HTTP/HTTPS requests from clients and responds with web content like HTML, JSON, or files. It handles routing, static file delivery, connection management, and passes dynamic requests to backend applications. The two most common web servers are Nginx and Apache, each widely used in modern deployments.
Nginx
Nginx is a high-performance, event-driven web server known for speed and scalability. It excels at handling large numbers of concurrent connections, making it ideal for APIs, reverse proxies, and load balancing.
💡Example: Nginx often sits in front of an application: Client → Nginx → Backend (Node, Python, PHP)
Apache
Apache is a flexible, module-based web server that processes requests using a multi-threaded or process-based model. It offers extensive customization through modules like mod_php, mod_security, and supports .htaccess for per-directory rules.
💡Example: Apache can directly serve PHP applications using mod_php or act as a reverse proxy.
2. Static vs Dynamic Content
Web servers deliver two main types of content: static and dynamic, each serving different purposes in a web application. Understanding how they differ helps clarify how modern websites work and how backend logic is processed.
Static Content
Static content is fixed and does not change based on the user or request. These files are stored as-is on the server and delivered directly to the browser without backend processing. Examples include HTML, CSS, JavaScript files, images, fonts, and PDFs.
💡Example: /assets/logo.png → always returns the same image.
Dynamic Content
Dynamic content is generated on the fly by backend code in response to user interactions. The output changes based on inputs like user ID, roles, queries, or business logic. APIs, dashboards, search results, and personalized data all fall under dynamic content.
💡Example: /user/profile → returns different data for different users.
3. Reverse proxy basics
A reverse proxy is a server that sits between clients and backend servers.
Instead of clients talking directly to the application, all requests go through the reverse proxy first. It forwards the request to the correct backend, gets the response, and sends it back to the client — acting as a central traffic controller.
Why Reverse Proxies Are Used:
Load Balancing: Distributes incoming traffic across multiple backend servers to prevent overload.
Security Layer: Hides internal server IPs, filters requests, and blocks malicious traffic.
Caching: Stores frequently requested content to improve performance and reduce backend load.
SSL Termination: Handles HTTPS encryption/decryption, allowing backend servers to work with plain HTTP.
💡Example: A common setup:
Client → Nginx (Reverse Proxy) → Backend App (Node/Python/PHP)Nginx receives every request, decides where to send it, and returns the final response to the client.
4. Environment Variables & Config Files
Modern applications use environment variables and configuration files to store settings that change between environments — like development, staging, and production. These allow sensitive or environment-specific values (API keys, database credentials, secrets) to be separated from the main codebase. This separation improves security, scalability, and maintainability.
Environment Variables
Environment variables store sensitive or dynamic configurations outside the code. They are loaded by the application at runtime and typically stored in .env files or system-level configs.
💡Example:
DB_PASSWORD=secret123JWT_SECRET=mysecretkeyAPI_KEY=abcd1234
Why They Matter: They prevent secrets from being hardcoded directly into the source code.
Config Files
Configuration files define settings for different environments or services (database, logging, caching, email, etc.). They may be written in formats like .json, .yaml, .toml, .ini, or .php.
💡Example:
config.yamlfor server settingssettings.jsonfor app modesapp.config.jsfor frontend build settings
Why They Matter: Config files allow structured, reusable configurations that developers can update without modifying code logic.
Security Best Practices:
- Keep
.envand config files out of version control. - Never expose them publicly (common leak: misconfigured server serves
.env). - Use environment-specific configs:
dev,stage,prod. - Rotate keys and secrets stored inside these files.
The end.
Catch you soon 🙌,
Abinesh
