Clients and servers

The client starts every HTTP exchange. It picks a URL, builds a request, and sends it over the network.

The server listens for incoming requests. For each one, it decides what should happen and builds a response.

Imagine you open /articles/hello on a blog:

1. The browser sends a GET request for that path.
2. The server matches the path to a route handler.
3. The handler loads the article (from a file, a CMS, or a database).
4. The server responds with HTML and a 200 status code.

The server does not have to return a file named hello.html. A route can generate the page dynamically. The client only sees the finished response.

One program can play both roles. Your Node server might receive a browser request, then become a client when it calls Stripe or a database API. The role depends on who started the exchange, not on what language you wrote the code in.

I find it helps to ask two questions for every hop: who sent the request, and who answered it? That client/server label stays useful even when traffic passes through proxies, load balancers, or CDNs. Those middle boxes still speak HTTP; they just sit between the original client and the final server.

Run curl -i https://flaviocopes.com/blog/ and you are the client. Cloudflare Pages (or whatever hosts the site) is the server. You get headers and HTML back. Same roles as the browser, different interface.

Try this on your own project: trace one page load and name the client and server at each step. If your app calls a third-party API, note where your server switches from answering to requesting.