In this chapter
We'll learn the standard way web applications are cut into parts: client-server, three-tier architecture, and the presentation, business logic and data access layers — explained as a hotel — plus how frontend, backend and full-stack fit in.
The Problem in Real Life
John looks at Anna's one big box and asks her to look closer. "Inside that server, when a fan buys a ticket, which code talks to the fan, which code decides the rules, and which code talks to the database?"
She opens the code. Some files build pages and API responses. Some calculate prices and check holds. Some only run SQL. "They're already sort of separate," she says. "Exactly," says John. "Almost every app is cut this way. Let's name the pieces."
Every app has someone who talks to the guest, someone who decides, and someone who keeps the storeroom.
John
One Big Program vs. Layers With Separate Jobs
Different jobs, different code
Showing things, deciding rules and storing data are different jobs and change for different reasons.
Each layer talks to the next
A request passes down through the layers and the answer comes back up.
Jobs map to roles
Frontend, backend and full-stack developers are named after these layers (Act 01).
Client-Server, Tiers and Layers
Client-server (a quick recap from Act 11): the browser or app is the client that asks; BlueTicket's server is the server that answers. That's the outer shape. Now let's look at how the server side itself is organised.
The hotel analogy: in a good hotel, the receptionist at the front desk talks to guests — but doesn't decide room prices or carry luggage from the storeroom. The manager decides the rules: prices, upgrades, who gets which room. The storeroom keeper fetches and stores things, and nobody else walks into the storeroom. Each person has one job, and they pass requests down the line and answers back up.
- Presentation layer — the front desk: the part that talks to the user. It builds pages, shows buttons and forms, and turns API responses into what the fan sees. In BlueTicket: the web pages, the mobile app screens, and the code that formats API responses.
- Business logic layer — the manager: the part that decides. All the rules of the business live here: "5 or more tickets get 10% off" (Act 07), "hold a seat for ten minutes" (Act 08), "a sold seat can't be sold again." It doesn't care whether the request came from the website or the app, or how data is stored.
- Data access layer — the storeroom keeper: the part that talks to the database. It knows the tables and SQL (Act 13) and gives the business layer simple functions like
findSeat(id)orsaveBooking(...). The rest of the code never writes SQL directly. - Layers vs. tiers: layers are about how code is organised; tiers are about where things run. In a three-tier architecture, the three tiers usually run on different machines: the client tier (browser or app), the application tier (the app server, which holds the business logic and data access code), and the data tier (the database server). BlueTicket is three-tier: fans' browsers, the app server, and PostgreSQL.
| Layer | Hotel version | Job | BlueTicket example |
|---|---|---|---|
| Presentation | Front desk | Talks to the user | The checkout page, API responses |
| Business logic | The manager | Decides the rules | Discounts, seat holds, "sold is final" |
| Data access | Storeroom keeper | Reads and writes data | findSeat(), saveBooking() using SQL |
| Feature | Layers | Tiers |
|---|---|---|
| About | How code is organised | Where things run |
| Can share one machine? | Yes — usually do | Usually separate machines |
| Example | Presentation / business / data access | Client / app server / database server |
Three tiers, and the layers inside the app server
Client tier
browser or app — the guest
Presentation layer
pages, API responses — the front desk
Business logic layer
discounts, holds, rules — the manager
Data access layer
findSeat, saveBooking — the storeroom keeper
Data tier: PostgreSQL
the storeroom itself
Why separate them? Each layer changes for different reasons. Redesigning the checkout page shouldn't touch the discount rules. Moving from one database to another shouldn't touch the pages. With clear layers, each change stays in one place — and each layer can be tested on its own (Act 17).
Frontend, backend and full-stack (back to Act 01): the frontend is the presentation side that runs in the browser or app — HTML, CSS and JavaScript (Act 12). The backend is everything on the server: business logic, data access and the database. A full-stack developer works on both. A full-stack application is one complete app with all of these parts.
Anna redraws her one big box with three bands inside it — presentation, business logic, data access — and the database as a separate tier below. It's still one program on one server, but now she can see which part of it was overwhelmed on Friday. The answer surprises her: it wasn't the database. It was the server spending most of its time sending SMS messages, while fans waited.
Key Takeaway
Web apps are usually cut into three layers, like a hotel: presentation (the front desk — talks to the user), business logic (the manager — decides the rules) and data access (the storeroom keeper — talks to the database). Layers are how code is organised; tiers are where it runs — in a three-tier architecture: client, application server and database server. The frontend is the presentation side; the backend is everything on the server.
Why This Matters
Layers and tiers are the vocabulary of every architecture discussion, every job title (frontend, backend, full-stack) and every codebase you'll open (Act 25). Knowing which layer a problem lives in — and which tier is overloaded — is how Anna found that Friday's real bottleneck wasn't the database at all.
The server spent most of Friday sending SMS confirmations, one by one, while fans waited for their pages. That's a job that doesn't need to happen while the fan waits at all.