What a backend actually does

You've built a page with React. You can write a JOIN that pulls exactly the rows you need. And yet the two don't talk to each other, because there's a whole layer missing in between, and that layer is what this series builds.

Open your browser's dev tools on any real site and watch the Network tab while you click around. You'll see requests firing off to some server, JSON coming back, the page updating. That server is the backend: the program that owns the database, enforces the rules, and decides what any given request is allowed to see. Nothing reaches the database except through it.

Why the browser can't just talk to the database

Say you wanted to skip the middle layer entirely. Your React app already knows how to fetch, so why not have it query the database straight from the client?

Two reasons kill that idea immediately.

Credentials. A database connection needs a username and password, or a connection string, or an API key. Ship that inside your JavaScript bundle and anyone who opens dev tools has it. Client-side code is public code, full stop. It doesn't matter how it's minified or obfuscated, a determined reader gets it out in minutes.

Rules. Say your app tracks bookmarks, and each person should only see their own. If the client queried the database directly, that rule would have to live in the client, and a modified request or a tampered client (a rewritten fetch call, a Postman request with the right shape) skips it entirely. Rules that live in the browser aren't rules. They're suggestions.

A backend fixes both. It holds the one connection to the database, behind credentials that never leave the server. Every request it receives gets checked against the rules before touching a single row: are you logged in, is this record yours, is the input well-formed. The client never gets closer to the data than what the backend decides to hand back.

The shape of a backend

Strip away the framework and a backend is three jobs done over and over, once per request:

1. Route the request to the right piece of code, based on its method and path.
2. Authenticate and validate, deciding who's asking and whether what they sent makes sense.
3. Talk to the database and shape a response.

That's it. Everything else, whether you reach for Express, Fastify, or raw Node, is scaffolding around those three steps. This series builds all three, in order, using a real running example instead of toy snippets.

The example: Linkstash

Across these fourteen lessons you'll build Linkstash, a small API for saving and organizing bookmarks. It has two resources: users, who register and log in, and links, which belong to a user and can be created, listed, fetched, and deleted. That's a deliberately small surface, because the goal isn't to cover every feature a real API might have. It's to cover the handful of decisions that show up in nearly every backend, correctly, once, so you recognize them everywhere else.

Here's the full route table you'll build toward:

Small, but every line in it hides a decision worth understanding. Why does registration return 201 and login 200? Why does deleting something return no body at all? What happens when you ask for a link that belongs to someone else? Those aren't arbitrary choices, they're the kind of thing that separates an API developers trust from one they route around.

What you already know, and what's new

If you've followed the JavaScript series, you already know functions, objects, and async code. If you've worked through why you'd learn SQL, you know how to shape a query and read a result set. Both of those skills carry over directly. What's new here is the request/response cycle itself: how a piece of code decides which function runs for a given URL, how it reads what the client sent, and how it turns a database row into JSON someone else's code can use.

You won't need a framework opinion yet. The next lesson starts with nothing but Node itself, no Express, no dependencies, just the http module and a function, so you can see exactly what a framework is doing for you before you let one do it.

Next up: Your first Node server, no framework, where you'll write the smallest possible thing that can answer an HTTP request.