🔌 Client-Server Architecture

The Essence of the Model

Client-server architecture divides a system into two roles. Clients request services; servers provide them. That's the whole idea — and it's powerful precisely because it's so simple. A single server can answer many clients at once, and a client doesn't need to know anything about how the server does its job, only how to ask.

• Clients — web browsers, mobile apps, desktop programs, IoT devices, or even other servers.
• Servers — always-on systems that hold resources and respond to requests over a well-defined protocol (usually HTTP for the web).

This split lets each side specialise: clients optimise for a smooth user experience, while servers optimise for processing power, data integrity, and security. They meet in the middle through a shared contract — the API.

The Library Analogy

Picture a public library, and the whole architecture falls into place:

And just as many patrons can use one library at the same time without tripping over each other, client-server systems handle many concurrent clients. The library doesn't hand out its only copy of a rare book to be taken home — it keeps control of its resources — exactly as a server keeps control of its data.

How the Model Evolved

The client-server idea isn't new — it's been reinvented every decade as hardware and networks changed. Seeing the arc helps you understand why today's architectures look the way they do.

• Mainframe era (1970s): one central computer did all the work; "dumb terminals" were just screens and keyboards.
• 2-tier (1980s): powerful PCs ran rich desktop apps that talked directly to a database server.
• 3-tier (1990s): a middle logic tier appeared between presentation and data, improving scalability and maintainability.
• Web apps (2000s): the browser became the universal client — no installation required.
• Mobile & cloud (2010s): diverse devices, cloud backends, and standardised APIs (REST, GraphQL).
• Microservices & serverless (2020s): backends split into small services and on-demand functions, with processing pushed to the edge.

Clients & Servers in Detail

"Client" and "server" are roles, not single machines. A real system has several kinds of each.

Common client types

• Web browsers — Chrome, Firefox, Safari; render HTML/CSS and run JavaScript in a sandbox.
• Mobile & desktop apps — native clients tuned for their platform.
• IoT devices — resource-constrained hardware with a minimal client.
• API clients — scripts and other servers with no UI at all (machine-to-machine).

Common server types

• Web servers (Nginx, Apache) — accept HTTP connections, serve static files or proxy onward.
• Application servers (Node, uWSGI, Tomcat) — run your business logic.
• Database servers (PostgreSQL, MySQL, MongoDB) — store and retrieve data.
• Auth servers (OAuth providers, identity services) — verify identity and issue tokens.
• Proxies & load balancers — route traffic, cache, and hide the internal layout.

How They Communicate

Every interaction follows the same four-beat rhythm — the request-response cycle.

Protocols

The protocol is the shared language of the conversation:

• HTTP/HTTPS — the primary web protocol; stateless, with HTTPS adding encryption.
• WebSocket — a persistent, two-way connection so the server can push data (chat, live updates).
• GraphQL — a query language letting clients ask for exactly the fields they need from one endpoint.
• gRPC — a fast, binary RPC framework popular for service-to-service calls.

Data formats

And the format is how the message body is encoded. JSON dominates modern web APIs for being lightweight and human-readable; XML lingers in enterprise and SOAP systems; Protocol Buffers are a compact binary format used with gRPC; and HTML is returned when the server renders whole pages.

A concrete request and response

Here is a real HTTP exchange — a request for one product, and the server's JSON answer:

GET /api/products/42 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600

{
  "id": 42,
  "name": "Wireless Headphones",
  "price": 89.99,
  "inStock": true,
  "categories": ["electronics", "audio"]
}

You'll dissect every part of this exchange — methods, headers, status codes — in the next lesson.

Rendering Patterns

Where does the HTML get built — on the server, in the browser, or ahead of time? That single question defines the four dominant web architectures.

Multi-Page Application (MPA)

The server generates a complete HTML page for every navigation. Simple and SEO-friendly, but each click means a full page load. Think classic WordPress sites.

Single-Page Application (SPA)

The server sends an app shell once; from then on JavaScript fetches JSON and updates the page in place. App-like and responsive, but heavier initial load and extra SEO care. Think Gmail or Twitter.

Server-Side Rendering with hydration (SSR)

The server renders the first HTML for a fast, SEO-friendly initial view, then JavaScript "hydrates" it into a live SPA. The best of both — at the cost of complexity. Think Next.js and Nuxt.

JAMstack

Pages are pre-built into static files served from a CDN, with dynamic bits added via APIs and client-side JavaScript. Extremely fast and secure, but not a fit for every app. Think Gatsby and Astro sites.

Advantages & Challenges

The client-server model earned its dominance for good reasons — but it isn't free of trade-offs.

Modern trends — microservices, serverless, edge computing, and Backend-as-a-Service (Firebase, Supabase) — are all attempts to keep the advantages while chipping away at the challenges.

Hands-on Exercise

Summary & Quiz

📚 Further Reading

• MDN — An overview of HTTP
• JAMstack.org
• Martin Fowler — Serverless Architectures

🚀 What's Next?

You've seen the shape of the conversation. Next we zoom all the way in on a single exchange in The HTTP Request/Response Cycle — the anatomy of every message that flows between client and server.