Client/Server and Layered
When a DabbaGo customer taps "Order", her phone does not cook anything or charge anyone. It sends a request to DabbaGo's server and waits for an answer. Inside that server, the request passes through a stack of code: one part reads the request, another applies the 10:30 am cut-off, another saves to the database. These two ideas, client/server and layers, are the oldest and most common architectural styles, and most systems still start with them.
The rule
Clients ask, the server decides; each layer talks only to the one below.
Client/server splits a system in two:
- Clients: phones, browsers, the kitchen tablet. They show things and send requests. There are many of them, and they cannot be trusted with rules or secrets, because users control them.
- Server: the shared, trusted side. It holds the data and enforces the rules for every client. The customer app, rider app and kitchen tablet all ask the same server.
That is why the cut-off check belongs on the server. A check only in the phone app could be bypassed by anyone who sends the request another way.
Layered architecture organises the server's code into horizontal layers:
Presentation receives requests, returns responses (API handlers, pages)
Business rules: cut-off time, kitchen capacity, pricing
Data access reads and writes the database
DatabaseEach layer depends only on the layer directly beneath it. Presentation never writes SQL; data access never decides prices. The payoff: you can change the database with changes only in the data layer, or add a new API alongside the web pages without touching the rules.
Layers have costs too. A simple read may pass through every layer doing nothing but handing data down, sometimes called the sinkhole problem. And layers split code by technical role, so one business feature, such as "skip tomorrow's tiffin", is spread across all three. For small and medium apps, the clarity is usually worth it.
The shortcut
For any piece of code, ask "Is this showing, deciding, or storing?" Showing goes in presentation (or the client), deciding goes in business, storing goes in data access. Anything that decides must run on the server.
Showing
The phone greys out the button after 10:30, and the API handler turns the request into a call. Client and presentation layer.
The trap is trusting the client. Greying out the button is a courtesy; the server's check is the rule.
Drills
Answer fast — trust the rule.
Why must DabbaGo's cut-off check run on the server, even if the app also checks it?
In a layered server, which layer should calculate the price of a tiffin?
DabbaGo moves from one database product to another. In a well-layered app, where should most changes happen?
A request to read today's menu passes through three layers that each just pass the data along. What is this problem called?
Remember
- Clients ask, the server decides; each layer talks only to the one below.
- Shortcut: "is this showing, deciding, or storing?"
- Trap: trusting the client to enforce rules.