1. The Simple Definition
Think of a backend as a computer that never sleeps. Its only job is to listen. It waits for requests coming from outside — these can be HTTP requests, WebSocket connections, gRPC calls, or other protocols.
This computer listens through open ports, like port 80 or port 443. A port is like a door. If the door is closed, nobody can knock. If it's open, clients (browsers, mobile apps, other servers) can connect and send or receive data.
We call this computer a server because it serves content:
- Static files (images, JavaScript, HTML)
- Data (usually as JSON)
- It can also receive data from the client (like a form submission)
This definition is correct, but it's only half the picture. To really understand a backend, we need to follow a request step by step, from the moment it leaves your browser to the moment it reaches the server.
2. The Journey of a Request
Let's say you open backend-demo.senus.xyz in your browser. Here is exactly what happens:
Step 1 — DNS: The Phone Book of the Internet
Your browser doesn't understand domain names like senus.xyz. It only understands IP addresses. So the browser asks a DNS server: "What is the IP address for this domain?"
DNS works like a phone book — you give it a name, it gives you a number. There are different types of DNS records:
- A Record → points a domain directly to an IP address
- CNAME Record → points a domain to another domain (an alias)
In our example, the subdomain backend-demo has an A record pointing to one specific IP address.
Step 2 — Reaching the Server (and the Firewall)
That IP address belongs to a real machine — in this case, an AWS EC2 instance. But the request doesn't reach the server directly. First, it must pass through a firewall, called a Security Group on AWS.
The Security Group decides which ports are allowed to receive traffic from the internet. A typical setup allows:
| Port | Purpose |
|---|---|
| Custom port (e.g. 22) | SSH access for developers to manage the server |
| 443 | HTTPS traffic (secure) |
| 80 | HTTP traffic (not secure) |
Important: if port 80 and 443 are not open, AWS blocks the request immediately. It never even reaches your server code.
3. Inside the Server: Reverse Proxy + Node Server
Once the request passes the firewall, it enters the EC2 machine. But it doesn't hit your Node.js code directly. First, it meets a reverse proxy.
What is a reverse proxy?
A reverse proxy is a server that sits in front of your real application servers. Its job is to manage redirects and configuration from one central place, instead of configuring every service separately.
In this example, the tool used is Nginx. A simplified Nginx config looks like this:
server {
listen 80;
server_name backend-demo.senus.xyz;
return 301 https://$host$request_uri; # redirect HTTP -> HTTPS
}
server {
listen 443 ssl;
server_name backend-demo.senus.xyz;
# SSL certificate handled automatically by certbot
location / {
proxy_pass http://localhost:3001; # forward to the real Node server
}
}
Nginx does two important things here:
- Redirects any HTTP (port 80) traffic to HTTPS (port 443) for security
- Forwards (
proxy_pass) all matching requests tolocalhost:3001, where the actual Node.js app is running
Who is running on port 3001?
That's your real backend code. On the server, a process manager called pm2 keeps it alive 24/7 (so if it crashes, it restarts automatically). Running pm2 list on the EC2 instance might show two processes: one for the frontend, one for the backend.
You can even test this from inside the server itself:
curl localhost:3001/users
This returns the exact same response the browser gets — because it is the same server, just accessed locally instead of through the internet. This is the same idea as running localhost:3000 on your own laptop while learning — just now it happens inside a cloud machine.
4. Why Do We Even Need a Backend?
Let's use a real example: Instagram likes.
You scroll your feed, see your friend's photo, and tap the like button. A second later, your friend gets a notification on their phone.
What actually happened in between?
Step by step:
- Your app sends a request to the server
- The server parses the request and figures out who you are
- The server persists (permanently saves) this action in a database
- The server finds the post owner and triggers a notification to their phone
Why can't your phone talk to your friend's phone directly?
Because your app only knows your data — your feed, your settings, your session. Your friend's app only knows their data. Neither app has the full picture.
We need one centralized computer that holds information about everyone, so it can connect people together (likes, comments, notifications, messages...).
If you had to describe a backend's job in one word, it would be:
Data. Fetching data, receiving data, persisting data, and handling any action related to data.
5. What Actually Happens on the Frontend?
Good question: if the backend does all this heavy lifting, why not just do everything in the frontend and skip the extra hop?
To answer that, let's look at what happens when your browser loads a frontend app (say, built with Next.js).
- The browser first fetches the HTML file
- Then it fetches everything else it needs: CSS, JavaScript, images, fonts — each as a separate request
- Once CSS arrives, the browser paints the page (colors, layout, fonts — the visual look)
- Once JavaScript arrives, the browser hydrates the page — this means it attaches event listeners so buttons actually respond when clicked
The key difference
| Frontend | Backend | |
|---|---|---|
| Where code runs | On the user's device (their browser is the runtime) | On the server |
| What is sent | The actual code (JS, CSS, HTML) | Only the result (e.g. JSON data) |
The frontend ships you the code and your browser executes it. The backend executes the code itself and only ships you the answer.
6. Why Can't We Just Put Backend Logic in the Frontend?
Since frontend code runs on a computer (the user's device), why not just connect the frontend directly to the database and skip the backend? There are four major reasons why this is impossible and dangerous:
1. Security & Sandbox Environments
Browsers run JavaScript in a Sandbox. This is a strict security measure that isolates the browser from the user's Operating System. If browsers weren't sandboxed, any malicious website you visit could execute a script to read your local hard drive, steal personal files, and send them to a hacker. Because of the sandbox, frontend code cannot access the local file system, read environment variables, or manage low-level OS processes—things a backend requires to function.
2. CORS (Cross-Origin Resource Sharing)
Browsers enforce a strict security policy called CORS. It prevents JavaScript running on Domain A from making API requests to Domain B unless Domain B explicitly allows it via specific HTTP headers. A backend needs to freely communicate with dozens of external APIs (payment gateways, email services, third-party data). The browser's CORS policy would block most of these communications.
3. Databases and Connection Pools
To talk to a database (like PostgreSQL or MongoDB), you need Native Database Drivers. These drivers maintain persistent socket connections and read binary data—things browsers cannot do.
- The Connection Pool: A backend server maintains a "pool" of open, reusable connections to the database. If 10,000 users visit your site, the backend handles them using a pool of maybe 50 database connections.
- The Disaster Scenario: If you connected the frontend directly to the database, all 10,000 users would open 10,000 direct, simultaneous connections. The database would immediately run out of memory and crash.
4. Computing Power (Scalability)
Frontend code runs on the user's hardware. Your users might be on a high-end gaming PC, or they might be on a 7-year-old budget smartphone with 2GB of RAM. You cannot run heavy business logic, data processing, or encryption on the client side without causing severe lag or crashing their browser. A backend server runs in a controlled cloud environment where you can easily scale up CPU and RAM to handle heavy computational loads.
7. Putting It All Together
A backend, in short, is not just "a computer that listens." It's a whole chain: DNS resolves a name to an address, a firewall guards the door, a reverse proxy routes traffic internally, and finally your actual application code runs — safely, centrally, and with full access to databases and other services that a browser could never have.
Summary & Interview Prep
If you are preparing for an exam or a technical interview, make sure you can confidently answer these core questions derived from the backend lifecycle:
Q: What is the traditional definition of a server, and why is it called that?
A: A server is a computer continuously listening on open ports for incoming network requests. It is called a "server" because it serves content (files, data, HTML) to clients.Q: What is the difference between an A Record and a CNAME Record in DNS?
A: An A Record maps a domain name directly to an IPv4 address. A CNAME maps a domain name to another domain name.Q: What happens if you don't open Port 80 or 443 in your AWS Security Group?
A: The AWS firewall will immediately drop/block incoming web traffic, and the request will never reach your EC2 instance.Q: What is a Reverse Proxy and why do we use Nginx?
A: A reverse proxy sits in front of backend servers to route traffic, handle SSL/TLS termination, and manage redirects centrally, shielding the internal application servers from direct internet exposure.Q: Why can't a mobile app send a notification directly to another user's phone without a backend?
A: Apps are customized for individual users and do not hold the global state of the application. A centralized backend is required to persist data, map user relationships, and trigger cross-device notifications.Q: What does "Hydration" mean in frontend development?
A: Hydration is the process where the browser downloads JavaScript and attaches event listeners to static server-rendered HTML, making the page fully interactive.Q: Why is a Connection Pool necessary in backend architecture?
A: Opening and closing database connections for every single user request is computationally expensive and would crash the database under heavy load. A connection pool maintains a set of reusable, persistent connections to efficiently handle thousands of concurrent requests.Q: Why do browsers use a Sandbox environment?
A: To protect the user. It isolates web scripts from the local operating system, preventing malicious websites from accessing the file system or sensitive local data.
Top comments (0)