The Asker and the Answerer

You open your laptop. You type readunderstory.ink into the browser. You hit enter. A page appears.

Simple, right? But in that half-second, something happened that most people never notice: one computer asked a question, and another computer answered. That’s it. That’s the whole web, in one line. Every website, every app, every API call, every tweet you’ve ever read — it’s just one computer asking and another answering.

The names for these two sides are client and server. You’ve heard them. You might even use them. But most developers — even working ones — don’t fully understand what they are. Because here’s the twist: they’re not types of machines. They’re roles.

Let’s get into it.

The market stall

Picture a busy market in Lagos. On one side, a trader sits behind her stall, waiting. She has tomatoes, peppers, onions. She’s not going anywhere. She’s just there, ready to respond to whoever shows up.

On the other side, you walk up. You ask for a basket of tomatoes. She weighs them, takes your money, hands them over. You walk away.

Then another customer comes. Then another. She serves them all, one at a time, always there, always ready.

That’s client-server.

Client-server model — An arrangement in which one party, the client, always initiates requests and the other, the server, always waits for and answers them. The relationship is asymmetric: only one side starts the conversation.

In plain terms: “One side always asks, the other always answers. Never the reverse.”

The trader is the server. She’s available, listening, waiting for requests. She doesn’t initiate. She responds.
You are the client. You initiate. You ask. You receive.

The relationship is asymmetric: one side starts the conversation, the other side answers it. That asymmetry is the whole point.

What “client” really means

A client is any program or device that initiates a request.

That’s it. That’s the definition. If it asks first, it’s the client.

Here’s the part most people miss: the client is not a specific type of machine. It’s whatever is asking at that moment.

Your browser (Chrome, Firefox, Safari) is a client.
Your phone app — Instagram, WhatsApp, your banking app — is a client.
curl on your terminal is a client.
Postman is a client.
A Python script that fetches weather data is a client.
Another server can be a client — when one server talks to another server, the one making the request is the client.

Client — Any program or device that initiates a request and receives the response.

In plain terms: “Whoever walks up to the stall and asks first.”

Analogy: The client is the customer at the market. It doesn’t matter whether the customer is a man, a woman, a child, rich, poor, in a car, or on foot. If they’re walking up to the stall to ask for something — they’re the client.

What “server” really means

A server is any program or device that listens for requests and responds to them.

Again — that’s the whole definition. If it waits and answers, it’s a server.

And here’s the same twist: a server is not a special type of machine. It’s just a computer that’s been told to sit and wait for requests. That’s what makes it “a server.” Not its size. Not its power. Not the fancy data centre it lives in.

A web server serves web pages. (Nginx, Apache.)
A database server serves database queries. (PostgreSQL, MongoDB.)
A mail server serves email. (Postfix, Microsoft Exchange.)
A file server serves files. (Samba, NFS.)
Your laptop, when you run python -m http.server in a folder, is a server. For real. That laptop on your desk just became a server to anyone who can reach it.

Server — Any program or device that listens for requests and responds to them.

In plain terms: “Whoever stands still, waits, and answers.”

Analogy: The server is the trader behind the stall. It doesn’t matter if she’s in a big shop or a small kiosk. It doesn’t matter if she sells tomatoes or phones or airtime. If she’s standing there, ready to respond — she’s serving.

The big idea: roles, not machines

Here’s where it gets really interesting — and where most beginners get confused for months.

The same computer can be a client and a server at the same time.

Not just “in different conversations.” At the same time. Right now, on your laptop:

Your browser (client) is talking to Google’s servers (server).
Your VS Code might be running a local dev server (server), and your browser is talking to it (client).
Your app might be making API calls (client) to Firebase, while Firebase is talking back (server).

Analogy: Think of a phone call. On any call, one person is speaking and the other is listening. But on the next call, the roles might flip. And in a group call, everyone is both speaking and listening at once.

“Client” and “server” are not identities. They’re postures — what you’re doing in this conversation, right now.

This is the day’s big unlock. Once it clicks, half of web development stops being confusing.

The heartbeat: request and response

Every client-server conversation follows the same rhythm, forever:

The client sends a request. It says, essentially: “Hey server, can I have this thing?”
The server processes the request. It checks what was asked, looks up the data, prepares an answer.
The server sends a response. It says, essentially: “Here’s what you asked for” — or “I couldn’t do that, and here’s why.”
The client receives the response. It displays it, uses it, saves it, or ignores it. Whatever it’s programmed to do.

Request — A message sent by a client asking a server to perform an action or return a resource, containing a method, a target, headers, and optionally a body.

In plain terms: “The question.”

Response — A message sent by a server in reply to a request, containing a status code, headers, and usually a body.

In plain terms: “The answer.”

That’s it. That’s the request-response cycle. Every website load, every API call, every message on Twitter, every “like” you’ve ever given — all of it is this four-step rhythm, over and over, billions of times a second, all over the world.

You’ll meet this pattern so often in this course that it becomes muscle memory. For now, just sit with it: ask, process, answer, receive. The entire web is that, on repeat.

Localhost — when the trader is you

There’s a word you’ll meet every single day as a developer, and now is the perfect time to understand it.

Localhost means “this computer, right here.” When your code says http://localhost:3000, it’s saying: “the client and the server are both me.”

Localhost — The hostname that always refers to the machine the program is running on, reached over an internal loopback interface that never touches a network.

In plain terms: “This computer, right here. Both sides of the conversation are you.”

That’s what happens when you run a React dev server, a Node backend, or a Python Flask app on your own machine. Your laptop becomes a server. Your browser becomes a client. They talk to each other — over a loopback connection that never leaves your machine.

Analogy: Imagine a market where the trader and the customer are the same person. Sounds absurd — but that’s exactly what’s happening when you develop locally. You’re both sides of the conversation, testing that the two ends can talk.

