Client-Server Architecture
Learn the relationship between clients (hosts requesting data) and servers (data processors) over networks and pipes.
Establish Transport pipe connection
Host client (IDE or AI assistant) connects to the server process over standard output streams.
▶📚 Prerequisites(1)
🎓 Learning objectives
- •Understand the distinct roles of Clients and Servers
- •Explain communication protocols and handshakes
- •Identify the difference between standard network ports and local stdio pipes
What is it?
[AI Engineering Prerequisite] Client-Server Architecture is a distributed program structure that partitions tasks between resource requesters (clients) and service providers (servers). A client (your browser, an app, a script) sends a request; a server (a backend process, an LLM API provider) processes it and sends back a response. Nearly every AI application follows this pattern twice over: your frontend is a client to your own backend, and your backend is in turn a client to the LLM provider's API — understanding this two-hop relationship is essential before building any real AI product.
Why it exists
Compute and data are often centralized. Client-server architecture lets lightweight local programs interact with heavy data systems.
Problem it solves
Solves data synchronization and local CPU limits: users do not need to host databases or model weights on their machines.
Intuition
A client is like a customer ordering a book. The server is the warehouse that fetches the book and ships it to the customer.
Analogy
Client-server communication is like a phone call: the caller (client) dials the number, waits for a greeting (handshake), states their request, and the listener (server) responds.
Technical explanation
Clients initiate connection sessions. Servers listen on ports (e.g. 80, 443) or standard inputs (stdio), processing requests sequentially or concurrently, maintaining network state.
Architecture
Topology consists of client request handlers, transport protocols (TCP/IP, Websockets, stdio pipes), and server-side route endpoints and controller systems.
Workflow
- Client opens socket -> 2. Handshake exchange -> 3. Client calls command -> 4. Server executes and prints output.
Example
client-server simulation
class Server: def handle(self, request): return f"Processed: {request}"
client_req = "Get Status" srv = Server() print(srv.handle(client_req))
Real-world usage
Claude Desktop client spawning a local Python MCP server process and communicating over stdio.
Trade-offs
Local stdio pipes have zero network lag and are highly secure but restrict client and server to the same physical machine.
Visual explanation
Client-Server Pipeline: Client (IDE / Browser) ──(Calls / Payload)──> [Network / Pipe] ──(Processes)──> Server (Database / Model Host)
Advantages
- —
Centralized control of resources and security scopes
- —
Clients can run on low-powered machines
Disadvantages
- —
Single point of failure (if server goes down, client loses functionality)
- —
Latency delays over network lines
Common mistakes
- —
Assuming the server can initiate requests to the client spontaneously (in standard REST architectures, the client must ask first)
- —
Forgetting to close connection sockets, leading to memory leaks and port lockups
🎤 Interview questions
Contrast standard network TCP connections with standard input/output (stdio) child process communication. What are the security tradeoffs?
📂 Subtopics
The Client-Server Model: What Happens When You Visit a Website
A client asks for something; a server provides it. Your browser is a client, the website's machine is a server — nearly every AI app you'll build follows this exact same two-role split.
~11 min
The HTTP Request Lifecycle: DNS Lookup, TCP Connection, Request, Response
Every HTTP request goes through the same four stages: find the server's address (DNS), open a reliable connection (TCP), send the request, and receive the response — worth understanding since each stage is a place things can be slow or fail.
~13 min
Synchronous vs Asynchronous: Blocking vs Non-Blocking, and Why It Matters for LLM Apps
Synchronous code waits, doing nothing else, until an operation finishes. Asynchronous code can work on other things while waiting — essential for LLM apps, where a single generation can take many seconds.
~13 min
Relevant for AI Apps: How Your Frontend Talks to a FastAPI Backend
Tying the whole unit together with the concrete shape of a real AI app: a browser frontend, a FastAPI backend, and the LLM provider as a THIRD party the backend talks to on the frontend's behalf.
~13 min