Client and server

Two programs, on two machines, talking. One asks, the other answers. That is the whole shape, and once you can draw it, "backend" stops being a job title and becomes a position on a picture.

#Who asks, who answers

A client initiates. It wants something and sends a request. A server waits, receives requests, and sends responses.

   CLIENT                          SERVER
   browser, app,     ──request──▶   a program that is
   another service                  already running and
                     ◀─response──   waiting for you

The distinction is about who starts the conversation, not about who is bigger or more important. Your phone is a client to a bank's server; that bank's server is a client to a payment provider's server. The same program is often both, and that is the normal case in a system built of services.

Two things follow immediately, and both matter:

The server is already running. It was started long before your request, and it stays running after. This is why a server has a startup that matters, why it keeps things in memory between requests, and why "restart it" is an operation with a cost.

The client cannot make the server do anything it has not been built to do. It can only ask, and only in the ways the server accepts. That set of acceptable asks is the API, and designing it well is most of backend engineering.

#The request nobody draws

The picture above is missing everything between the two boxes, and the missing part is where production problems live:

browser ─▶ DNS ─▶ load balancer ─▶ your service ─▶ database
                                        │
                                        └──▶ another service ──▶ …

• DNS turns a name into an address. When "the site is down" but the server is fine, this is a suspect.
• A load balancer picks one of several identical servers. This is why your log line might be on any of five machines, and why a bug that happens "sometimes" may be happening on one machine always.
• Your service does the work — and usually asks other things for help.
• A database holds what must outlive the process.

Each arrow can be slow, can fail, and can succeed in a way you did not expect. A request that takes two seconds is rarely two seconds of your code.

#Why "stateless" keeps coming up

A server usually handles requests from thousands of clients, and it cannot keep a conversation open with each one. So the common design is: each request carries everything needed to serve it, and the server remembers nothing about you between requests.

That sounds inconvenient and buys something large. If no request depends on a previous one, any server can handle any request — so you can run five of them behind a load balancer, restart one without anybody noticing, and add a sixth on a busy day.

The moment a server remembers something about you specifically, all three of those get harder. That is the trade, and you will meet it again under names like sessions, sticky routing and shared caches.

#What the backend is responsible for

Draw the line and the responsibilities sort themselves:

That first row on the right is the one worth memorising. Anything the client checks, it can also skip — it is code on somebody else's machine, and they can change it. A price validated only in the browser is a price a user can set. Every rule that matters is enforced on the server, and the client's version of it is a courtesy to honest users.

#Misconceptions

• "The server is a machine." It is a program that waits for requests. Many can run on one machine; one service can run on many machines.
• "Client means browser." A mobile app, another service, a script, a smart meter — anything that initiates.
• "The frontend calls the backend, so the backend is lower." They are peers with different jobs. The backend owns truth and rules; the frontend owns presentation and immediacy.