What a web app is actually made of

Four parts and one road between them

Every web app you will build is the same four things.

The browser runs on the user’s device. It is given HTML (the content and its structure), CSS (how it looks) and JavaScript (what happens when you click). It is a stranger’s machine, on a stranger’s network, and you control none of it.

The server runs somewhere you pay for. It is a program that sits waiting, and when a request arrives it decides what to send back. Your rules live here, because this is the only place a user cannot edit them.

The database is where things survive. Anything that must still exist tomorrow (bookings, accounts, messages) is written here. The server talks to it. The browser never should.

The network is the road between them, and it is slower and less reliable than anything in this list. On a train in Lucknow it is 400 milliseconds each way, and sometimes it drops.

Follow one click

A customer taps Book now.

1. The browser collects the form values and sends an HTTP request: a method (POST), a path (/api/bookings), some headers, and a body: usually JSON, which is just text shaped like {"stylist":"Anita","start":"2026-09-11T14:00"}.
2. That request crosses the internet to your server.
3. Your server code runs. It checks who is asking, validates the values, and asks the database whether that slot is free.
4. The database answers. The server writes a new row.
5. The server sends back a response: a status code (200 means fine, 401 means you are not logged in, 404 means no such thing, 500 means your code crashed) and usually some JSON.
6. The browser reads the response and changes the screen.

That loop is the whole of web development. Everything else (frameworks, hosting, authentication) is a way of arranging those six steps.

Words you will keep meeting

• Frontend is everything that runs in the browser. Backend is everything that runs on the server. A full-stack framework such as Next.js, Django or Rails writes both from one project, which is why a model can build you a working app from one sentence.
• An API is just a set of server addresses your own code calls instead of a human. /api/bookings is an API. There is nothing more to it.
• A port is a numbered door on a machine. localhost:3000 means door 3000 on this computer. That is why, when two projects start at once, the second either refuses to start (a plain Node server does) or quietly moves to the next port, as next dev does to 3001, and you can end up looking at the wrong project.
• Rendering is where the HTML is assembled. On the server, before it is sent, or in the browser afterwards by JavaScript. Both are normal, and mixing them badly is where a page turns up empty for one second and full the next.

Why this matters more than it sounds

Almost every serious mistake in AI-built software is a confusion about which of the four parts something is running in.

An API key placed in browser code is public, because the browser is a stranger’s machine. A price checked in browser JavaScript is not checked, because the browser is a stranger’s machine. A permission enforced by hiding a button is not enforced, because the browser is a stranger’s machine.

Say that sentence to yourself twice. It is the single most load-bearing fact in this course, and lesson 8 of the security block is entirely about people who forgot it.

Look at the road yourself

You do not have to take any of this on trust. Open your app, press F12 (or Ctrl+Shift+I, or Cmd+Option+I on a Mac), and choose the Network tab. Now click something.

Every request appears as a row: the path, the status code, the size, how long it took. Click one and you can read exactly what your browser sent and exactly what came back. This is free, built into every browser, and it settles arguments that would otherwise take an hour.

Two things to try immediately. First, click a button that saves something and watch the request go. If you see no request at all, nothing was saved anywhere: whatever appeared on screen was only in the browser’s memory and will vanish on refresh. Second, look at the Size column on first load. A page over about 2 MB will feel slow on a mid-range Android phone on 4G, and you have just measured it for nothing.

The limitation

The browser only shows you what crossed the road. It cannot show you what your server did internally, which query it ran, or why the database refused. For that you need the server’s logs, and if you have never opened your host’s log page, you have no view of half your app. Find that page before you need it.

What to hold on to

When something is wrong, the first question is not “what is the bug”. It is which of the four parts is this happening in. Browser, server, database, or the road. Almost every debugging session in this course starts by answering that, and the Network tab answers it in about ten seconds.