Part 0.2 — How the Web Works: Requests, Responses, and the Stack

Before you build, deploy, or debug, you need to understand what actually happens when someone opens your app.
Every click, every fetch, every response traces back to one fundamental pattern: a client sending a request, and a server sending back a response.

Let’s pull the curtain back on that interaction.

1. The Journey of a Web Request

When you type a URL like https://app.example.com/api/users into your browser, here’s the high-level sequence:

1. DNS Lookup — Your browser translates the domain name into an IP address.

2. TCP Connection — The browser opens a connection to the server.

3. TLS Handshake (HTTPS) — Encryption starts if using HTTPS (always should).

4. HTTP Request — The browser sends a structured message like:

   GET /api/users HTTP/1.1
   Host: app.example.com
   Accept: application/json

5. Server Processing — The backend (NestJS in our case) parses the request, talks to PostgreSQL through Prisma, and prepares a response.

6. HTTP Response — The server returns data, typically in JSON:

   HTTP/1.1 200 OK
   Content-Type: application/json
   
   [{ "id": 1, "name": "Ava" }]

7. Browser Rendering — The frontend (React) reads the JSON and updates the UI.

That’s it: seven steps every web interaction follows.

2. The Client–Server Model

Your React frontend is the client — it runs in the user’s browser, makes requests, and renders responses.
Your NestJS backend is the server — it runs on a remote machine, handles requests, applies business logic, and queries PostgreSQL.

Here’s the mental model:

React (frontend)  →  REST API (NestJS)  →  Prisma ORM  →  PostgreSQL
     ↑                    ↓
   Fetch()              Response

Every endpoint is a small contract between these two halves — for example, /api/users might support:

3. Understanding REST: Simplicity with Structure

REST (Representational State Transfer) isn’t a library or protocol; it’s a style of designing APIs.
Its rules are simple but powerful:

• Resources are nouns: /users, /posts/12/comments

• Methods express intent: GET, POST, PUT, DELETE

• Statelessness: Every request must include all data needed to process it.

• Use of standard HTTP status codes: 200 OK, 404 Not Found, 500 Internal Server Error

Example — fetching users from your backend in React:

// src/hooks/useUsers.ts
export async function useUsers() {
  const response = await fetch("/api/users");
  if (!response.ok) throw new Error("Failed to load users");
  return response.json() as Promise<{ id: number; name: string }[]>;
}

This fetch call sends a GET request to your backend.
Later, when we build the NestJS side, you’ll see the matching controller method that returns the same JSON structure.

4. Inside an HTTP Request: Anatomy of a Message

Every HTTP message has three main parts:

1. Start line – Method and path:
   GET /api/users HTTP/1.1

2. Headers – Metadata about the request:

   Host: example.com
   Authorization: Bearer <token>
   Accept: application/json

3. Body (optional) – JSON data in POST or PUT:

   {
     "name": "Ava"
   }

The server responds similarly — with a status code, headers, and body.

5. From REST Call to Database Query

Let’s trace a typical flow end to end — what happens when React fetches /api/users.

1. React sends a GET /api/users request.

2. NestJS controller handles it in a class method like:

   @Get('users')
   async getUsers() {
     return this.usersService.findAll();
   }

3. Service layer talks to Prisma:

   async findAll() {
     return this.prisma.user.findMany();
   }

4. Prisma runs a SQL query against PostgreSQL:
   SELECT * FROM "User";

5. The server wraps the result in JSON and returns it.

6. The frontend re-renders with the new data.

That’s your first full-stack flow — React → REST → Prisma → PostgreSQL → React.

6. Why REST Still Matters

You might hear that “REST is old” or “GraphQL is the future.”
In reality, REST remains the backbone of most production APIs — especially when combined with strong validation, caching, and predictable URLs.
REST is simpler to monitor, scale, and document. That’s why this course stays grounded in it.

7. Debugging and Observability

Learn to inspect your requests — this habit saves hours.

• In the browser DevTools → Network tab, check every request’s headers and response.

• Use tools like curl or HTTPie for CLI debugging:

  curl -i http://localhost:3000/api/users

• Log incoming requests in NestJS for early feedback:

  app.useLogger(['log', 'error', 'warn', 'debug', 'verbose']);

8. The Real Goal

You now understand the invisible web conversations your app depends on.
The next time you build a React component or define a NestJS controller, you’ll see the request path and the data flow through it.

In the next sub-post, we’ll jump into Modern JavaScript & TypeScript Essentials — the language foundation that powers every line of our stack.