The one-sentence version
The frontend is the part of an app running on your device that you see and touch; the backend is the part running on the company's servers that holds the data and enforces the rules.
Nearly every app you use — Instagram, Gmail, Swiggy, your bank — is these two programs in constant conversation.
The restaurant analogy
This is the analogy the whole industry uses, because it maps perfectly:
| Restaurant | App | Technical term |
|---|---|---|
| Dining room, menu, waiter | What the user sees & interacts with | Frontend (client) |
| Kitchen | Where the real work happens, hidden | Backend (server) |
| Order slip passed to the kitchen | Structured request for data/action | API request |
| The dish that comes back | The response data | API response |
| Pantry & inventory | Stored information | Database |
You never enter the kitchen. You order through a fixed, agreed-upon menu — and that menu is the API (next page).
What the frontend does
The frontend (also called the client) runs on the user's device — in a browser as HTML/CSS/JavaScript (the previous page), or as a mobile app installed from the store. Its jobs:
- Display — turn data into pixels: the feed, the buttons, the charts
- Interact — react instantly to taps, scrolls and typing
- Validate politely — "that doesn't look like an email address" before bothering the server
- Request — ask the backend for data and send the user's actions to it
The defining property: the frontend runs on hardware you don't control, in front of eyes you can't verify. Anyone can open dev tools and read or modify the frontend code they received.
What the backend does
The backend runs on servers — computers in a data center owned (or rented — see the cloud) by the company. Users never see this code. Its jobs:
- Store and fetch data — usually via a database
- Enforce the rules — this is the big one. "You can only see your own messages." "You can't withdraw more than your balance." "This coupon is single-use."
- Authenticate — verify who is asking (passwords, sessions, tokens)
- Coordinate — talk to other services: payments, email, maps, AI models
Because users control the frontend, every security rule must be enforced on the backend. Frontend checks are a courtesy for honest users; a malicious user can bypass all of them and talk to your server directly. "Validate on the server" is possibly the single most important sentence in this entire roadmap — interviews at every level probe whether you understand it.
How they talk: the request/response loop
Walk through a single Instagram like:
- You tap the heart. The frontend fills it in immediately (so the app feels fast) and sends a request to the backend.
- The backend checks you're logged in and allowed to see that post, then writes the like to the database.
- It responds "saved, new count is 1,042," and the frontend settles on the real number.
Every action in every app is some version of this loop, usually completing in under half a second.
Where the boundary sits (and why it moves)
Could the frontend just do everything? No — and seeing why cements the concepts:
- Data must be shared between users → it has to live somewhere all users can reach: a server.
- Rules must be trusted → they must run where users can't tamper: a server.
- Secrets (payment keys, other users' data) must stay secret → server.
But anything that's instant feedback on your own screen belongs on the frontend: animations, input validation hints, a half-typed draft. Deciding what goes on which side is a daily engineering judgment call, and a classic interview discussion at Level 7–8.
Industry perspective
- Job titles map directly: frontend engineer (Level 8), backend engineer (Level 7), full-stack engineer (both). At FAANG scale, teams often split even further (mobile, web, API, infrastructure).
- Real products have many backends: Netflix runs hundreds of small backend services (microservices — Level 7) behind one app.
- This study site is interesting: it's almost all frontend — the content is pre-built into static files (a static site), so it needs no backend or database at all. Knowing when you don't need a backend is also a skill.
Common beginner mistakes
- Enforcing security in the frontend. Hiding the "Delete" button from non-admins is fine UI; not checking again on the server is a breach waiting to happen.
- "Backend = database." The backend is a program; the database is where that program keeps data. Different things (next two pages).
- Thinking "server" means special hardware. A server is just a computer running a program that answers requests. Your laptop can be one — and will be, constantly, during development ("localhost").
- Assuming one app = one frontend + one backend. Mature products have several frontends (web, iOS, Android) sharing many backend services.
Interview perspective
Check yourself
- For a food-delivery app, sort these onto frontend or backend: showing the map animation; calculating delivery fees; checking the coupon hasn't been used; remembering your dark-mode preference; storing restaurant ratings.
- Your friend "secures" an admin page by hiding the link from regular users. What's the attack, and what's the fix?
- Why does this study site work without any backend at all?
Next: What is an API? — the menu the frontend orders from, formalized.