A Typical Web App Workflow: Frontend and API

You know what an API is, what JSON looks like, and how to write a unit test. One question is left before we start building: how does a real team put all of this together?

There is no code to run in this lesson. It is about how people work together, and it explains why the rest of the course is built the way it is.

The team

A software team is not only programmers. Two groups matter for us:

• Developers write the software.
• QA (quality assurance) are the people who test it. They try to find problems before the users do.

Not every team looks like this. Some have no QA role, and some have one person who does everything. But this is a common setup, and it is the one we will use.

Frontend and backend developers

Look at the developers' box. Many organizations split it in two:

• The frontend developer builds what the user sees and touches: the screens in the browser.
• The backend developer builds what runs on the server: the API, the rules and the data.

The two sides tend to care about different things.

These are only tendencies. A good backend developer also thinks about the user, and a good frontend developer also thinks about speed.

Why split at all? Each side has its own tools and habits. A person who works on one side all day gets very good at it.

The cost is that two people now work on one feature, and they must agree on how their parts connect. That agreement is called the contract.

💡 Smaller teams often skip the split. A full-stack developer does both sides. In this course you will do both too: backend first (lessons 14 to 22), then frontend (lessons 23 to 26).

The contract

Say the shop needs a screen that shows one book. The frontend developer needs data from the API. The backend developer needs to know what to build.

Without an agreement, each one guesses. The frontend developer expects a field called title, the backend developer sends name, and the screen shows nothing.

So before any code, the two sit down and agree on the contract:

• Which endpoint: the method and path, such as GET /books/1.
• What comes back: the JSON fields and their types.
• Which status codes are used, such as 200 and 404 (lesson 00).

If this reminds you of an interface from lesson 03, it is the same idea one level up. An interface let two pieces of code agree on what a class offers, without knowing how it works inside. The contract lets two people agree on what the API offers, without knowing how the other side is built.

Here is a small contract for one endpoint in the bookshop:

GET /books/{id}

Success:    200 OK, with the book as JSON
Not found:  404 Not Found, with a short error message

And the JSON the 200 response carries:

{
  "id": 1,
  "title": "The Pragmatic Programmer",
  "author": "Andrew Hunt",
  "price": 39.90,
  "stock": 12,
  "category": "Software"
}

On the backend, the contract turns into code. A small service class holds the logic, and its interface lists what it offers. A Book is a class with the fields above:

public interface IBookService
{
    Book? GetById(int id);   // null when there is no such book: the API answers 404
}

Lesson 17 builds the real service. Notice that the contract and the code say the same thing.

Both developers keep a copy of the contract. It can be a shared document, a message thread or a short list, as long as both sides agreed on it before they started.

It gets faster later

The first contract takes a careful conversation, because everything is new. After that, many endpoints look alike.

Every kind of thing in the shop (books, customers, orders) tends to need the same few actions: list, get one, add, edit, delete. Once the team has agreed how GET /books works, the other four for books follow the same pattern. The talk becomes a quick "same as before", or is skipped.

So the team only holds a real discussion for the tricky endpoints. If something turns out to be different from the pattern, they talk again.

The flow

Now the work can start. With the contract agreed, the two developers do not have to wait for each other.

Backend developer:

1. Builds the endpoint exactly as the contract says.
2. Writes its unit tests together with it (lesson 11).
3. Spot-checks it by hand in Swagger. Swagger is a web page that the API can generate for itself. It lists every endpoint and has a button to try each one. It shows what was actually built, so the developer can confirm it matches the contract. We set it up in lesson 15.

Frontend developer:

1. Builds the screen at the same time.
2. The real API does not exist yet, so the screen uses fake data: a made-up list, typed by hand, in exactly the shape the contract promises. Using fake data in place of a real part is called mocking.

[
  { "id": 1, "title": "The Pragmatic Programmer", "author": "Andrew Hunt", "price": 39.90, "stock": 12, "category": "Software" },
  { "id": 2, "title": "Clean Code", "author": "Robert Martin", "price": 34.50, "stock": 0, "category": "Software" }
]

The frontend developer can even check how the screen looks when stock is 0, because they control the fake data.

Then they meet in the middle. The frontend swaps the fake data for real calls to the API. If both followed the contract, it mostly just works. Where it does not, the difference is small and easy to find: one side did not follow the contract, or the contract needs an update.

Finally, QA tests the finished system.

Who tests what

Testing is not one job. Each person tests their own work first.

Nobody hands over untested code and hopes someone else finds the problems.

Why this order

Look at who finds a bug at each step, and what it costs.

A bug the developer finds in seconds costs a few minutes to fix. The same bug found by QA means a report, a switch back to old code, a fix and a retest. Found by real users, it costs the most.

That is why everyone tests their own work first, and why QA comes last. It is the "tests are an investment" idea from lesson 11, applied to the whole team.

Real teams vary

The flow above is a common way to work, not the only one. Real teams differ:

• No QA role. The developers test everything, or the users report problems.
• Full-stack developers. One person does both sides, so there is less to agree. The screen and the API still follow a contract.
• Tests first. Some developers write the test before the code (called test-driven development).
• Code review. A teammate reads each change before it is accepted.
• Automated builds. A server builds and tests the code after every change, so mistakes are caught right away.
• Code first, document after. Some teams build the API and publish the contract afterwards, with Swagger.

Recap

• A software team has developers and QA. Many teams split developers into frontend (the user's side) and backend (the system's side).
• The two sides must agree on a contract before coding: the endpoint, the JSON shape and the status codes. It is like an interface, between two people.
• With a contract, both work at the same time. Backend builds the endpoint with unit tests and checks it in Swagger. Frontend builds the screens on fake data (mocking).
• Then they integrate, and QA tests the whole system.
• Familiar endpoints are agreed fast. Only the tricky ones need a real discussion.
• Everyone tests their own work first. The earlier a bug is found, the cheaper it is.
• Real teams vary. This is the common flow, not the only one.

Questions to think about

The answers are not given here on purpose, so check yourself against the lesson.

1. Why can the frontend developer start building the screen before the backend is finished?
2. Name one thing a frontend developer tends to focus on, and one for a backend developer. Why does the team need a contract between them?
3. A teammate renames the field title to name in the API and tells nobody. What goes wrong, and for whom?
4. Who writes the unit tests for the backend calculations, and who tests the whole system?
5. Why does QA come last, and not first?

Next lesson: .NET versions, and why upgrades are routine.