Week 1 system check

Why this matters

Six days ago you could not name the parts of a web application. You can now draw the request path, operate a terminal, start and stop a server, and read a status code out of DevTools. Today is not new material — it is the check that those things are yours.

The test is deliberately harsh: can you define each idea precisely, without using the word itself? Vague understanding survives reading; it does not survive writing a definition someone else could act on. Today you find which ideas are solid and fix the rest, while it is still cheap.

The request path, end to end

Everything in Week 1 hangs off one sequence. Say it out loud before reading further:

browser → server → database → server → browser

1. Browser — the person clicks. The browser builds an HTTP request with a method (GET, POST) and a URL, then sends it.
2. Server — a process listening on a port receives it and decides whether it is allowed and what it means. Rules live here because the user cannot tamper with them.
3. Database — the server holds no data across requests, so it asks the database, which reads disk and returns rows.
4. Server — shapes those rows into a response, attaches a status code (200, 404, 500), sends it back.
5. Browser — receives it and updates the DOM so the person can see it.

The path goes out and comes back through the same layers. That is why the sequence is browser → server → database → server → browser, not a straight line ending at the database. The database never talks to the browser.

What separates a real definition from a hand-wave

Three failure modes account for nearly every weak definition.

Circular — it uses the term, or an obvious synonym.

"A server is a computer that serves things."

You restated the word. Someone who did not know still does not.

Vague — not wrong, but too loose to act on.

"A port is how programs connect to the internet."

Which programs? Connect how? This cannot tell you why EADDRINUSE happens.

Technically wrong — confident and false, the most dangerous kind.

"localhost is the internet address of your website."

localhost is the loopback address of whatever machine you type it on, and traffic to it never leaves that machine. A definition like this quietly produces a week of confusion.

A good definition names the category, what distinguishes it from its neighbours, and what follows from that. Compare:

"A port is a number from 1 to 65535 attached to a network message, telling the operating system which process on this machine should receive it. Because delivery must be unambiguous, only one process can listen on a port at a time — which is why starting a second server on 3000 fails with EADDRINUSE."

Category, distinction, consequence. Usable.

The eight terms

Each has one thing your definition must pin down.

Term	Must pin down
Client	It initiates the request, and runs where you have no control
Server	It listens and decides — a program, not a machine
API	A contract: which requests are accepted, which responses promised
Database	Durable storage that survives the process stopping
Process	One running instance of a program, with a PID
Port	The number routing a message to the right process
Path	Text that identifies a file, absolute or relative to the working directory
Repository	A project folder whose change history Git records

One term needs a proper introduction, because you have used it loosely but never defined it. An API — Application Programming Interface — is the agreed set of requests one program accepts from another, and the responses it promises back. For web work: the URLs your server exposes, the methods each accepts, and the shape of the data going each way. Not code — the agreement about the code.

Walkthrough: recall, then write one definition properly

First, the CLI recall drill. Close this page. On paper, write every terminal command you used this week with one line on what each does. Aim for eleven: pwd, ls, cd, mkdir, touch, cat, cp, mv, rm, --help, history. Then check yourself:

history | tail -40

tail -40 keeps the last forty lines. Anything you use daily but could not recall is a weak point — write it down as one.

Then write one definition together. Take "repository". A first attempt usually looks like:

"A repository is where your code is stored."

Vague — a USB stick stores code. Apply the three parts. Category: a folder. Distinction: Git tracks every committed change inside it. Consequence: you can see what changed and return to an earlier state.

"A repository is a project folder whose entire change history Git records. Because every committed change is kept with its author and message, you can see exactly what changed and when, and restore an earlier state."

Do that for all eight terms.

Using AI today: reviewer mode

Today's mode is reviewer — the AI attacks work you already did. A useful review returns specific, actionable findings backed by evidence: this definition is circular, this claim contradicts the docs, this one is too vague to test. Praise tells you nothing, and a rewrite is worse than useless, because the point is your understanding. So the instruction must state the restraint explicitly.

Your turn

1. Create glossary.md in ~/fullstack-journey. Define all eight terms from memory, no references open: client, server, API, database, process, port, path, repository.
2. Add one line to each naming evidence you saw this week — for port, your EADDRINUSE error; for process, the PID from lsof.
3. Re-read the draft and mark any definition that is circular, vague, or unverified.
4. Save this draft as it stands. Do not tidy it: it is half the deliverable.
5. Run the reviewer prompt above. Fix every flagged definition yourself, then write the corrected version below the original, clearly labelled.
6. Finish with three lines: your weakest topic, how you will test that it improved, and one unresolved question for Week 2.

Common pitfalls

• Looking things up while drafting. That tests search skills, not understanding. Draft blind; verify afterwards.
• Letting the AI write the fix. You lose the only measurement the day produces.
• Deleting the first draft. The comparison is the deliverable, weak definitions and all.
• Calling a topic "fine" because it felt familiar. Recognising a term and defining it are different skills; the written definition is the real test.

Verify it yourself

Open today's reference, MDN's How the web works, and read its account of a request.

1. Compare its sequence to browser → server → database → server → browser. Which steps does MDN name that this lesson compressed — DNS, TCP, packets?
2. Check client and server against MDN's wording. If MDN contradicts you, MDN wins: fix your glossary and note what you had wrong.