Two halves
A web app is split in two. The front end runs in your browser and draws what you see. The back end runs on servers far away: it keeps the data and does the work. They talk over HTTP.
Loading the page
You type shop.example and press Enter. The browser sends an HTTP request, GET /, to the web server: a program whose only job is to answer requests. HTTP itself has its own lesson in the Networking course.
For the front page, /, the web server just reads files from its disk and sends them back exactly as stored: index.html, style.css and app.js. Every visitor gets the same bytes. That is a static page.
Now the browser builds the page. HTML gives the structure (a heading, a list), CSS gives the look (colours, sizes) and JavaScript gives behaviour. All three run here, on your own device: this is the front end.
Asking for data
The page needs your orders. Its JavaScript calls fetch("/api/orders"), which sends a second HTTP request. This time it asks for data, not a page, and the page stays on screen while it waits.
Paths under /api/ are set up to go to the app server, so the web server passes the request on. The app server runs code. Its answer is dynamic: built fresh for this request, so it can differ from user to user.
The Python function for /api/orders runs. It needs stored data, so it asks the database in SQL, a language for data: SELECT item, qty FROM orders. A database keeps data safely on disk and finds rows fast.
The database answers with 3 rows: (tea, 2), (cake, 1), (juice, 3). fetchall() hands them to the Python code, which keeps them in a variable called rows, in the app server's memory.
return {"orders": rows} turns the rows into JSON: plain text that any language can read. It travels back through the web server as the HTTP response: 200 OK, Content-Type: application/json.
r.json() turns the text back into JavaScript data, and showOrders writes 3 rows into the list. Only that part of the page changes; nothing reloads. An app built this way is a single-page app.
Where code runs
Front-end code is sent to every visitor, who can read it and change it. So secrets, such as the database password, and the checks that really matter live in back-end code on the server, out of reach.
What happens
;; step 1/11 · two-halves
front end runs in the browser, on your device
HTML, CSS and JavaScript
back end runs on servers
web server, app server, database
between HTTP requests and responses
The web server, app server and database are drawn as three machines. In practice they are three programs (for example NGINX, a Python app run by a server such as Gunicorn, and PostgreSQL) that may share one computer or be spread over many. Each HTTP request and response is shown as one envelope. Underneath, they travel over a TCP connection (or QUIC with HTTP/3), usually encrypted with HTTPS; the HTTP and HTTPS lessons in the Networking course show how.