How the backend's job got smaller
If the frontend settles what sits where on a screen, the backend settles what gets displayed in it. Both, in the end, are taking a request on a server and returning values.
The split was not always this clean, because backend tools used to draw the screen too. Shaping the data, painting the view, and wiring the two together lived in one frame, a arrangement called the MVC pattern. In Python, Django held that seat for a long time.
Then, as the previous post described, screen drawing moved over to Next.js. The view part fell away, and one question was left: what values to hand back.
A lighter tool built only for that took the seat. That is FastAPI. The name shows up constantly in vibe coding because this is where the seat is now. Every language has several such tools; Spring in Java and Laravel in PHP occupy the same place.
API and JSON
An API is the counter where programs meet each other. Just as the place where a person meets a computer is a user interface, the place where one program meets another gets the same name.
The frontend and backend talk across that counter. The frontend prepares the frame it will draw and asks the backend for the values to fill it; the backend answers.
The format of that answer is JSON: open a brace, pair names with values, separate with commas. A fixed format is what lets the receiving side parse it mechanically.
The backend is structurally the same as the frontend. Libraries other people built are pulled in with pip and merged with your code. Same position as npm, different name.
request GET /api/posts?page=2
response {
"items": [
{ "id": 11, "title": "First post" },
{ "id": 12, "title": "Second post" }
],
"total": 57,
"page": 2,
"pageSize": 10
}API design settles three things
APIs get called designed because there are three things to settle.
First, the address rules. Which address returns a list and which returns one item. With a rule in place, the next person can tell what an address does by looking at it.
Second, the split of actions. What a user does comes down to four things: create, read, update, delete, abbreviated CRUD. The same address is split among the four by the method used to call it.
Third, the shape of the response. This is the one most often skipped. A list is not enough on its own. How many there are in total and which page this is have to travel with it, or the screen cannot draw page navigation. Login responses and error responses need their shapes settled too.
| Action | Method | Example address |
|---|---|---|
| Read a list | GET | /api/posts |
| Read one | GET | /api/posts/12 |
| Create | POST | /api/posts |
| Update | PUT · PATCH | /api/posts/12 |
| Delete | DELETE | /api/posts/12 |
Hand an agent these three first
Settling these three was originally about working with other developers. A rule keeps people from using someone else's API by guesswork.
The same value applies when handing work to an agent. Leave them unsettled and every attempt produces a different shape. Yesterday's list carried a total and today's does not; the error format differs from screen to screen. The frontend code then keeps wobbling.
So change the order. Before asking for code, settle address rules, action split and response shape as a document. Then ask for an implementation of that spec.
Putting just those three up front makes what follows far steadier. Next we look at where the backend pulls its values from: the database.