Client-Server

Separation of concerns

“By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.” – Roy Fielding

When to use

When designing distributed systems or Web APIs.

Why it matters

  • Portability: The UI code can be ported to iOS, Android, and Web without touching the Server.
  • Simplicity: The server doesn’t care about UI logic (rendering HTML).

Signs of Violation

  • “Server-Side Rendering” where the server is tightly coupled to a specific UI framework (controversial, as SSR is back in fashion, but pure REST implies separation).
  • Database logic inside the Desktop UI app (Client doing Server’s job).

Explanation

Problem

If the UI and Data concerns are mixed, you can’t scale them independently or update them independently.

Solution

Client sends non-UI requests (Data). Server sends non-UI responses (JSON/XML). The Client decides how to show it.

Real world analogy

A restaurant. You (Client) sit at the table. The Kitchen (Server) cooks the food. You don’t go into the kitchen to cook, and the Chef doesn’t come out to feed you. The Waiter (API) passes messages.

Pros and Cons

Pros Cons
  • Scalability
  • Independent evolution
    		•
  • Network overhead (chattiness)
    		•

    Comparison

    • Monoliths: Often violate this by mixing UI generation with data processing.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)