How the Front and Back Talk

Lesson 5 · taught by Pip

So far we've met two rooms. The front end is the part you touch — the buttons and screens. The back end is the part that does the heavy work — the math, the checking, the remembering.

But two rooms can't help each other if they never speak. So today we learn how they pass notes. 🐙

The waiter and the kitchen

Picture a restaurant. You sit at a table (the front end). The kitchen is in the back (the back end). You never walk into the kitchen yourself — and the cook never comes to your table to ask what you'd like.

Instead, a waiter carries the message. You say "one bowl of soup," the waiter carries that order back to the kitchen, and a little later the waiter returns with a plate.

That back-and-forth has a name in app-building: request and response.

• A request is the front end asking for something: "Give me this person's order history."
• A response is the back end answering: here's the history, or "I couldn't find it."

The front end asks. The back end answers. Ask, answer, ask, answer — a steady rhythm, like a waiter walking the same path all night.

The menu has a name: the API

Now, here's the clever part. You don't shout any random demand at the waiter. You order from the menu. The menu lists exactly what the kitchen is willing to make.

In app-building, that menu is called an API. (It stands for "application programming interface," but the menu picture is all you need.) An API is the fixed list of things the front end is allowed to ask the back end for, and the exact words to ask in.

So the front end can't say "hand me everything you've got." It can only pick from the menu: "place an order," "look up a price," "show my profile." If it's not on the menu, the kitchen won't make it.

Why this clean hand-off matters

This waiter-and-menu setup isn't fussy for no reason. It buys an app three big things.

Fast. The waiter only carries small notes, not the whole kitchen. The front end asks for just what it needs, so the back end isn't dragged into every little thing.

Safe. Because the menu is fixed, the front end can't sneak into the kitchen and grab whatever it wants. The back end decides what's on offer and checks every order before cooking. Strangers can't order off-menu.

Easy to change. This is my favorite. The kitchen can buy a new stove, hire a new cook, or completely rearrange itself — and as long as the menu stays the same, your table never notices. Likewise, the dining room can get new chairs and paint without touching the kitchen.

That's the real gift: you can fix or improve one room without breaking the other. Builders lean on this every single day.

Your turn

Think of an app you used today — ordering food, checking a balance, sending a message. Pick one button you tapped.

What was the request (what did the front end ask for), and what was the response (what came back to your screen)? Say it in waiter terms: "I ordered ___, and the kitchen sent back ___."

If you can name the ask and the answer, you've spotted the rhythm that runs every app.

Next, we step back and notice something: this same restaurant can be reached three different ways — through a phone, a desktop, or a browser. That's Phone, Desktop, and Web Apps. See you there. 🐙