Recap and Practice

Key takeaways

• Every app is four parts: a frontend (what users see), a backend (the rules and logic), a database (where data persists), and hosting (where it all runs). The frontend never touches the database directly — it goes through the backend.
• In the browser, HTML is structure, CSS is style, and JavaScript is behavior; code changes the page by changing the DOM.
• You don't write everything yourself — packages (managed by npm via package.json and a lockfile) supply solved problems as dependencies.
• Environment variables keep secrets out of code and let the same code behave correctly in dev and prod.
• A request flows frontend → hosting → backend → database and back; naming the layer a problem lives in is half of solving it.

Try it

Pick an app you use daily and narrate one action through the layers out loud: "I tap send (frontend) → it goes to their server (backend) → which checks I'm allowed and saves the message (database) → and the chat updates (frontend)." Then guess which layer each problem lives in: the button looks misaligned; the app says "you're not logged in"; a message from yesterday is gone. Getting good at this naming is the skill the rest of the book builds on.

Prompt of the chapter

I'm learning how apps fit together. Here is a feature I want:
<one sentence describing what the user should be able to do>

Before writing any code, break it down by layer for me:
- Frontend: what the user sees and what gets sent
- Backend: what rules/checks must run, and where
- Database: what data needs to be stored or read
- Any env vars or config (especially secrets) involved

Then describe the request flow from click to result in numbered steps.
Keep it in plain language — I want to understand the shape before the code.