Phase 2: Web Fundamentals

Welcome to Phase 2. In our previous phase, we learned how to write logic and manipulate data within a single machine using Programming Fundamentals. Now, we must expand our horizons. Modern applications don't live in isolation—they communicate across vast networks of fiber-optic cables spanning the globe.

To become a proficient Web or Backend Architect, you must intimately understand the ecosystem in which your code runs: The Web. In this comprehensive guide, we will unpack protocols, API architectures, real-time communication, and the infrastructure that keeps the internet alive.

Chapter 1: The Backbone — HTTP and HTTPS

At its core, the web is a massive conversation between Clients (browsers, mobile apps) and Servers (computers sitting in a data center). This conversation happens via HTTP (Hypertext Transfer Protocol).

The Request-Response Cycle

HTTP is a request-response protocol. A client asks for something (a Request), and the server replies (a Response). HTTP is fundamentally stateless—every request is independent, and the server retains no memory of previous requests (unless we explicitly implement state management, which we'll cover later).

Anatomy of an HTTP Request

When you type a URL or make a fetch() call, your browser constructs an HTTP Request that looks somewhat like this plain text:

GET /api/users/123 HTTP/1.1
Host: www.example.com
Authorization: Bearer my_secret_token
Accept: application/json

1. The Method (Verb): Tells the server what we want to do.

• GET: Please give me some data. (Read-only, no side effects).
• POST: Here is some new data, please save it. (Creates a new resource).
• PUT: Here is a completely updated version of an existing resource. (Replaces entirely).
• PATCH: Here are a few partial updates to an existing resource.
• DELETE: Please remove this resource.

2. The URL/URI: The address of the resource (e.g., /api/users/123).

3. Headers: Metadata about the request. For example, Content-Type tells the server what format the body is in (e.g., JSON, XML), and Authorization carries credentials.

4. The Body: The actual data payload (used mainly in POST, PUT, and PATCH).

Anatomy of an HTTP Response

The server processes the request and sends back a response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 42

{
  "id": 123,
  "name": "Alice"
}

The Status Code: A 3-digit number indicating the result.

• 2xx Success: Everything went well. (200 OK, 201 Created).
• 3xx Redirection: You need to go somewhere else. (301 Moved Permanently).
• 4xx Client Error: You messed up. (400 Bad Request, 401 Unauthorized, 404 Not Found).
• 5xx Server Error: The server messed up. (500 Internal Server Error).

HTTPS and Encryption

HTTP transmits data in plain text. If an attacker intercepts your traffic at a coffee shop Wi-Fi network, they can read your passwords. HTTPS (HTTP Secure) solves this by encrypting the HTTP payload using TLS (Transport Layer Security). Before any HTTP data is sent, the client and server perform a "TLS Handshake" using asymmetric cryptography (public/private keys) to agree on a secure, symmetric session key.

Chapter 2: API Architectures

An API (Application Programming Interface) is a set of rules defining how two pieces of software can communicate. Over the years, several paradigms have emerged.

1. REST (Representational State Transfer)

REST is the undisputed king of web APIs. It relies heavily on standard HTTP conventions. In REST, everything is a Resource, identified by a URL. You manipulate these resources using standard HTTP verbs.

• Analogy: A well-organized library. Each book has a specific shelf location (URL). You can borrow (GET), donate a new book (POST), or burn a book (DELETE).

RESTful Endpoint Examples:

• GET /articles -> Fetch all articles.
• POST /articles -> Create a new article.
• GET /articles/45 -> Fetch article #45.
• PUT /articles/45 -> Update article #45.

2. GraphQL

Created by Facebook, GraphQL was designed to solve REST's limitations: Over-fetching (getting more data than you need) and Under-fetching (needing to make multiple requests to different endpoints to assemble a view).

In GraphQL, there is only one endpoint (usually POST /graphql). The client sends a specific query detailing exactly the shape of the data it wants, and the server returns exactly that—nothing more, nothing less.

• Analogy: A bespoke tailor. Instead of buying off-the-rack clothes (REST), you give the tailor precise measurements, and they craft an outfit specifically for you.

# GraphQL Query
query {
  user(id: "123") {
    name
    email
    friends(limit: 2) {
      name
    }
  }
}

3. gRPC

Developed by Google, gRPC uses HTTP/2 and Protocol Buffers (Protobufs) instead of JSON. Protobufs serialize data into a dense, highly efficient binary format. gRPC is incredibly fast and is typically used for internal Microservice-to-Microservice communication, rather than public-facing web APIs.

Chapter 3: Real-Time Communication

HTTP is strictly Request-Response. The server cannot send data to the client unless the client asks first. But what about a chat application or a live stock ticker?

1. Polling and Long-Polling

• Short Polling: The client repeatedly asks the server every 5 seconds, "Do you have new messages?" This is inefficient and wastes resources.
• Long Polling: The client asks the server for messages. If the server has none, it holds the connection open until a message arrives, then responds.

2. WebSockets

WebSockets provide a full-duplex, persistent, bidirectional connection over a single TCP connection. Once a WebSocket connection is established (via an HTTP Upgrade request), both the client and the server can push data to each other instantly without the overhead of HTTP headers.

• Analogy: HTTP is like sending letters through the mail. WebSockets are like a phone call; once you connect, you can both talk simultaneously.

// WebSockets in the Browser
const socket = new WebSocket('wss://chat.example.com');

socket.onopen = () => {
  console.log('Connected to chat server!');
  socket.send(JSON.stringify({ type: "join", room: "general" }));
};

socket.onmessage = (event) => {
  const message = JSON.parse(event.data);
  console.log('New message received:', message);
};

3. Server-Sent Events (SSE)

SSE is a unidirectional mechanism. The client establishes a connection, and the server streams data down to the client over time. It operates over standard HTTP. It's perfect for things like a live Twitter feed or news updates where the client only needs to receive, not send.

Chapter 4: State Management and Sessions

Because HTTP is stateless, how does Amazon remember what's in your cart as you navigate between pages?

Cookies

A Cookie is a small piece of data (up to 4KB) that the server sends to the user's browser via the Set-Cookie HTTP header. The critical feature of cookies is that the browser automatically attaches the cookie to every subsequent request made to that specific domain.

Sessions

1. The user logs in with a username/password.
2. The server verifies the credentials and creates a "Session Object" in its memory (or a fast database like Redis).
3. The server generates a random, unique Session ID (e.g., abc-123).
4. The server sends this Session ID to the browser in a Cookie.
5. On the next request, the browser automatically sends the Cookie. The server reads abc-123, looks it up in Redis, finds the corresponding Session Object, and knows the user is authenticated.

(Note: We will explore token-based authentication like JWT deeply in the Phase 3 Security module).

Chapter 5: Web Infrastructure 101

When you type https://www.google.com and press Enter, an incredible journey happens in milliseconds.

1. DNS (Domain Name System)

Computers communicate using IP Addresses (like 142.250.190.46), but humans prefer names (google.com). DNS is the internet's phonebook. When you press enter, your browser first queries a DNS server: "What is the IP address for google.com?" The DNS server replies with the IP.

2. CDNs (Content Delivery Networks)

If your server is in New York, a user in Tokyo will experience high latency due to the physical distance the signal must travel. A CDN is a global network of servers. You upload your static assets (images, CSS, JavaScript, videos) to the CDN. The CDN copies these files to "edge servers" all over the world. When the user in Tokyo requests an image, they download it from a CDN node in Tokyo, drastically reducing load times.

3. Load Balancers and Reverse Proxies

When your application gets popular, one server won't be enough. You might have 10 servers running your backend. A Reverse Proxy / Load Balancer (like Nginx, HAProxy, or AWS ALB) sits in front of your 10 servers. The client sends the HTTP request to the Load Balancer. The Load Balancer looks at its pool of 10 servers, finds one that isn't busy, and forwards the request to it.

Load balancers also handle:

• SSL Termination: Decrypting HTTPS traffic so your backend servers don't have to waste CPU cycles doing it.
• Caching: Serving frequently requested data instantly.
• Health Checks: Automatically removing broken backend servers from the pool.

Conclusion

You now understand the intricate dance of protocols, APIs, and infrastructure that makes the modern web function. You've looked under the hood of HTTP, explored real-time sockets, and mapped out the physical infrastructure of global networks.

In Phase 3: Authentication & Security, we will look at the dark side of the web. We will learn how to defend our applications against malicious actors, securely handle user identities, and implement bulletproof authentication mechanisms.