Phase 0 Understand how websites work
Before writing code, understand these concepts.
Learn:
What is a website?
Browser vs server
Frontend vs backend
Database
HTTP
Request
Response
URL
Domain
IP address
HTTP vs HTTPS
GET vs POST
Client-server architecture
You should be able to understand:
You
↓
Chrome
↓
Internet
↓
Server
↓
Application
↓
Database
↓
Server
↓
Chrome
↓
You

Practice
Open browser DevTools → Network tab.
Visit a website and observe:
Request
Response
Status Code
Method
URL
Headers
Response
Don't worry about understanding everything yet.

Phase 0 — How Websites Work

[!NOTE]
You don't need to memorize any of this. Read it, understand the big picture, and come back as a reference. Everything will become clearer once you start writing code.

1. What is a Website?

A website is a collection of files (text, images, code) stored on a computer somewhere in the world. When you "visit" a website, your browser downloads those files and displays them on your screen.

Think of it like a restaurant:

Key takeaway: A website isn't a single magical thing — it's files on someone else's computer, delivered to your computer over the internet.

2. Browser vs Server

Browser (Client)

The browser is the app on your device — Chrome, Firefox, Edge, Safari. Its job is to:

1. Send requests — "Hey, give me google.com"
2. Receive files — HTML, CSS, JavaScript, images
3. Render (display) those files as a visual webpage

The browser is also called the client — the one asking for something.

Server

A server is a computer (usually in a data center) that is always on and always connected to the internet, waiting to respond to requests.

Its job is to:

1. Listen for incoming requests
2. Process the request (look up data, run logic)
3. Send back a response (usually an HTML page, JSON data, or files)

Real-world analogy:

• Browser = You calling a pizza shop on the phone
• Server = The pizza shop answering the phone, making your pizza, and delivering it

[!TIP]
Your own laptop can act as a server! When you learn backend development, you'll run a "local server" on your machine. It's just a program that listens and responds.

3. Frontend vs Backend

Frontend (Client-Side)

Everything the user sees and interacts with in the browser:

• The layout of the page (HTML)
• The colors, fonts, spacing (CSS)
• Buttons that do things, animations, pop-ups (JavaScript)

Technologies: HTML, CSS, JavaScript, React, Angular, Vue

Analogy: The dining area of a restaurant — what customers see.

Backend (Server-Side)

Everything that happens behind the scenes on the server:

• Processing login credentials
• Fetching your order history from a database
• Sending emails
• Payment processing

Technologies: Node.js, Python (Django/Flask), Java, Go, PHP, Ruby

Analogy: The kitchen of a restaurant — customers can't see it, but that's where the real work happens.

How They Connect

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│   FRONTEND   │  ────►  │   BACKEND    │  ────►  │   DATABASE   │
│  (Browser)   │  ◄────  │   (Server)   │  ◄────  │  (Storage)   │
│              │         │              │         │              │
│ HTML/CSS/JS  │         │ Node/Python  │         │ MySQL/Mongo  │
│ What you SEE │         │ Logic/Rules  │         │ Where data   │
│              │         │              │         │ LIVES        │
└──────────────┘         └──────────────┘         └──────────────┘

4. Database

A database is organized storage for data. Think of it as a super-powered Excel spreadsheet.

When you sign up on Instagram:

• Your username, email, password → stored in a database
• Your posts, likes, followers → stored in a database
• When you log in → the server reads from the database to check your password

Types of Databases

Example — A "users" table in SQL:

[!NOTE]
You don't need to learn databases right now. Just understand: data has to live somewhere, and that somewhere is the database.

5. HTTP — The Language of the Web

HTTP = Hyper Text Transfer Protocol

It's the set of rules that browsers and servers use to talk to each other. Think of it as the language the waiter speaks.

Every time you visit a website, your browser speaks HTTP to the server.

6. Request

A request is what your browser sends to the server when you want something.

When you type https://www.google.com and hit Enter, your browser sends an HTTP request that looks roughly like this:

GET / HTTP/1.1
Host: www.google.com
User-Agent: Chrome/120
Accept: text/html

Breaking it down:

7. Response

A response is what the server sends back to your browser.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 14523

<!DOCTYPE html>
<html>
  <head><title>Google</title></head>
  <body>... the Google homepage ...</body>
</html>

Breaking it down:

Common Status Codes

8. URL — The Address of a Webpage

URL = Uniform Resource Locator — it's the address that tells the browser exactly where to go.

https://www.example.com:443/products/shoes?color=red&size=10#reviews
  │        │              │       │              │              │
  │        │              │       │              │              └─ Fragment (scroll to this section)
  │        │              │       │              └─ Query params (filters/search)
  │        │              │       └─ Path (which page)
  │        │              └─ Port (which door on the server)
  │        └─ Domain (which server)
  └─ Protocol (how to communicate)

9. Domain & IP Address

IP Address

Every computer on the internet has a unique IP address — a number like 142.250.190.46. This is the real address of a server.

Domain Name

Since nobody wants to remember 142.250.190.46, we use domain names like google.com as human-friendly aliases.

DNS — The Phonebook of the Internet

DNS (Domain Name System) translates domain names to IP addresses:

You type: google.com
     ↓
DNS lookup: "google.com → 142.250.190.46"
     ↓
Browser connects to: 142.250.190.46

Analogy:

