What a full-stack developer actually does

Why this matters

By the end of today you will be able to look at any website — a bank, a shop, a maintenance log — name the parts doing the work, and say where a piece of data is at each moment. That sounds modest. It is what separates people who can debug from people who guess, because you cannot fix a system whose shape you cannot picture.

Nothing gets installed today and no code gets written. Today you build the map.

The system you are actually building

"Full-stack" means you can work on every layer of a web application. There are five parts, and almost every web app you have ever used is made of exactly these.

The client — where the person is

The client is the program in front of the human. For us that is the browser (Chrome, Firefox, Safari). Its job is to take files it is given and turn them into something a person can see and click: text, layout, colours, buttons, forms.

The critical fact: the browser runs on the user's own machine, which you do not control. It may be a ten-year-old phone on bad WiFi. Anything it does — including code you sent it — is visible to the user and can be modified by them. That one fact drives a great deal of what follows, especially about security.

The server — where the decisions happen

The server is a program running on a computer somewhere else, waiting for requests and answering them. When you open a page, the browser asks a server for it; the server decides what to send back.

The server is where anything trusted or private belongs: who may see what, how a price is calculated, your secret keys. Rules enforced only in the browser are suggestions, because the user controls the browser. Rules enforced on the server are real.

The database — where facts survive

A database is a program built for storing data durably and finding it again quickly. When the server must remember something after the request ends — a user account, a maintenance record — it hands it to the database.

Why not keep it in the server's memory? Because memory is erased when the program stops, and programs stop all the time: crashes, restarts, deploys. The database keeps it on disk.

The network — the space between

The browser and server are usually on different machines, often on different continents. The network carries requests and responses between them, using a protocol (an agreed set of rules) called HTTP, which you will learn properly in Week 6.

For today, one habit: the network is slow and it fails. It is the only part of the system with a delay you can feel, and requests genuinely get lost. Good applications are designed knowing this; naive ones assume the network is instant and reliable, and fall apart.

Source control — the history of your work

Source control (you will use Git) records the history of your code: every change, when, why, and by whom, with the ability to go back. The user never touches it, but it is part of the system you work in every day, and it is what makes changing things safe.

Walkthrough: one click, traced end to end

Follow one real interaction. A technician opens a maintenance app and clicks "Show pump #3 history".

1. Browser — the technician clicks. The browser has code that says: when this is clicked, ask the server for pump #3's history. It sends a request across the network.
2. Network — the request travels to the server. It carries what is wanted (pump 3 history) and who is asking (a token proving the technician is logged in).
3. Server — the request arrives. The server checks the token: a real logged-in user, allowed to see pump #3? If not, it stops and answers "no". If yes, it needs data it does not have in memory, so it asks the database.
4. Database — it receives a query meaning "all maintenance records where pump = 3, newest first", finds those rows on disk, and returns them.
5. Server — it shapes those rows into a tidy response (usually JSON, a plain text format for structured data) and sends it back across the network.
6. Browser — the response arrives and the browser turns that data into a visible table. The technician reads it.

Six steps, five parts, one click. Every web feature you build for the rest of this course is a variation on this loop.

How to use AI today

Today's mode is tutor. Whether AI helps you learn or replaces your learning is entirely a matter of how you ask.

A tutor-style request asks for an explanation, then a small example, then lets you attempt it yourself. A request that says "give me the finished answer" produces something you cannot debug, defend, or remember. Want the first kind — before you write code, you should be able to say what that code will do.

Your turn

Draw a block diagram of a maintenance-record web app. Paper and a pen is genuinely fine; a drawing tool is fine too.

1. Draw five boxes and label them: Browser, Network, Server, Database, Git repository.
2. Draw an arrow from Browser to Server and label it with what travels along it: "request: show pump 3 history + who I am".
3. Draw the return arrow and label it: "response: list of records as JSON".
4. Draw arrows between Server and Database and label them: "query" and "rows".
5. Mark the two boundaries where the machine changes: between Browser and Server (different computers, network in between), and between Server and Database (different programs). Write next to the first one: "user controls everything on this side".
6. Connect the Git repository to the Server and Browser boxes with a dashed line labelled "the code that runs in these came from here".

Common pitfalls

• Thinking "the website" is one thing. It is at minimum two programs on two machines that communicate only by messages. Most confusing bugs live at that seam.
• Putting rules only in the browser. "The button is hidden so they can't do it" is not security — the user controls the browser. The server must check too.
• Confusing the server with the physical computer. "Server" usually means the program listening for requests. One machine can run several.
• Skipping the diagram because it feels basic. Drawing it is what proves you have the mental model, which is the entire point of today.

Verify it yourself

Open today's reference, MDN's How the web works, and find where it describes what happens when you type a URL and press Enter. Compare it to the six-step walkthrough above.

1. MDN mentions DNS, which today's lesson left out. What job does it do, and where would it fit in your diagram?
2. Does MDN agree that browser and server are separate machines exchanging messages? Find the sentence that says so.

Add DNS to your diagram once you work out where it belongs. Correcting today's simplified map with something you found yourself is exactly the skill this course is built on.