Backend & APIs

The backend is the trusted server that holds your keys and rules; an API is the contract the frontend uses to ask it for things.

Building with AI · Lesson 28 · 11 min read

Your frontend (last lesson) can’t safely hold the API key, and you can’t trust the user’s browser to enforce limits or talk to your database directly. Something trusted, sitting on a server you control, has to do all that. That something is the backend, and the way the frontend talks to it is an API. So what does the backend actually do — and what is an “API” really?

The backend is the trusted middle

The backend is code that runs on a server you control, not in the user’s browser. Because it’s out of the user’s reach, it can safely do the things the frontend can’t: hold the API key, check who the user is (auth), enforce rate limits and spend caps, talk to the model and the database, and return only what’s allowed. This app’s /api/ai proxy is exactly this — a single trusted chokepoint that every model call goes through.

An API is a contract

The backend exposes endpoints — named URLs that accept a request (usually JSON, sent with an HTTP method like POST) and return a response (usually JSON). The API is the agreed-upon shape of those requests and responses. That contract is powerful because it lets the frontend and backend be built and changed independently, as long as both keep honoring it. For example: POST /api/chat with { message } returns { reply }.

The request/response cycle

Putting it together: the frontend sends a request to an endpoint → the backend validates it, does the work (calls the model, queries the DB) → it returns a response → the frontend renders it. Errors are part of the contract too (a status and a message). The non-negotiable rule: validate every input on the server and never trust the client — the request could come from anywhere, not just your nice frontend.

An everyday analogy

Think of a bank teller window. You (the frontend) can’t walk into the vault. You fill out a standard slip (the API request) and hand it through the window to the teller (the backend), who has access to the vault (keys, database), verifies who you are, performs the transaction, and hands back a result. The format of the slip — what you’re allowed to ask for and how — is the API: a fixed contract both sides agree on. The customer never touches the vault, and the teller never just trusts a slip without checking it.

Worked example

A chat request, end to end:
1. User types “What’s our refund policy?” The frontend sends POST /api/chat with { message }.
2. The backend receives it, checks the user’s auth and their rate limit / spend cap.
3. Holding the key, the backend calls the model (perhaps with RAG retrieval) and gets a reply.
4. It returns { reply, sources } as JSON.
5. The frontend renders it (streaming, with sources — last lesson).
The key, the limits, and the database access all stayed server-side; the browser only ever saw the contract.

This is the reading. The interactive version — active-recall quiz, a hands-on experiment you run in your own AI, and an earned mastery check — is free in the app.

Start this lesson free →

← Frontend for AI Apps Database with Supabase →