Two kinds of round trip

The moment you type an address, the container round trip begins. What comes back is HTML, and every CSS file, image and JavaScript file written inside it sends the browser off to fetch that one too.

So ① does not finish in a single go. It makes one round trip per file, which means showing one page is a pile of dozens of round trips.

The big thing about what travels here is that the contents are the same for everybody. The style.css you get and the style.css the person next to you gets are the same file.

If all you do is hand out the same thing, no program has to run. You return the file that is sitting there, as it is. That is why this round trip is fast, and cheap to keep serving.

Once the container has arrived and the JavaScript starts running, the second round trip sets off. It goes and asks who is logged in, and which posts are theirs.

What comes back here is usually data only, not HTML. There is nothing in it about how things should look — just values, lined up. The usual way of carrying it is a format called JSON.

The decisive difference from ① is that something has to think before it answers. It checks who is asking, goes and looks in the database, and picks out only that person's share. That is nothing like handing back a file that is already sitting there.

Which is why ① and ② are often handled by different servers.

These two round trips have names.

• The frontend … the side that runs on the device in front of you (the browser). Its job is showing things, and taking what the person does
• The backend … the side that runs on the server. Its job is keeping the data, and deciding whether something is allowed

The reason to split them is that you change them for different reasons. You do not need to touch how a price is worked out to change the colour of a button. And fixing the price calculation does not change how the screen is put together.

The other big one: one backend can be reused by several kinds of frontend. The web screen and the phone app can both hit the same data round trip. That works precisely because the data carries no appearance.

This is the most important line to draw. Anything you send to the frontend is completely visible to the person using it.

Browsers come with developer tools, and they can read the HTML that arrived, the JavaScript, and the contents of every round trip. Obfuscating it does not hide it, and it can be rewritten and run as well.

Which means you cannot keep a secret in the frontend. Write the API key for an outside service into your JavaScript and you have published it.

Decisions are the same. Doing "only show the button to an admin" on the screen alone still leaves the round trip behind that button as something anyone can build by hand. So the backend has to make the decision over again.

The phrase to remember: the check on the screen is a courtesy, the check on the server is the real one.

HTTP has a property that explains a lot once you know it. When a round trip ends, the server forgets who you were (it is stateless).

So every data round trip starts from scratch. "But I logged in a moment ago" gets you nowhere.

Which is why every request carries an ID. Sometimes it sits in a cookie and goes automatically, sometimes it goes in a field called Authorization. Either way, the part that matters is that you attach it every time.

Forgetting is not laziness. It is designed that way so you can run as many servers as you like. Whichever machine you land on gives you the same answer, and that is only possible because it does not remember last time.

Everything so far, on one page.

The container round trip is answered by whatever hands out the files sitting there. The data round trip is answered by a program that runs and goes all the way to the database.

With this map in your head you can split the causes apart when things are slow, too. Slow until the frame appears is a story about ① (the files are big, there are a lot of them). The frame is there but the contents never arrive is a story about ② (the database is slow, there are too many round trips).

Where you fix it, and how, are completely different.

How heavy the traffic is does not come down to how much you carry. Each round trip costs a fixed amount of effort, so the sheer number of them starts to tell.

Getting small pieces of data in a hundred separate goes is far slower than getting the lot in one. Every single round trip has to find the other side, connect, check, and so on — that always comes attached.

A common failure is going off to ask one at a time in order to show a list. To show 20 posts: one round trip for the list of posts, then 20 more asking who wrote each one. 21 round trips in total.

The fix is to get it together. Have the round trip for the list return the writers along with the posts.

Sometimes one screen has things from both round trips mixed together.

Take an article page on a news site. The body of the article arrives with the container, and then the recommended articles underneath turn up a moment later. The first came over ①, the second over ②.

Which one carries what is decided by is it the same for everybody and is it needed straight away. The same body text for everyone gets there faster carried in ①, and recommendations that vary by person are better carried later in ②, so the first paint is not held up.

In the next lesson we look at how you choose how much to carry in ① — where the HTML gets built.

The four things this chapter rests on.

• Round trips come in two kinds: the container round trip (the same whoever looks) and the data round trip (different from person to person)
• The frontend shows, the backend keeps and decides. One backend can be reused by several frontends
• Everything you send to the browser is visible. No secrets can live there, and the server decides over again
• The server does not remember last time, so the ID goes on every single request

When someone tells you "it is not showing", settle which round trip we are talking about first. That alone halves the places you have to look.