Servers and Clients

Every action on the web — loading a page, submitting a form, clicking Like — is a conversation between two roles: a client that makes requests and a server that responds to them. Understanding this division is the conceptual foundation for frontend development, backend development, and system design.

Target reader: Beginners who want to understand the structure of web applications. Estimated time: 10 min read Prerequisites: How the Web Works (recommended)

What a Client Is

A client is any software that initiates a request to a server. The most familiar client is a web browser (Chrome, Firefox, Safari), but clients also include:

Mobile apps (an iOS or Android app calling an API)
Desktop applications (a Slack client sending messages)
Command-line tools (curl, wget, gh)
Other servers making requests to downstream services

The defining characteristic of a client is that it starts the conversation. It does not sit and wait — it sends a request when it needs something.

What a Server Is

A server is software (running on a computer) that listens for incoming requests and responds to them. The word “server” often refers to the physical or virtual machine itself, but more precisely it means the software process listening on a network port.

A server:

Runs continuously, waiting for connections
Handles many clients simultaneously
Returns a response for every request it receives

The computer running server software can be anywhere — a data center, a cloud provider, or a laptop on the same desk. What matters is that it is reachable over the network and has a known address (IP + port).

The Client-Server Model

                     Internet
                        |
  +--------+    Request |    +--------+
  |        |  --------->|    |        |
  | Client |            |--> | Server |
  |        |  <---------|    |        |
  +--------+   Response |    +--------+
   (browser,            |   (web server,
    mobile app)         |    API server)

The flow is always the same:

The client sends a request (e.g., “GET /products”).
The server processes the request.
The server sends back a response (e.g., an HTML page or a JSON list of products).
The client uses the response (renders the page, updates the UI).

This is called the request-response model. HTTP is the protocol that defines the format of these requests and responses.

An important detail: the server never reaches out to the client unprompted. In the basic model, all communication is initiated by the client. (WebSockets and server-sent events are exceptions, covered in more advanced material.)

Types of Servers

Modern web applications use several specialized types of servers, each with a distinct role:

Server Type	Role	Examples
Web server	Serves static files (HTML, CSS, images) and routes HTTP requests	Nginx, Apache
Application server	Runs business logic — authentication, calculations, data processing	Node.js, Django, Rails, Go
API server	Responds to requests with data (usually JSON) rather than HTML	REST API, GraphQL API
Database server	Stores and retrieves structured data	PostgreSQL, MySQL, MongoDB
File/object storage	Stores large binary files (images, videos, documents)	AWS S3, Cloudflare R2
Cache server	Stores frequently accessed data in memory for fast retrieval	Redis, Memcached

A single web application typically uses several of these together. A user request might hit a web server, which forwards it to an application server, which queries a database server, then returns data back up the chain.

Frontend vs Backend

The client-server model maps closely onto the frontend/backend distinction used in web development:

+----------------------------------+     +----------------------------------+
|          CLIENT SIDE             |     |          SERVER SIDE             |
|         (Frontend)               |     |          (Backend)               |
|                                  |     |                                  |
|  Browser renders HTML/CSS/JS     |<--->|  Server processes logic + data   |
|  User sees and interacts here    |     |  Database lives here             |
|  Code: HTML, CSS, JavaScript     |     |  Code: Python, Node.js, Go, etc. |
+----------------------------------+     +----------------------------------+

	Frontend	Backend
Where it runs	In the browser (client)	On a server
What it does	Displays the UI, handles user interactions	Processes requests, queries databases, applies business logic
Languages	HTML, CSS, JavaScript	Python, Node.js, Go, Ruby, Java, etc.
What it sees	The visible interface	The data and internal logic

A full-stack developer works on both sides.

A concrete walkthrough makes the model tangible. When a Like button is clicked on a social media post:

1. Browser (client)
   └─ Sends:  POST /api/posts/1234/like
              Authorization: Bearer <token>

2. Application server
   └─ Checks:  Is this user authenticated?
   └─ Queries: Has this user already liked this post?
   └─ Writes:  INSERT INTO likes (user_id, post_id) VALUES (...)
   └─ Writes:  UPDATE posts SET like_count = like_count + 1 WHERE id = 1234

3. Database server
   └─ Stores the new like record

4. Application server
   └─ Returns: HTTP 200 OK
               { "like_count": 42, "liked_by_me": true }

5. Browser (client)
   └─ Updates the Like button to show as filled
   └─ Updates the count display to "42"

Every Like on every post on every social platform follows this same client-server pattern. The details differ, but the structure — client requests, server processes, server responds, client updates — is universal.

Summary

A client initiates requests; a server listens and responds.
The request-response model is the foundation of web communication.
Modern apps use several specialized server types: web servers, application servers, database servers, and more.
Frontend code runs in the browser (client side); backend code runs on the server.
Every web interaction, no matter how complex, follows this client-server pattern.

FAQ

Q: Can a server also be a client?

A: Yes. A backend server that calls another API (such as a payment service or weather data provider) is acting as a client in that sub-request. In a microservices architecture, servers are constantly making requests to other servers.

Q: What is an API?

A: An API (Application Programming Interface) is a defined contract for how clients can communicate with a server. A web API typically accepts HTTP requests and returns data in JSON format. It is what allows a mobile app, a browser app, and a third-party integration to all talk to the same backend.

Q: What is the difference between a web server and an application server?

A: A web server (like Nginx) mainly handles HTTP routing and serves static files. An application server runs the program logic — it decides what data to fetch, what calculations to do, and what response to send. In practice, many frameworks combine both roles.

Next: Domains and DNS

Link to this page (Japanese): サーバーとクライアント