05 · Node.js & Fastify — JavaScript leaves the browser

Until now, every line of your JavaScript has lived inside a browser tab. Phase 4 breaks it out: the same language, running directly on your computer, powering a server — a program that answers requests. Your Library app is about to get a backend.

1. Same language, different world

Node is NOT a new language. It's a different place for the language you already know to run — with different powers, because the world around the code is different:

	Browser JS (what you've done)	Node JS (Phase 4)
Started by	a <script> tag in a page	node file.js in the terminal
Can see	document, DOM, buttons, alert, prompt, localStorage	files on disk, the network, environment — no DOM at all
Output goes to	the page + DevTools console	the terminal
Who runs it	every visitor's machine	YOUR machine (or a rented server)
Still the same	variables, functions, arrays, objects, map/filter/find, arrows, JSON.stringify/parse, console.log, Dates — everything from Phase 2/3 travels with you

2. Running Node — two ways

# 1. run a file (the normal way)
node hello.js

# 2. REPL — an interactive console, like DevTools but in the terminal
node
> 2 + 2
4
> [1,2,3].map(n => n * 5)
[ 5, 10, 15 ]
> .exit

3. npm & package.json — how projects declare what they need

# inside your project folder — creates package.json (asks a few questions)
npm init

# install a package LOCALLY into this project
npm install fastify

After that, three things exist — know what each is:

Thing	What it is	Your rule
package.json	your project's identity card: name, scripts, and the dependencies list ("fastify: ^5…")	you edit this (carefully)
node_modules/	the actual downloaded code of every dependency (thousands of files)	NEVER edit — regenerable, like app.js. Delete it any time; npm install rebuilds it from package.json
package-lock.json	the exact resolved versions, so installs are identical everywhere	don't edit, don't delete — npm maintains it

4. import / export — and the crash from Phase 3, finally explained

So far your whole app is ONE file. Real projects split code into modules — files that explicitly say what they share (export) and what they borrow (import):

// books.ts — shares things
export interface Book { id: number; title: string; }
export function findBook(books: Book[], id: number) {
    return books.find(b => b.id === id);
}

// server.ts — borrows them
import { Book, findBook } from "./books.js";

5. What a server actually is

Strip the mystique: a server is a program that waits for requests and sends back responses. That's the whole job. It runs forever in a loop: listen → request arrives → build an answer → send it → listen again.

6. HTTP — the request language

Requests follow a standard: HTTP. A request names a method (what kind of action) and a path (what thing). You already built all four actions in the Library — HTTP just gives them official names:

Method	Meaning	Your Library equivalent
GET	read, change nothing	renderBooks, searchBooks, showLowStock
POST	create something new	addBook, borrowBook (creates a Loan)
PUT / PATCH	update something existing	returnBook (flips returned, copies+1)
DELETE	remove	deleteBook

The response carries a status code — a number stating how it went:

Code	Means	Your app's version of it
200 OK	worked, here's your data	a successful render
201 Created	POST succeeded, thing now exists	addBook pushing a new book
400 Bad Request	client sent nonsense	your addBook validation (isNaN → alert)
404 Not Found	no such thing	your if (!book) return; guard
500 Server Error	server itself crashed	an unhandled bug in your code

7. Fastify — your first server, ~10 lines

// server.ts — a complete working server
import Fastify from "fastify";

const app = Fastify();

app.get("/hello", () => {
    return { message: "Library server is alive" };
});

await app.listen({ port: 3000 });
console.log("Listening on http://localhost:3000");

Run it, then visit http://localhost:3000/hello in the browser — JSON appears. Read the shape: app.get(path, handler) — "when a GET request hits this path, run this function and send back what it returns." Return an object → Fastify auto-converts to JSON (JSON.stringify'd for you).

8. Routes — the server's API takes shape

Each app.get/app.post/... line is a route. The Library's backend will grow into this list — read it and notice it's exactly your function list, renamed:

GET    /books          → all books           (renderBooks' data source)
GET    /books/:id      → one book            (your find-by-id)
POST   /books          → add a book          (addBook)
DELETE /books/:id      → remove a book       (deleteBook)
POST   /loans          → borrow              (borrowBook)
PATCH  /loans/:id      → return a loan       (returnBook)

Two new pieces inside handlers:

// :id is a URL PARAMETER — /books/3 → request.params.id is "3"
app.get("/books/:id", (request) => {
    const id = Number((request.params as { id: string }).id);  // params arrive as STRINGS
    const book = books.find(b => b.id === id);
    // ...guard → 404, else return book
});

// POST bodies: the JSON the client sent, already parsed for you
app.post("/books", (request) => {
    const newBook = request.body as Book;
    // ...validate → 400, else push + return 201
});

9. The Phase 4 arc — Library grows a backend

The plan, in order — each step is a working app:

Step	What changes	What it teaches
1. Hello server	Fastify answers /hello	setup, routes, the waiting loop
2. GET /books	server owns the books array (in memory)	routes returning real data
3. Frontend fetches	index.html calls fetch("http://localhost:3000/books") instead of reading localStorage	fetch, async/await — the missing JS piece
4. Full CRUD routes	add/delete/borrow/return move server-side	POST bodies, params, status codes
5. Save to a JSON file	server writes books.json/loans.json to disk (fs)	persistence without a browser — localStorage's server cousin
6. → Phase 5	the JSON file becomes a real database	SQL — and your bookId foreign key becomes literal

10. TypeScript on the server

Same two-step you already live by, new runner: edit .ts → tsc → node server.js (instead of refresh). And here's the satisfying part: tsconfig's module: "nodenext" — the setting that CRASHED your browser app — is the correct setting now, because the output finally runs where it was designed to run: Node. Types get more valuable here too — no DevTools on a server, so the more bugs die at compile time, the better.

11. The mental model to keep

Idea	One line to remember
Node	the browser's JS engine, freed — same language, no DOM, plus files & network
npm local vs -g	commands you type → global; code you import → local
node_modules	regenerable, never edited — the app.js rule, scaled up
import/export	each file a private room; exports are what's passed through the door
Server	a program that waits: request in → response out, forever
HTTP methods	GET read · POST create · PATCH update · DELETE remove — your CRUD, officially named
Boundaries	whatever crosses one (form, URL, HTTP, storage) arrives as a string — convert at the border
The split	data lives on the server, presentation in the browser, JSON between them

---

← Prev: TypeScript  ·  Back to contents  ·  Next: SQL & Prisma →