The Client-Server Model: What Happens When You Visit a Website

The client-server model is one of the most fundamental patterns in all of computing, and it directly underlies everything covered in the api-basics unit: two roles, a client that REQUESTS something and a server that PROVIDES it. It's the same restaurant relationship from the api-basics unit, but now focused on the MACHINES involved rather than the request/response messages themselves.

The client is whatever initiates the interaction — your web browser, a mobile app, or a script calling an API. Clients are typically what a specific user is directly interacting with, and there are usually MANY of them (millions of browsers might connect to the same website). The server is the machine that WAITS for requests and responds to them — it holds the actual data or does the actual computation, and typically there are far FEWER servers than clients (often just one, or a small cluster, serving all those millions of browsers).

Walking through 'what happens when you visit a website' makes this concrete. You type a URL into your browser (the client) and hit enter. Your browser needs to find WHICH computer, on the whole internet, actually holds that website — this is DNS lookup, covered in depth in the next subtopic, which translates a human-readable name ('google.com') into a specific machine address. Once your browser knows the address, it opens a connection to that server and sends a request ('please send me the homepage'). The server receives the request, does whatever work is needed (querying a database, running some logic, or just reading a stored file), and sends back a response — typically HTML, CSS, and JavaScript that your browser then renders into the page you see.

One server can (and usually does) handle requests from enormous numbers of clients simultaneously — this many-clients-to-few-servers ratio is exactly why servers are typically powerful, always-on machines (or cloud infrastructure), while clients can be anything from a high-end desktop to a cheap phone. This split is also why you'll hear 'frontend' (the client-side code, running in the user's browser) and 'backend' (the server-side code, running on the provider's machine) as near-synonyms for client/server in web-development conversations — a distinction that matters directly for building AI applications, where your frontend (what the user sees and types into) is a separate program from your backend (which actually calls the LLM API and returns results).

# A minimal client-server pair using Python's built-in http.server --
# no external dependencies -- to make the two-role split concrete.

import http.server
import threading
import urllib.request
import json

class TinyServer(http.server.BaseHTTPRequestHandler):
    """The SERVER: waits for requests, does the work, sends a response."""
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(json.dumps({"message": "Hello from the server!"}).encode())

    def log_message(self, *args):
        pass  # silence default logging for this demo

server = http.server.HTTPServer(("localhost", 8899), TinyServer)
thread = threading.Thread(target=server.serve_forever, daemon=True)
thread.start()          # the server now waits in the background

# The CLIENT: initiates the request, receives the response
with urllib.request.urlopen("http://localhost:8899") as response:
    data = json.loads(response.read())
    print(f"Client received: {data}")

server.shutdown()