Blog

Backend Finally Started Making Sense

Yesterday I focused on DSA and mock interviews.

Today I spent almost the entire day understanding what actually happens when we type a URL into a browser.

I always knew terms like DNS, HTTP, Nginx, CORS, Headers, and Routing, but today they finally connected together.

The Journey of a Request

One thing that completely changed how I think about backend was understanding the complete request flow.

Browser
   ↓
DNS → finds server IP
   ↓
Firewall → checks if traffic is allowed
   ↓
EC2 Instance
   ↓
Nginx
   ↓
FastAPI running on localhost

Before today these felt like separate buzzwords.

Now they feel like one pipeline.

HTTP Isn’t Just “Requests and Responses”

Some interesting things I learned:

• HTTP is stateless, even though it usually relies on TCP.
• HTTP/3 uses QUIC over UDP to avoid Head-of-Line blocking.
• HTTP methods simply represent different intentions.

For example:

• GET → Fetch data
• POST → Create data
• PATCH → Update existing data
• PUT → Replace existing data
• DELETE → Remove data
• QUERY -> a newcomer in the list

I also finally understood idempotency, a concept that’s commonly asked in interviews.

CORS Finally Clicked

This was probably my biggest takeaway.

I always thought CORS was something backend frameworks randomly required.

Turns out…

The browser is the one enforcing it.

If my frontend is hosted on GitHub Pages and my backend lives somewhere else, the browser refuses to expose the response unless my backend explicitly says:

“Yes, I trust this origin.”

That one concept made CORS make much more sense.

Other Things I Explored

Along the way, I also learned about:

• HTTP response codes and what they actually mean
• Caching using ETags
• Compression with gzip and Brotli
• Serialization & deserialization using Pydantic
• Routing and API versioning
• Content negotiation
• Why SSL was replaced by TLS
• Why Nginx is commonly placed in front of backend services

One Thing That Surprised Me

I also learned why mobile apps don’t need CORS.

Browsers execute code from thousands of different websites inside the same application, so they need strict rules like the Same-Origin Policy and CORS to prevent one website from stealing another website’s data.

Mobile apps are different.

Each app runs inside its own isolated sandbox and doesn’t automatically share authentication cookies or sessions with other apps. Because of this isolation, the browser-specific security problem that CORS solves simply doesn’t exist for native mobile applications.

I had never thought about it this way before, and it made CORS make even more sense.

Today’s Biggest Realization

Backend isn’t just writing API endpoints.

It’s understanding how data actually travels from a user’s browser to your application and back again.

Once that pipeline becomes clear, every technology—FastAPI, Nginx, Docker, AWS, DNS, HTTP—starts fitting together naturally.

Tomorrow I’ll continue exploring backend fundamentals before diving deeper into FastAPI.

Applying It to a Real Project

Learning something is one thing, but using it immediately makes it stick.

After understanding CORS and why browsers enforce it, I went back and updated my Noodle backend built with FastAPI.

I realized that even though one of my endpoints uses WebSockets, I should still explicitly allow only the trusted frontend origin instead of accepting connections from anywhere. Since my mobile app isn’t a browser, it doesn’t need this origin restriction, but my web client does.

This small change helped reduce the attack surface of my backend against browser-based attacks such as Cross-Site WebSocket Hijacking (CSWSH), where a malicious website could otherwise attempt to establish a WebSocket connection to my server using a victim’s browser and authenticated session. Restricting trusted origins makes these attacks significantly harder.

Today’s learning wasn’t just theory—I immediately used it to make one of my own projects more secure.

Checkout Noodle: https://maitry4.github.io/Noodle/