Course outline · 0% complete

0/27 lessons0%

Course overview →

Clients and servers

lesson 7-1 · ~9 min · 22/27

Unit 6 covered what happens to a program's variables when the program ends or the power goes off.

They are gone. RAM is volatile, and only storage persists, as lesson 6-2 established.

Anything worth keeping must be explicitly written to storage, or, as you are about to see, sent to a server that stores it for you.

Two computers talking

So far everything ran on one machine. The internet is what happens when programs on different machines send each other data.

The pattern behind nearly all of it is client and server:

  • A client is the program that asks: your browser, your phone apps
  • A server is a program (running on a computer that is usually in a data center, a warehouse-sized building full of computers run around the clock exactly for this) that answers: it waits, receives requests, and sends back responses

When you visit a website, your browser sends a request across the internet, something like "GET the page at hackuniversity.dev". The server receives it, runs code to build or fetch the page, and sends back a response containing the page data. Your browser then draws it.

It is lesson 1-1's triangle stretched across the planet: the request is the server's input, its code is the process, and the response is its output. A server is just a program, and people write servers in Python every day.

client(browser)server(data center)request →← responseone round trip, usually well under a second
A request travels from client to server, the server's code runs, and a response travels back. Every page load is at least one of these round trips.

A weather app in client-server terms

The statement that fits is: the app, acting as the client, sent a request, and a server responded with the current forecast data.

The app is the client. It requested the forecast for your city, a server looked it up and responded, and the app drew the result.

No request means no response, which is why the app struggles without an internet connection. What it shows in that situation is a useful clue about how it was built: an app that displays yesterday's forecast when offline saved the last response, and one that shows nothing kept none.

That saved copy is called a cache, and it is the standard answer to a slow or unreliable network. The request still happens when it can, and the old response fills the gap in the meantime.

The name for the answering program

It is the server.

It is an ordinary program in an endless loop: wait for a request, process it, send a response, and wait again. The asking side is the client.

The word gets used loosely for the physical computer the program runs on, which is a lasting source of confusion. One machine can run many server programs at once, and one server program can run across many machines.

Worth noticing how little of this is new. That endless loop is lesson 5-2's while loop, and the request-process-response shape is lesson 1-1's triangle with a network in the middle. A server is not a special kind of software, it is a program whose input arrives from somewhere else.