nonobie — Real dev skills, explained like a friend would

What you'll learn

By the end of this chapter you will:

Explain what a backend is in plain English — to a non-developer
Name the three layers every backend has and what each one does
Trace a real HTTP request from browser to database and back
Understand why NestJS exists instead of plain Express

The why

💡The QuickBite analogy

You open QuickBite (think Zomato or Swiggy), browse restaurants, pick a Margherita pizza, and tap Place Order. Instantly your screen shows "Order placed! 🎉 Arriving in 30 min."

That screen — the buttons, the pizza image, the countdown timer — is the frontend. It's what you see and touch.

But who actually saved your order? Who charged your card? Who notified the restaurant? Who will track the delivery? That's the backend.

The frontend is the menu board and cashier at a restaurant.
The backend is the kitchen, the billing system, the inventory, and the delivery coordinator — all hidden behind the counter.

Nobody sees the kitchen. But without it, you get zero pizza. 🍕

Throughout this entire guide we'll build QuickBite — a food delivery . Every concept you learn will be applied directly to it.

The three layers every backend has

No matter what technology you use — NestJS, Django, Rails, Spring — every backend has exactly three layers. You will hear these terms constantly, so learn them now.

Layer 1 — Edge (the gatekeeper)

You usually don't write this layer yourself. It's handled by an API gateway, a , or like Helmet.

Layer 2 — App (what you write every day)

This is where your NestJS code lives. It receives a request, figures out what to do, talks to the database, and sends a response back:

Layer 3 — Data (where state lives)

Your app is stateless — it doesn't remember anything between requests. All is stored here:

The golden rule — state goes down, code goes up

The golden rule

State goes DOWN (into the database). Code goes UP (into the app). Never the other way around.

❌ Wrong: Write business logic in the database (stored procedures, triggers with business rules)
❌ Wrong: Store state in the app (in-memory variables that pods don't share)
✅ Right: Business logic in the service layer. State in PostgreSQL or Redis.

What happens when a user taps "Place Order" on QuickBite

Let's trace exactly what happens — step by step — when a user submits an order:

Why do we use NestJS instead of plain Express?

💡Bricks vs a blueprint

You might have heard of Express — the most popular Node.js framework. NestJS is built on top of Express, and adds structure that Express doesn't have.

Express gives you bricks and mortar. You decide how to arrange them.
NestJS gives you a blueprint, pre-built rooms, and enforces that the kitchen is not in the bedroom.

Without structure, a large Express codebase turns into chaos — controllers call models directly, services call controllers, everything imports everything. NestJS forces a clean architecture by design.

Common mistakes

One thing to remember

Mistake	Why it's wrong	What to do instead
Writing business logic in the database	Code splits between and — impossible to test	Business logic in services
Storing state in app memory	Other pods don't see it; restarts wipe it	Use PostgreSQL or Redis
Putting HTTP logic in a service	Service becomes tightly coupled to HTTP	Services know nothing about HTTP

A backend is: receive request → validate → apply business rules → read/write data → return response. Your job is to write the business rules layer. Everything else is plumbing.

Chapter 1 — What is a Backend?