What Is a Backend?

"The backend is where the promises your product makes are either kept or quietly broken." — an engineer who has been paged at 3 a.m.

Open any app you love. Tap a button and a message appears on someone else's screen a continent away. Refresh and your data is exactly where you left it. Pay, and money moves. None of that lives in the app on your phone — the phone is a beautiful window. The machinery behind the glass, the part that remembers, decides, charges, and coordinates millions of these windows at once, is the backend. This volume is about building it.

You have spent seven volumes becoming dangerous: you can program, you know the frontend (React), and you know the data layer (SQL). What sits between them — receiving requests, enforcing rules, talking to the database, and returning answers — is the server side. It is where correctness, security, and scale are won or lost, and it is one of the most reliably in-demand skills in the industry.

Frontend, backend, and the line between them

Software that runs on many people's devices splits, almost inevitably, into two halves:

• The frontend (client) runs on the user's device — the browser, the phone. It renders the interface, handles interaction, and is fundamentally untrusted: the user controls it and can inspect or tamper with anything in it.
• The backend (server) runs on machines you control. It holds the shared source of truth, enforces the rules, and does the work that must be trusted, coordinated, or kept secret.

Why not do everything on the client? Because a program that runs on the user's device cannot be trusted with anything that matters:

The rule of thumb every backend engineer internalizes: never trust the client. The frontend is a convenience for the user; the backend is the authority. A price, a permission, a balance — if it matters, the server checks it, no matter what the client claims.

A backend is a function from request to response

Strip away the frameworks and a backend is astonishingly simple at its core: it is a program that waits for requests and returns responses. A request comes in ("get me user 42"), the server does some work (look it up, check you're allowed to see it), and it returns a response (the user's data, or an error). That's it. Everything else — routing, auth, databases, caching — is structure around that one loop.

Because it's just a function, we can run the essence of it right here. The block below models an HTTP request as a plain object and a handler as a function that returns a response. Click Run:

Three requests, three responses: a 200 with the user, a 404 for someone who doesn't exist, a 405 for a method we don't allow. A real server adds a network listener, a router to pick the right handler, middleware, a real database instead of a Map, and thousands of concurrent connections — but the beating heart is exactly what you just ran: map each request to the right response. Hold onto this mental model; the entire volume is elaborations on it.

What a backend is responsible for

Across almost every system, the backend owns a recognizable set of jobs:

• Expose an API — a well-defined contract of endpoints the frontend (and other services) call. Most of Part II and III.
• Authenticate & authorize — know who is calling and what they're allowed to do. Part IV.
• Validate input — never trust the request body; check it before acting. Part II.
• Talk to data — read and write the database, cache hot data, store files. Part V, building on Databases (Volume 7).
• Run business logic — the actual rules: can this order ship, is this transfer allowed, what's the total.
• Integrate — call other services: payment providers, email, third-party APIs.
• Do it reliably, at scale, securely — under load, under failure, under attack. Parts VI and VII.

Where the backend runs

The frontend runs on the user's device; the backend runs somewhere you control — historically a physical server in a rack, today almost always a cloud machine or managed platform (AWS, GCP, Azure, or a PaaS like Render/Railway/Vercel functions). One backend process typically serves many users at once, which is why so much of backend engineering is about concurrency (handling many requests without them interfering) and scale (adding more machines as traffic grows). We'll meet the Node runtime and its single-threaded event loop — the surprising way one process juggles thousands of simultaneous requests — in the chapter after next.

Common Mistakes

• Trusting the client. Putting the price, the permission check, or the "isAdmin" flag in the frontend and believing it. The client is untrusted; the server must re-check everything that matters.
• Leaking secrets to the browser. Shipping an API key or database credential in frontend code — it's visible to anyone who opens dev tools. Secrets live only on the backend.
• Putting business logic only in the UI. If two clients (web + mobile) hit the same API, logic in one client isn't enforced for the other. Rules belong on the server, behind the API.
• Thinking of the backend as "just CRUD." Reading and writing rows is the easy 20%; auth, validation, concurrency, failure handling, and scale are the 80% that make it engineering.

Summary

• The backend is the server-side program that holds the shared source of truth, enforces rules and security, and exposes an API the frontend and other services call.
• The frontend is untrusted (it runs on the user's device); the backend is the authority. The golden rule: never trust the client — re-validate and re-authorize everything that matters.
• Logic lives on the server because of shared truth, security, secrets, coordination, and central work — none of which a per-device client can provide.
• At its core a backend is a simple loop: map each request to a response. Everything else is structure around that.
• Backend responsibilities: expose an API, authenticate/authorize, validate input, talk to data, run business logic, integrate, and do it all reliably, at scale, and securely — the map of this volume.

Next, we'll zoom in on the language every backend speaks — HTTP: its methods, status codes, and headers — so that "map a request to a response" becomes concrete and precise.