Lesson 1: How the Web Reaches Your App

Why this matters

In Part 1 your app lived in a GitHub repository. In Part 2 you will put it online so that anyone can open it. First you need a picture of what happens when someone visits a web address. Once you have that picture, later steps make sense: hosting, databases, sign-in and keeping keys safe. It also tells you where security problems tend to appear.

This lesson follows one visit to a small example app, Snack Tracker, at the made-up address snacktracker.example. You will learn five terms and then use them on your own app.

The five terms in plain words

1. Domain: the name people type to find a site, such as mozilla.org or snacktracker.example. It is a readable name for a computer that has a hard-to-remember number.
2. IP address: that number. Every computer on the internet has one, for example 192.0.2.172. Computers reach each other by number, not by name.
3. DNS (Domain Name System): the internet's shared lookup system. It matches domain names to IP addresses. Finding the number for a name is called a DNS lookup. Think of the contacts list on your phone: you tap a name and the phone dials the number stored with it.
4. HTTPS: the secure way a browser and a website talk. It uses an encryption method called TLS, which does two jobs:
   • It encrypts the traffic, so anyone in between, such as public Wi-Fi, cannot read or change it.
   • It proves the site's identity with a digital certificate, so the browser knows it reached the real snacktracker.example and not an impostor. The padlock or site-information icon in the address bar shows that the connection is HTTPS.
5. Front-end code and server-side code:
   • Front-end (client-side) code runs in the visitor's browser. It is made of HTML (structure), CSS (style) and JavaScript (behaviour). It draws buttons and layouts and reacts to clicks. It can also check a form before sending it, as a convenience. The browser downloads this code to run it, so anyone can open it and read it.
   • Server-side code runs on a computer you control, called a server. Visitors never see the code itself, only the answers it sends back. It decides what data to send, checks what users submit, and talks to databases.

Follow one visit, step by step

A visitor types snacktracker.example and presses Enter. This is what happens:

1. Type the address. The browser now has a domain name but no number.
2. DNS lookup. The browser asks DNS for the IP address of snacktracker.example. DNS replies with something like 192.0.2.172. Browsers and devices keep answers for a while, so repeat visits skip this step.
3. Secure connection (HTTPS). The browser connects to that IP address. The server shows its certificate, the browser checks it, and both sides set up encryption.
4. Request the page. Over the secure connection, the browser asks for the page.
5. Receive the front-end files. The server sends back HTML, CSS and JavaScript.
6. Run the front end. The browser builds the page on screen and starts the JavaScript. Snack Tracker's buttons and list are now visible.
7. Ask the server-side code. The visitor taps Save snack. The JavaScript sends a new request to the server-side code. That code checks the data, saves it, and replies.
8. Show the result. The browser updates the page with the reply. Steps 7 and 8 repeat every time the app needs data.

Note, dated October 2026: since Chrome 154, Chrome warns visitors by default before it opens a public site that has no HTTPS. Other browsers may handle this differently, and the behaviour may change again. Plan for HTTPS from day one.

Task 1: Draw the path

Do this now, on paper or in any drawing tool:

1. Draw three boxes: Browser, DNS, Server.
2. Draw an arrow from Browser to DNS labelled "What is the IP for my domain?" and one back labelled "192.0.2.172".
3. Draw an arrow from Browser to Server labelled "HTTPS: secure connection + request page".
4. Draw an arrow back labelled "HTML, CSS, JavaScript".
5. Inside the Browser box, write "front-end code runs here".
6. Inside the Server box, write "server-side code runs here".
7. Add one more pair of arrows between Browser and Server labelled "Save snack" and "Saved!".

Check it: you should be able to point at every arrow and name its step from the list above.

Task 2: Sort your own app's features

Open the app you built in Part 1 and list five things it does. Then put each one in a column using these questions:

• Browser (front end) if it only changes what is on screen. Examples: a dark-mode toggle, an animation, opening a menu, showing a warning that a form field is empty.
• Server (server-side) if it must be trusted, kept private, or shared between users. Examples: saving data everyone can see, checking a password, using a secret key, enforcing a limit on how often someone can do something.

Ask yourself: "Would it be a problem if a visitor could read or change this?" If yes, it belongs on the server. The browser runs code on the visitor's machine and anyone can inspect it, so it can never keep a secret.

If you are unsure where a feature runs, ask your AI assistant: "For each feature in this app, tell me whether its code runs in the browser or on a server, and point to the file." Then open the files it names and check the answer yourself.

Key takeaways

• A domain is a readable name. DNS turns it into an IP address the computer can use.
• HTTPS encrypts the connection and uses a certificate to prove the site is genuine.
• One visit goes: type the address, DNS lookup, secure connection, request, front-end files arrive, browser runs them, and server-side code answers further requests.
• Front-end code runs in the browser, and anyone can read it.
• Server-side code runs on a computer you control. Anything secret, trusted or shared belongs there.