One asks, one answers

Think of it when a screen shows data that lives on another computer, or you wonder where a piece of code actually runs.

In everyday life

A pharmacy counter: you ask, and the pharmacist in the back fetches the medicine and applies the rules. You cannot walk behind the counter, and a closed window means no answer even when the shelves are full.

One case

A commuter on a train opens a bank app at 08:15 and taps “Balance”. The app holds no balance itself, so it sends a request to the bank’s server. The train enters a tunnel, the request never arrives, and the screen shows a spinner for 30 seconds. The money was safe on the server the whole time.

One asks, one answers
The ideaHow systems talk
One asks, one answers

One program, the client, sends a request. Another program, the server, does the work and sends back an answer. A phone app is a client; the computer that holds a bank’s accounts is a server.

How systems talk, Foundations

Every case

Most software is split this way. The client is the part a person touches: a browser, a phone app, a script. The server holds the shared data and the rules. Every answer the client shows must cross a network first, and a network can be slow, down or cut. So a client can fail to reach its server even when both programs are fine.

The word

Engineers call this

client and serverOne program, the client, sends a request. Another program, the server, does the work and sends back an answer. A phone app is a client; the computer that holds a bank’s accounts is a server.

For every piece of code, know which side it runs on. Keep shared data and rules on the server, because the person holding the client can change it.

Where this idea leads

Skills that encode it

  • make-bot-ui pstackThe local server, not the browser, holds the key and POSTs to the webhook, so the client never sees it.
  • principle-boundary-discipline pstackValidates and returns errors “at boundaries” such as network protocols, where a client’s data arrives.