How the web actually works.

The whole web, in 30 seconds

The web is millions of computers doing one simple thing over and over: one computer asks, another answers. The computer that asks is called the client (usually your browser). The computer that answers is called the server.

What happens when you visit a page

When you type an address and press Enter, a lot happens in under a second. Here's the whole trip, in order:

1. You type a URL — like google.com — and hit Enter. That's you placing an order.
2. DNS looks up the address. Computers don't find each other by name; they use numbers called IP addresses. DNS is the internet's phone book — it turns google.com into a number.
3. Your request travels across the internet to the right server.
4. The server responds — it sends back the page (some HTML, styles, and code).
5. Your browser renders it — it reads that code and paints the page you see.

All of that, every single time you click a link. Now you know what "loading…" really means.

The words you'll keep hearing

You don't need to memorize these — read them once and come back when one trips you up.

URL

The full address of a page, like https://cadenceadvisers.com/learn. "Link" and "URL" mean the same thing.

domain

The human-friendly name part of a URL — cadenceadvisers.com. You buy one to have your own web address.

DNS

The internet's phone book — turns a domain name into the number (IP) where the server actually lives.

IP address

The numeric address of a computer on the internet, like 142.250.72.14.

HTTP / HTTPS

The language browsers and servers speak. The S means secure (encrypted) — always prefer it.

request / response

The ask and the answer. You request a page; the server responds with it.

status code

A number the server sends with its answer. 200 = OK, 404 = not found, 500 = the server broke. You'll see these a lot.

server / hosting

A server is a computer that answers requests. "Hosting" is renting space on one so your site is online (Cloudflare does this for free).

API

A doorway one program opens so other programs can ask it for data. More on this below.

JSON

A simple, text-based way to package data that programs pass around. Looks like a tidy list of "name": value pairs.

Frontend vs backend

You'll hear these constantly. They just describe where code runs.

A finished app usually has both: a frontend the user clicks, talking to a backend that remembers things. Your Supabase database (from Module 01) is a backend you didn't have to build.

APIs — how programs ask each other for things

An API is just a doorway a program opens so other programs can ask it for data or actions — the same request/response idea, but computer-to-computer instead of you-to-website.

Say you want today's weather in your app. You don't measure it yourself — you ask a weather API: "what's the weather in Boston?" It responds with data (as JSON), and your app shows it. That's it.

{
  "city": "Boston",
  "temperature": 72,
  "conditions": "sunny"
}

Most of the interesting things you'll build — maps, payments, sign-in, AI — work by calling someone's API. (And remember Module 11: an API usually needs a key, which goes in Doppler.)

What this means for you

You now have the map. When you build a web page, you're writing the frontend a browser will render. When you save data, you're using a backend. When you pull in maps or weather or payments, you're calling an API. And it's all just requests and responses — computers asking and answering.