Most developers learn backend development backwards.
They start with frameworks like Express.js, Next.js, or Django and only later realize they never actually understood what was happening underneath.
That’s why so many developers can build features but struggle to debug authentication issues, CORS problems, cookies, caching, or weird API behavior.
Everything on the web comes down to one thing:
A client sends a request.
A server sends a response.
That’s the entire internet.
But the details inside that cycle are what separate beginners from engineers who deeply understand systems.
The Request/Response Cycle
Imagine you type:
google.com
into your browser and hit Enter.
What happens next?
A lot more than most people think.
Step 1 — DNS Resolution
Your browser does not know where google.com lives.
It asks a DNS server:
“What IP address belongs to google.com?”
DNS responds with something like:
142.250.184.46
DNS is basically the internet’s phonebook.
Humans remember names.
Computers communicate with IP addresses.
Without DNS, we would all be typing raw IP addresses into browsers.
Step 2 — TCP Handshake
Before HTTP even begins, the browser and server establish a connection.
This happens using a TCP three-way handshake:
Client → SYN
Server → SYN-ACK
Client → ACK
This basically means:
“I want to connect.”
“Okay, I’m ready.”
“Great, let’s communicate.”
This setup takes time.
That’s why the first request to a server is slower than later requests.
Step 3 — TLS Handshake (HTTPS)
If the site uses HTTPS — which most modern websites do — another handshake happens.
Now the browser and server negotiate:
encryption algorithms
security certificates
encryption keys
This is what keeps your passwords, messages, and payment information secure while traveling across the internet.
Without HTTPS, anyone on the network could potentially read your traffic.
Step 4 — The HTTP Request
Now the browser finally sends the actual request.
A real request literally looks like this:
GET / HTTP/1.1
Host: google.com
Accept: text/html
User-Agent: Mozilla/5.0
That’s it.
Plain text.
HTTP is just structured text sent over a network connection.
Step 5 — The Server Processes the Request
The server receives the request and decides what to do.
Maybe it:
queries a database
authenticates a user
processes business logic
generates HTML
fetches cached data
talks to another API
Then it prepares a response.
Step 6 — The Response Comes Back
A response looks like this:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 48523
<!DOCTYPE html>
...
A response contains:
Status line
Headers
Blank line
Body
Every API response you’ve ever worked with follows this pattern.
Step 7 — The Browser Fires More Requests
The HTML might reference:
CSS files
JavaScript bundles
fonts
images
videos
Each one triggers additional requests.
A single page load can easily generate 50–100 requests.
This is why:
caching matters
CDNs matter
bundling matters
HTTP/2 matters
performance optimization matters
Every request has overhead.
HTTP Methods Explained Properly
Methods are the verbs of HTTP.
The URL is the noun.
Together they form a sentence.
GET
Retrieves data.
GET /users/42
Rules:
should not change server state
should be safe
should be idempotent
Calling it 10 times should behave the same as calling it once.
GET requests are aggressively cached by browsers.
POST
Creates data or triggers an action.
POST /users
POST requests usually contain a body:
{
"name": "Jeffrey"
}
POST is not idempotent.
Submitting the same form twice may create two records or send two emails.
PUT
Full replacement update.
If a resource has 10 fields and you PUT it, you send all 10.
Missing fields may get erased.
PATCH
Partial update.
Only send the fields that changed.
Most modern APIs prefer PATCH over PUT.
DELETE
Deletes a resource.
DELETE /users/42
Usually idempotent.
Deleting something twice should not crash the server.
HEAD
Like GET, but returns headers only.
Useful for:
checking file existence
checking last modified dates
validating caches
without downloading the body.
OPTIONS
Asks:
“What methods are allowed here?”
Browsers use this heavily during CORS preflight requests.
Status Codes — What They Actually Mean
2xx — Success
200 OK
Standard success.
201 Created
Something new was created.
Usually returned after POST.
204 No Content
Success with no response body.
Very common for DELETE operations.
3xx — Redirects
301 Moved Permanently
Permanent redirect.
Search engines update their records.
302 Found
Temporary redirect.
304 Not Modified
Used for caching.
Server tells the browser:
“Use your cached version.”
No response body needed.
4xx — Client Errors
400 Bad Request
Malformed request.
401 Unauthorized
Actually means unauthenticated.
“I don’t know who you are.”
403 Forbidden
Authenticated but not allowed.
“I know who you are, but you can’t do this.”
404 Not Found
Resource does not exist.
409 Conflict
Conflicts with current state.
Example:
duplicate email during signup
422 Unprocessable Entity
Valid syntax, invalid data.
429 Too Many Requests
Rate limiting.
5xx — Server Errors
500 Internal Server Error
Generic server crash.
502 Bad Gateway
Proxy received an invalid response upstream.
503 Service Unavailable
Server overloaded or under maintenance.
504 Gateway Timeout
Upstream server took too long to respond.
The Most Important Debugging Skill
Remember this rule:
4xx = fix the request
5xx = fix the server
That mental model alone saves developers hours.
Headers — The Hidden Metadata
Headers are key-value pairs.
They carry metadata about requests and responses.
Important Request Headers
Authorization
Used for authentication.
Two common formats:
Authorization: Basic base64(username:password)
and
Authorization: Bearer
Bearer tokens are heavily used in modern APIs.
Content-Type
Tells the server how to parse the body.
Examples:
application/json
multipart/form-data
application/x-www-form-urlencoded
If this header is wrong, your backend may fail to parse incoming data.
Cookie
Sends stored cookies to the server.
This powers traditional session authentication.
Important Response Headers
Set-Cookie
Tells the browser to store a cookie.
Cache-Control
Controls caching behavior.
Examples:
no-store
max-age=3600
public
private
Caching is one of the biggest performance optimizations on the web.
Access-Control-Allow-Origin
The famous CORS header.
Without it, browsers block cross-origin responses.
CORS — Why Every Developer Eventually Suffers
CORS confuses almost everyone initially.
Here’s the core idea:
Browsers enforce a Same-Origin Policy.
JavaScript running on:
cannot freely read responses from:
```api.otherdomain.com```
without permission.
Why?
Security.
Otherwise malicious websites could silently read sensitive data from sites where you’re logged in.
**How CORS Works**
When your frontend calls another origin, the browser may first send:
OPTIONS /api/users
This is called a preflight request.
The server must respond with headers like:
Access-Control-Allow-Origin: https://velto.io
Access-Control-Allow-Methods: GET, POST, PATCH
Access-Control-Allow-Headers: Authorization, Content-Type
If those headers are missing:
the request may still succeed
the server may still respond
but the browser blocks JavaScript from reading the response
That’s why CORS errors feel confusing.
It’s not usually the backend failing.
It’s the browser enforcing security rules.
**Authentication — The Real Problem It Solves**
HTTP is stateless.
The server forgets you after every request.
Authentication solves that memory problem.
There are three major approaches:
Sessions
JWT
OAuth
**Sessions — The Traditional Approach**
Sessions work like coat-check tickets.
You log in once.
The server creates a session record:
session_id → user_id
Then the server gives your browser a cookie:
Set-Cookie: sessionId=abc123
Your browser automatically sends it back later:
Cookie: sessionId=abc123
The server checks its session store and identifies you.
Why Sessions Are Still Great
Advantages:
instant logout
easy invalidation
simple security model
works naturally with browsers
Disadvantages:
server must store session state
scaling requires shared storage like Redis
But honestly?
For many applications, sessions are still the best option.
**JWT — JSON Web Tokens**
JWTs use a different philosophy.
Instead of storing session state on the server, the client carries signed identity data.
A JWT contains payload data like:
{
"sub": "42",
"role": "admin",
"exp": 1716716400
}
The server signs it cryptographically.
Clients send it like:
Authorization: Bearer <token>
The server verifies the signature and trusts the contents.
No database lookup required.
The Big JWT Tradeoff
JWTs are stateless.
That’s their strength.
And their weakness.
If a JWT gets stolen, it stays valid until expiration.
You cannot instantly invalidate it unless you maintain some server-side blacklist.
This is why modern systems use:
short-lived access tokens
long-lived refresh tokens
Where Should JWTs Be Stored?
localStorage
Easy.
But vulnerable to XSS attacks.
httpOnly Cookies
Much safer.
JavaScript cannot read them.
Preferred for many web apps.
Memory
Most secure.
But disappears on refresh.
**Sessions vs JWT**
Use sessions when:
building traditional web apps
you need instant logout
security matters heavily
Use JWT when:
multiple services need auth
mobile apps consume your API
microservices need shared identity verification
Most applications do not need ultra-complex auth architecture.
Simplicity is often more secure.
**OAuth — “Login with Google”**
OAuth lets third parties authenticate users without sharing passwords.
When users click:
“Continue with Google”
your app never sees their Google password.
Google handles authentication.
Your app only receives trusted identity information.
Simplified OAuth Flow
User clicks login with Google
Redirect to Google
User logs in
Google asks permission
Google redirects back with a code
Your server exchanges the code for tokens
Your app logs the user in
The critical detail:
The token exchange happens server-to-server.
Not directly in the browser.
That prevents token leakage.
Password Storage — Never Store Plain Passwords
Passwords should always be hashed.
Use:
bcrypt
Argon2
scrypt
These are intentionally slow algorithms designed to resist brute-force attacks.
Never store raw passwords.
Ever.
The Full Modern Auth Flow
A modern app usually looks like this:
Registration
hash password
store user
issue session/token
Login
verify credentials
issue authentication
Authenticated Requests
client sends token/cookie
server validates identity
Token Refresh
expired access token replaced using refresh token
Logout
destroy session or invalidate refresh token
Password Reset
issue single-use time-limited reset token
email user
invalidate token after use
Final Thought
Frameworks change constantly.
Protocols last decades.
If you deeply understand:
HTTP
request/response cycles
headers
status codes
cookies
sessions
JWT
OAuth
CORS
then every backend framework becomes dramatically easier to learn.
Because underneath all the abstractions, the internet is still just:
A client sending text to a server.
A server sending text back.
Everything else is layers on top of that foundation.