Three Layers, Three Jobs
Once Sprout has to remember plants, it stops being one program and becomes three, running on different machines. Many full-stack bugs, and most security holes, come from doing a job in the wrong layer: checking a rule only in the browser, or asking the database to worry about what a button looks like.
The rule
The browser shows, the server decides, the database remembers.
| Layer | Runs on | Owns | In Sprout |
|---|---|---|---|
| Client | the user's device | showing data, collecting input, instant feedback | the plant list, the "Add plant" form |
| Server | a machine you control | who is asking, what they may do, the rules | "only the owner may delete this plant" |
| Database | a machine you control, kept private | durable data and its basic rules | the plants table |
The client is the HTML, CSS and JavaScript running in the browser. It is fast and close to the user, but it sits on their machine. Anyone can open the developer tools, change the code, or skip the page entirely and send requests by hand. Treat everything that arrives from a client as a claim, not a fact.
The server is your code (Sprout uses Node.js) on a machine the user cannot touch. It receives requests, works out who is asking, checks whether they are allowed, validates the input, applies the rules and talks to the database. It is the only layer where a rule truly holds.
The database (Sprout uses PostgreSQL) stores data so it survives restarts, answers queries, and enforces structural rules such as "every plant has a name". Only the server talks to it. The browser never sees its address or password.
The most important line in the picture is the one between client and server. Everything on the browser's side of it can be changed by the user.
The shortcut
For any piece of logic, ask: "Would it be a problem if the user changed this?" If yes, it belongs on the server, and often in a database rule as well. If no, such as layout, sorting a list the user may already see, or a friendly hint, the client is the right place.
The trash-can button
Pure display. If a user restyles it, nothing is harmed. Client.
The classic trap is hiding the Delete button on plants that are not yours and calling that security. The button is gone, but the request is not: anyone can send it by hand. Hiding is good design; the server's check is the protection.
Drills
Answer fast — trust the rule.
Where must the rule "a plant's watering interval is at least 1 day" be enforced so nobody can bypass it?
Which job belongs to the browser?
Why does the browser never connect to PostgreSQL directly?
A developer hides the Delete button on plants the user does not own and adds no server check. What happens?
Remember
- The browser shows, the server decides, the database remembers.
- Shortcut: "Would it be a problem if the user changed this?" Yes means server, often plus a database rule.
- Trap: hiding a button is design, not security. The server must check every request.