What runs in the browser, and what runs on a server

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll know which parts of a web app run in the browser, and which run on a server. And why secrets, and the final say on who may do what, stay on the server.

A web app is split across the network. On one side is the frontend. It runs in the visitor's browser, on their computer. On the other side, the backend runs on a server you control. Between them, requests go one way, and responses come back.

[00:30] The browser's side

Start in the browser. Say you open shop dot example dot com. The browser downloads three kinds of files. First, HTML. That's the content. Then CSS, for how it looks. And JavaScript, for what happens when you click. Then the browser runs them itself, on the visitor's laptop or phone. That's the frontend, also called the client.

Frontend code is good at what happens on screen. Opening a menu. Warning that a form field is empty. Updating the cart count, without reloading the page.

[01:06] The server's side

Now the other side. The backend is a program running on a server. It receives HTTP requests, like the ones you met in Cloud foundations. It reads and writes the database, and calls other services, like a payment provider. Then it sends a response back. It can be written in any language. Visitors only see its responses, never its code or its passwords.

[01:34] What the browser can't be trusted with

Here's the catch. The visitor owns their browser. With the developer tools open, anyone can read every file your frontend downloaded. They can change what its JavaScript does. Or send any request they like. Two rules follow from that.

Rule one. Secrets stay on the server. An API key in frontend code is published to every visitor, even inside a minified file. Build tools like Vite and Next.js can copy variables into frontend code. Those values are public on purpose. So the backend keeps the key, and the frontend asks the backend.

[02:14] The server makes the final check

Rule two. The server makes the final check. Hiding the Delete button from people who aren't admins is good design. But it isn't security. Anyone can send the delete request by hand. So on every request, the server checks who is asking, and whether they're allowed.

[02:32] Where a piece of code goes

Where does a piece of code go? Ask two questions. Does it need a secret, the database, or the power to decide who's allowed? It goes on the server. Does it react to what the visitor does on the page, without waiting? It goes in the browser. Some work belongs on both sides, like checking that an email address looks right. The browser checks it for instant feedback. The server checks it again before saving, because the browser's check can be skipped.

[03:04] Recap

So, a quick recap. The frontend runs in the browser. The backend runs on your server. Everything in the browser can be read and changed by the visitor. So secrets, and the final check on every request, stay on the server.

[03:20] Check yourself

Here's a question to check yourself. Your frontend calls a weather API. You put the API key in the JavaScript, so the call works. What's wrong? Every visitor can read the key. Make the call from your backend, which keeps the key. Next up: static sites, server-rendered apps and APIs. I'll see you there.