• IP address = A house's GPS coordinates (27.1751, 78.0421)
• Domain name = The house's street address ("Taj Mahal, Agra")
• DNS = Google Maps converting the address to coordinates

10. HTTP vs HTTPS

Why it matters:
If you log into a website over HTTP, someone on the same Wi-Fi can literally read your password. With HTTPS, everything is encrypted.

[!CAUTION]
Never enter passwords or credit cards on a site that shows http:// (no 's'). Modern browsers show a "Not Secure" warning for these sites.

11. GET vs POST

These are the two most common HTTP methods — they tell the server what kind of action you want.

GET — "Give me something"

• Purpose: Read / retrieve data
• When it happens: Loading a page, searching, clicking a link
• Data location: In the URL (visible) → ?q=cats&page=2
• Safe to repeat? Yes — nothing changes on the server

Examples:

• Visiting google.com → GET
• Searching google.com/search?q=cats → GET
• Loading your Twitter feed → GET

POST — "Here, take this data"

• Purpose: Send / submit data to the server
• When it happens: Submitting a form, logging in, uploading a file
• Data location: In the request body (hidden from URL)
• Safe to repeat? No — might create duplicates (e.g., double purchase)

Examples:

• Submitting a signup form → POST
• Posting a tweet → POST
• Uploading a photo → POST

Comparison Table

[!TIP]
There are other methods too — PUT (update), DELETE (remove), PATCH (partial update). You'll learn these when building APIs. For now, just know GET and POST.

12. Client-Server Architecture

This is the fundamental pattern of how the web works:

  ┌─────────┐                              ┌─────────┐
  │ CLIENT  │  ──── Request ──────────►    │ SERVER  │
  │(Browser)│  ◄─── Response ────────────  │         │
  └─────────┘                              └─────────┘

1. The client (your browser) initiates communication by sending a request
2. The server processes the request and sends back a response
3. The server never contacts you first (in basic HTTP) — it only responds

This is like a restaurant:

• You (client) call the waiter and place an order (request)
• The kitchen (server) prepares the food and the waiter brings it back (response)
• The kitchen never randomly walks up to your table with food you didn't order

13. The Full Journey — Step by Step

This is the flow you need to understand. Let's trace what happens when you open Instagram:

 YOU                    "I want to see Instagram"
  ↓
 CHROME (Browser)       Types instagram.com, hits Enter
  ↓
 DNS                    Converts "instagram.com" → 157.240.1.174
  ↓
 INTERNET               Your request travels through cables/wifi
  ↓
 SERVER                  Instagram's server receives your request
  ↓
 APPLICATION             Instagram's code runs:
                         "This user is logged in, fetch their feed"
  ↓
 DATABASE                Queries: "Get latest 20 posts from
                         people this user follows"
  ↓
 APPLICATION             Formats the data into an HTML page / JSON
  ↓
 SERVER                  Sends the response back
  ↓
 INTERNET                Response travels back through cables/wifi
  ↓
 CHROME (Browser)        Receives HTML/CSS/JS, renders the page
  ↓
 YOU                     See your Instagram feed! 🎉

Timing

This entire journey happens in ~200-500 milliseconds (less than half a second). That's how fast the internet is.

14. 🧪 Practice Exercise — Using Browser DevTools

This is your first hands-on practice. No coding needed — just observation.

Step 1: Open DevTools

1. Open Chrome (or any browser)
2. Press F12 or Ctrl + Shift + I (Windows) / Cmd + Option + I (Mac)
3. Click the "Network" tab at the top

Step 2: Visit a Website

1. Make sure the Network tab is open and recording (there should be a red circle ● at the top-left)
2. Type https://httpbin.org/get in the address bar and hit Enter
3. You'll see lines appear in the Network tab — each line is one request

Step 3: Observe the First Request

Click on the first item in the list (usually named get).

You'll see panels showing:

✅ What to look for:

Step 4: Try a POST Request

1. Open a new tab
2. Open DevTools (F12) → Network tab
3. Paste this into the address bar: https://httpbin.org/post
4. You'll get an error (because browsers send GET by default) — that's expected!
5. This tells you: the server only accepts POST at this URL, but your browser sent GET

Step 5: Observe Multiple Requests

1. Go to https://www.google.com with DevTools Network tab open
2. Notice there are dozens of requests — not just one!
3. Each image, CSS file, JavaScript file, and font is a separate request

[!IMPORTANT]
A single webpage often makes 30-100+ HTTP requests to load completely. The HTML is just the skeleton — it then triggers requests for all the images, styles, and scripts.

Step 6: Status Codes in Action

Try visiting these URLs and check the status code in DevTools:

• https://httpbin.org/status/200 → Should show 200 (OK)
• https://httpbin.org/status/404 → Should show 404 (Not Found)
• https://httpbin.org/status/500 → Should show 500 (Server Error)

15. Summary Cheat Sheet

✅ Phase 0 Checklist

Before moving to Phase 1, make sure you can answer:

• [ ] What happens when I type a URL and press Enter?
• [ ] What's the difference between frontend and backend?
• [ ] What does a database do?
• [ ] What's a request? What's a response?
• [ ] What's the difference between GET and POST?
• [ ] What does a 404 error mean? What about 500?
• [ ] Why is HTTPS better than HTTP?
• [ ] I've opened DevTools and seen real requests/responses

[!TIP]
You do NOT need to understand everything perfectly. If you can explain the restaurant analogy to someone — you're ready for Phase 1. Understanding deepens as you build things.