Client and Server

What is it?

When you open an app or website, the thing you're looking at — the screen, the buttons — is called the client. It usually doesn't have all the data or logic itself; instead, it sends a request over the internet to a server: a computer somewhere else that has the actual data and does the real processing, then sends a response back.

This split — client asks, server answers — is the foundation almost every piece of software on the internet is built on.

Explain like I'm 10

It's like ordering food at a restaurant. You (the client) don't cook the meal yourself — you tell the waiter what you want, the kitchen (the server) prepares it, and the waiter brings it back to your table.

Examples

A basic client-server exchange

// Client (browser) sends a request:
fetch("https://api.example.com/users/1")
  .then((response) => response.json())
  .then((user) => console.log(user));

// Server receives the request, looks up the data,
// and sends back something like:
// { "id": 1, "name": "Amara" }

How it works

The client sends a request over the network specifying what it wants. The server receives that request, does whatever work is needed (looking up data, running logic), and sends a response back. The client then updates what the user sees, based on that response.

Client (app/browser)
       │  sends a request
       ▼
     Server
       │  processes it, sends a response
       ▼
Client (app/browser) — updates the screen

Why does it exist?

Splitting work this way lets many different clients (phones, browsers, smart TVs) share the same server and data, without each device needing to store and manage everything itself. It also lets the server be updated or scaled independently of the apps that use it.

When to use it

This model applies to essentially any networked application — web apps, mobile apps, games with online features — any time one program needs data or processing that lives somewhere else.

When not to use it

A fully offline tool that never talks to another machine doesn't need a client-server split at all. And for something genuinely tiny and local, introducing a whole separate server just adds operational complexity with no real benefit.

Common mistakes

• Assuming the client can be trusted — a server should always re-check anything important, since clients can be modified by users.

• Forgetting that a request/response trip takes real time (network latency), which affects how responsive an app feels.

• Putting sensitive logic or secrets in client-side code, where anyone can inspect it.

Practice exercises

1. Easy:

   Open your browser's Network tab and find one request your favorite website sends to its server.

2. Medium:

   Explain, in your own words, why a weather app needs a server instead of just knowing the weather itself.

3. Hard:

   Describe what could go wrong if a shopping app trusted the price sent from the client instead of verifying it on the server.

Interview questions

What is the client-server model?

An architecture where a client sends requests to a server, which processes them and returns a response, rather than the client handling everything itself.

Why shouldn't a server trust data coming from the client?

Because client-side code and requests can be modified or forged by anyone, so the server must independently validate anything security- or business-critical.

What is latency, in the context of client-server communication?

The time it takes for a request to travel to the server and for the response to travel back — a key factor in how fast an app feels.

What's the difference between a thin client and a thick (fat) client?

A thin client does minimal processing and relies on the server for most logic and data (e.g. a basic web page); a thick client handles significant logic and state locally, only talking to the server when it needs data or to persist changes (e.g. a native desktop app).

Why can many different kinds of clients (web, mobile, smart TV) all share the same server?

Because the server exposes its data and logic through a shared protocol (like HTTP) rather than a client-specific interface, so any client that speaks that protocol correctly can use it, regardless of what device or platform it runs on.

What is a request-response cycle, and why does understanding it matter for building responsive apps?

It's the full round trip of a client sending a request and receiving a response — understanding it matters because every cycle takes real time, so an app that triggers many unnecessary cycles (or blocks the UI while waiting on one) will feel slow even if the server itself is fast.

At a conceptual level, how does a client know which physical server to talk to when it makes a request?

The client resolves a human-readable address (like a domain name) into a network location via DNS, then opens a connection to that location — the client doesn't need to know or care which actual machine ends up handling the request.

How should a well-built client handle a server that's slow to respond?

It should avoid blocking the whole UI, show appropriate loading/pending state, and set a reasonable timeout rather than waiting indefinitely — treating a slow response as an expected condition to design for, not an edge case.

Why is validating input only on the client side considered a security anti-pattern?

Because client-side code runs on a device the user fully controls — it can be bypassed, modified, or skipped entirely by sending requests directly, so any validation that matters for security or data integrity must also be enforced on the server.

What's the difference between synchronous and asynchronous client-server communication?

In a synchronous exchange, the client waits for the server's response before doing anything else; in an asynchronous exchange, the client continues other work and handles the response (or a notification) whenever it eventually arrives.

Can a server ever act as a client? Give an example.

Yes — when a server needs data or work from another service, it makes its own outgoing request and acts as a client to that service, e.g. a backend server calling a third-party payment API before returning a response to the original client.

Why does moving business logic from the client to the server usually improve security, even at the cost of extra latency?

Logic that runs on the server is outside the user's control and can't be tampered with or bypassed the way client-side code can, so anything where correctness or trust matters (pricing, permissions, validation) is safer enforced there, even though it means an extra round trip.

What's the difference between latency and bandwidth?

Latency is the delay before data starts arriving; bandwidth is how much data can be transferred per unit of time once it's flowing — a connection can have low latency but low bandwidth, or vice versa, and each affects performance differently.

Why might a client cache data locally instead of requesting it from the server every time, and what's the trade-off?

Caching avoids the latency and load cost of repeating identical requests, but risks the client working with stale data if the server-side data changes and the cache isn't invalidated or refreshed appropriately.

What is a network round trip, and why do developers try to minimize how many a page or app makes?

It's one full request-response exchange between client and server; each one adds latency, so an app that makes many sequential round trips (instead of batching or parallelizing them) ends up feeling noticeably slower than the actual server processing time would suggest.

How does the client-server model differ from a peer-to-peer model?

In client-server, roles are fixed — clients request, servers respond, and servers are usually centralized; in peer-to-peer, participants act as both client and server to each other, with no required central authority coordinating every exchange.

What role does the server play when multiple clients try to modify the same data at the same time?

The server acts as the single source of truth that decides how concurrent updates are ordered or reconciled (e.g. via locks, transactions, or conflict resolution rules) — without that central arbiter, clients could overwrite each other's changes inconsistently.

Why do mobile apps often need to handle network failures more gracefully than typical desktop web apps?

Mobile devices frequently lose or switch connectivity (moving between Wi-Fi and cellular, entering low-signal areas), so a mobile client needs to expect intermittent failures and design for retries, offline states, or queued requests rather than assuming a stable connection.