The number after localhost — like :3000 or :5173 or :8000 — is the port. Think of a port as a specific stall number in the market. One machine can host many servers, each listening on a different port, like different traders at different stalls.

We’ll go deeper into ports later. For now: localhost:3000 means “a server running on my own machine, on stall 3000.”

The other model: peer-to-peer

There’s an alternative to client-server, and it’s worth knowing because people ask about it in interviews.

Peer-to-peer — A network model in which every participant acts as both client and server, exchanging resources directly with peers and depending on no central server.

In plain terms: “Everybody grows their own tomatoes and swaps. No stall, no trader.”

In a peer-to-peer (P2P) network, there’s no fixed server. Every machine is both client and server, and they talk to each other directly.

BitTorrent — when you download a file, you’re also uploading pieces of it to others.
Blockchain — every node is equal; no central authority.
Some crypto apps — same idea.

Analogy: Instead of everyone going to the trader for tomatoes, everybody grows their own and swaps directly with each other. No stall. No trader. Just neighbours.

P2P is powerful for certain use cases — but it’s not how the web works. The web is overwhelmingly client-server. Keep P2P in your vocabulary, but don’t confuse it with the standard model.

Thick clients and thin clients

One last piece of vocabulary, then we’re done.

A thin client does very little work itself. It just displays what the server tells it. Old-school websites: the server sends fully-rendered HTML, the browser just shows it.
A thick client (also called a fat client) does a lot of the work itself. Modern SPAs like Gmail or Twitter: the browser receives data and renders everything on its own. The server barely knows what the page looks like.

Thin client — A client that performs little computation itself, relying on the server to do the work and return a largely finished result.

In plain terms: “You order a fully cooked meal.”

Thick client — A client that performs most of the application’s work itself, receiving data from the server and assembling the interface on its own.

In plain terms: “You order raw ingredients and cook at home.”

Analogy: A thin client is like ordering a fully-cooked meal at a restaurant. A thick client is like ordering raw ingredients and cooking at home.

Most modern web apps are somewhere in between — the server sends data, the client assembles the UI. We’ll unpack this properly in Module 5 when we get to CSR vs SSR.

Backstory: from mainframes to every phone on Earth

You asked for backstory. Here’s where “client-server” came from.

1950s–1960s: The mainframe era. Computers were the size of rooms and cost millions. Only big companies and universities had them. You accessed one through a dumb terminal — a screen and keyboard with no computing power of its own. All the work happened on the mainframe. That’s the purest form of a thin client ever built.

1970s–1980s: Personal computers arrive. Suddenly, individuals had computing power on their desks. The mainframe stopped being the only option. People started building software that ran locally.

1980s–1990s: The client-server era proper. Businesses realised they could split work: PCs would handle the UI and some logic (the client), and a central server would handle storage and heavy computation. This is when the term “client-server” became industry standard.

1990s–2000s: The web explodes. The browser becomes the universal client. Suddenly, you don’t install software to use a service — you just point your browser at a URL. The server does the heavy lifting; the browser just displays. This is the “thin client” model of the early web.

2005–2015: JavaScript grows up. With AJAX and then React, the browser becomes powerful enough to do real work. The client gets thicker again. Modern web apps feel like desktop apps.

2015–now: Client and server blur. Serverless functions, edge computing, React Server Components, streaming SSR — the line between client and server is moving constantly. But the relationship hasn’t changed. Someone still asks. Someone still answers.

The roles are ancient. Only the players change.

What you’d say in the room

If an interviewer asks “What’s the difference between a client and a server?” — here’s an answer that makes you sound like you’ve been around:

“Client and server aren’t types of machines — they’re roles in a conversation. The client initiates a request; the server listens and responds. Any device can be either, depending on the context. My browser is a client to Google’s servers, but my laptop is also a server when I run a local dev environment. The relationship follows a request-response cycle: the client asks, the server processes, the server answers, the client receives. It’s asymmetric — the server never initiates. That’s the model the entire web is built on.”

That answer alone will separate you from most junior candidates.

Say it like a professional

The definitions from today, in one reviewable block. Say each one out loud. If you stumble, go back to that section.

Client — Any program or device that initiates a request and receives the response.
Server — Any program or device that listens for requests and responds to them.
Client-server model — An arrangement in which one party, the client, always initiates requests and the other, the server, always waits for and answers them. The relationship is asymmetric: only one side starts the conversation.
Request — A message sent by a client asking a server to perform an action or return a resource, containing a method, a target, headers, and optionally a body.
Response — A message sent by a server in reply to a request, containing a status code, headers, and usually a body.
Localhost — The hostname that always refers to the machine the program is running on, reached over an internal loopback interface that never touches a network.
Peer-to-peer — A network model in which every participant acts as both client and server, exchanging resources directly with peers and depending on no central server.
Thin client — A client that performs little computation itself, relying on the server to do the work and return a largely finished result.
Thick client — A client that performs most of the application’s work itself, receiving data from the server and assembling the interface on its own.

Before you close this tab

Say these answers out loud, in your own words, without looking:

What defines a client? What defines a server?
Why is the relationship called “asymmetric”?
Can the same computer be both? Give a real example.
What are the four steps of the request-response cycle?
What does localhost:3000 actually mean?
What’s the difference between peer-to-peer and client-server?
What’s a thin client, and what’s a thick client?

If you can answer these seven without peeking — Day 2 is done.

If one is fuzzy, scroll back and read that section again. No shame in it. This is the foundation everything else sits on.

Tomorrow, we meet the language clients and servers actually speak to each other: HTTP and HTTPS. You’ll learn what’s in a request, what’s in a response, and why the little padlock in your browser’s address bar means more than you think.