Web Architecture and Communication

TL;DR

Web architecture describes how different parts of a website (like servers and browsers) are organized to work together. Communication is how these parts talk to each other, primarily using the HTTP protocol. Understanding these helps you build efficient, reliable websites by seeing the bigger picture.

1. The Mental Model

Think of a website like a restaurant. You (the client) order food from a waiter (the browser), who sends your order to the kitchen (the server). The kitchen prepares it and sends it back to you via the waiter.

2. The Core Material

Web architecture essentially defines the components involved in serving web pages and how they interact. At its core, it's about clients (your browser) making requests to servers (where the website files live) and servers sending back responses.

Client-Server Model

Photo by panumas nikhomkhai on Pexels

This is the fundamental interaction.
- Client: Usually your web browser (like Chrome, Firefox, Safari). It initiates requests for resources (HTML files, images, CSS, JavaScript).
- Server: A computer program that waits for client requests. When it receives one, it processes it and sends back the requested resources. It's like a digital librarian for website content.

Request-Response Cycle

This is the communication pattern.
1. You type a URL: Your browser translates this into a request.
2. DNS Lookup: The browser needs to find the server's IP address (like a street address). It asks a Domain Name System (DNS) server for this.
3. TCP Handshake: Once the IP is known, your browser and the server establish a connection using Transmission Control Protocol (TCP), ensuring reliable data transfer.
4. HTTP Request: Your browser sends an HTTP request to the server, asking for a specific file or resource. This request includes details like the method (GET, POST), headers (browser type), and sometimes a body (data for POST requests).
5. Server Processing: The server receives the request, finds the requested resource, and prepares a response.
6. HTTP Response: The server sends back an HTTP response. This includes a status code (e.g., 200 OK, 404 Not Found), headers (content type), and the actual data (HTML, image, etc.).
7. Browser Rendering: Your browser receives the response, interprets the HTML, CSS, and JavaScript, and displays the web page for you.

HTTP (Hypertext Transfer Protocol)

Photo by Miguel Á. Padriñán on Pexels

HTTP is the language browsers and servers speak. It's stateless, meaning each request/response pair is independent; the server doesn't remember previous interactions without extra help (like cookies).

Common HTTP methods:
- GET: Request data from a specified resource (e.g., loading a webpage).
- POST: Send data to a server to create or update a resource (e.g., submitting a form).
- PUT: Update an existing resource or create one if it doesn't exist.
- DELETE: Delete a specified resource.

HTTP status codes tell you the outcome of a request:
- 2xx Success:
- 200 OK: Request succeeded.
- 201 Created: Resource successfully created.
- 3xx Redirection:
- 301 Moved Permanently: Resource moved to a new URL.
- 4xx Client Error:
- 400 Bad Request: Server couldn't understand the request.
- 401 Unauthorized: Authentication required.
- 403 Forbidden: Server understood, but refuses to authorize.
- 404 Not Found: Resource not found on the server.
- 5xx Server Error:
- 500 Internal Server Error: Generic server error.

Here's a diagram illustrating the core request-response flow:

graph TD
    A["You (User)"] --> B["Enter URL/Click Link"];
    B --> C["Browser"];
    C --> D["DNS Resolver (Finds IP)"];
    D --> E["Web Server (IP Address)"];
    C -- HTTP GET Request --> E;
    E -- HTTP Response (HTML, CSS, JS) --> C;
    C --> F["Render Page"];
    F --> A;

Other Components

Photo by Vít Staniček on Pexels

• Load Balancers: Distribute incoming traffic across multiple servers to prevent any single server from getting overloaded.
• Databases: Store and manage the data for dynamic websites (e.g., user profiles, product lists).
• CDNs (Content Delivery Networks): Store copies of static website files (images, CSS, JS) on servers located closer to users, speeding up load times.

3. Worked Example

Let's trace what happens when you visit https://www.example.com/about:

1. You: Type www.example.com/about into your browser and press Enter.
2. Browser:
   • Checks its cache for www.example.com's IP address. If not found, it asks a DNS resolver.
   • The DNS resolver finds the IP address, say 192.0.2.1.
   • The browser then opens a TCP connection to 192.0.2.1 on port 443 (for HTTPS).
   • It sends an HTTPS GET request:
     http GET /about HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Connection: keep-alive

3. Server (www.example.com):

   • Receives the GET request for /about.
   • Looks for the /about page (e.g., about.html or generates it dynamically from a database).
   • Prepares an HTTP response.
     ```http
     HTTP/1.1 200 OK
     Date: Mon, 29 Jul 2024 10:00:00 GMT
     Server: Apache/2.4.56
     Content-Type: text/html; charset=UTF-8
     Content-Length: 1234
     Connection: keep-alive

   <!DOCTYPE html>
   
   
   
   

   Our Story

   
   

   This is the about page content.

   
   
   
   ```
   4. Browser:
   * Receives the 200 OK status code and the HTML content.
   * Parses the HTML, CSS, and JavaScript.
   * Displays "Our Story" and "This is the about page content." on your screen.

4. Key Takeaways

• Web architecture describes the organization of components like clients, servers, and databases.
• The client-server model is foundational: your browser requests, a server responds.
• HTTP is the primary protocol for communication, defining how requests and responses are structured.
• HTTP methods (GET, POST) specify the action, and status codes (200, 404, 500) indicate the outcome.
• The request-response cycle involves DNS lookup, TCP connection, HTTP request, server processing, and HTTP response.
• CDNs and load balancers are common architectural components that improve performance and reliability.

Common mistakes to avoid:
- Confusing client-side (browser) issues with server-side problems.
- Ignoring HTTP status codes; they provide crucial debugging information.
- Not understanding that HTTP is stateless; subsequent requests don't inherently remember previous ones.
- Thinking www.example.com is just one physical server; it's often a complex system of many components.

5. Now Try It

Open your browser's developer tools (usually F12 or right-click -> Inspect Element, then go to the "Network" tab). Navigate to any website you frequent. Observe the network requests made as the page loads. Look for GET requests for HTML, CSS, JavaScript, and images. Pay attention to the HTTP status codes received for each request. Try to identify at least one 200 OK and one other status code (e.g., 304 Not Modified if the browser already has a cached version, or even a 404 Not Found if a resource fails to load). Success is being able to describe what happened for at least three different network requests.