Chapter 1 · Foundations

How Software Talks

Before touching a line of JavaScript, you need a mental map of the pieces you'll be wiring together: a client, a server, and the language they speak to each other. Everything in the rest of this course — the framework code, the database, the real-time updates — is a more sophisticated version of the same three ideas.

The client/server model #

Almost every web application you'll build has two halves that run in different places, at different times, written (often) in different styles:

A client — typically a web browser running your JavaScript, asking for things.
A server — a long-running program that listens for requests and answers them.

The client never reaches directly into the server's memory or its database. It can only ask, over the network, using an agreed-upon protocol. That protocol, for the vast majority of the web, is HTTP.

A request/response round trip. The client always speaks first.

Key idea

HTTP is stateless and request-initiated. The server cannot push information to the client out of nowhere — the client has to ask first. Later, in Chapter 11, you'll see how servers work around this to send live updates anyway.

Anatomy of a request and response #

A request has a method, a path, optional headers, and an optional body. A response has a status code, headers, and usually a body. In modern apps that body is almost always JSON.

a request, in plain text

GET /api/todos/42 HTTP/1.1
Host: example.local
Accept: application/json

the response

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

{ "id": 42, "title": "Write chapter 1", "done": false }

The method tells the server what kind of thing you're doing:

Method	Meaning	Typical use
`GET`	Read	Fetch a todo list
`POST`	Create	Add a new todo
`PATCH`/`PUT`	Update	Mark a todo done
`DELETE`	Remove	Delete a todo

A server that organizes its endpoints around resources and these methods is following a REST-ish convention. It's not a strict standard, just a shared habit that makes APIs predictable.

Terminals, processes, and the command line #

You'll spend a lot of this course typing into a terminal. A terminal is just a text interface to your operating system's shell; the shell starts processes — running programs — and shows you their output. When you later run something like:

node server.js

you are starting a process that keeps running, listening for HTTP requests, until you stop it. This is exactly the "server" box in the diagram above. Contrast that with a script that runs once and exits — a CLI tool like a build step or a test runner.

Try it

Open any terminal and run curl -i https://drlongnecker.com (or paste that URL into a browser and view the page source). You're watching the exact request/response cycle from the diagram above, just with HTML in the body instead of JSON.

Why this matters for everything that follows #

Every technology in this course sits on one side of the client/server line or spans it:

Client side

JavaScript/TypeScript running in the browser, rendering UI, reacting to clicks, asking the server for data. Covered in Chapters 2, 3, and 6–8.

Server side

A long-running Node.js process that receives requests, talks to a database, and sends responses. Covered in Chapters 9–12 and 16.

Spanning both

Build tooling, type systems, plugin architecture, and design systems all shape how the two sides are written and how consistently they cooperate. Chapters 4, 5, 13–15.

Keep this triangle — client, server, protocol — in your head. When something in a later chapter feels overwhelming, ask "is this client code, server code, or the wiring between them?" It will almost always be one of those three.