# NodeBook Full AI Context

> Curated AI context for NodeBook, a free online technical book and paid study system for Node.js internals. This file contains short chapter summaries and product facts. It does not contain full chapter text.

Canonical site: https://www.thenodebook.com
Source manifest: digital/epub/manifest.json
Manifest generatedAt: 2026-07-13T01:48:24.396Z
Scope: one-paragraph summaries for published book entries plus current product facts.
Use the canonical chapter URLs for citation. Use /pricing for current paid product details.

## Canonical Routes

- Home: https://www.thenodebook.com
- Complete index: https://www.thenodebook.com/browse
- Study options: https://www.thenodebook.com/pricing
- Licensing: https://www.thenodebook.com/licensing
- Sitemap: https://www.thenodebook.com/sitemap.xml

## Product Facts

- Free Online Book: NodeBook is free to read online.
- NodeBook Raw Mode: $14.99/month, $71.99/year, or $99.99 lifetime. Build a zero-dependency Node.js backend framework yourself, master Node.js internals, and prove the depth through the complete practice system. Includes A complete zero-dependency backend framework build, Every current and future NodeBook volume, Light and dark PDFs plus EPUB editions, Every Runtime Lab with phases, hints, and rubrics, 100 interview questions answered at three depths, Follow-up trees, hallucination drills, and debug repos, System-design scenarios and raw-editor protocols, Account dashboard and protected re-downloads, and Every future Raw Mode update. The current lab bundle includes 8 labs, 23 challenges, and 120 phases. Use Node.js 24 or newer. No package install step is required. The project uses Node.js core modules only.

## Chapter Summaries

### Chapter 1: Node.js Architecture

#### 1.1 What Node.js Is

- URL: https://www.thenodebook.com/node-arch/what-is-nodejs
- Source: src/content/node-arch/what-is-nodejs.mdx
- Book position: Chapter 1, subchapter 1.1
- Last updated: 2026-05-14
- Tags: nodejs, v8, libuv, runtime, architecture
- Summary: What Node.js is, how V8, libuv, native bindings, and core APIs fit together, and how JavaScript reaches files, sockets, timers, and the OS.

#### 1.2 V8 JavaScript Engine in Node.js: Architecture, Tiers, Shapes, and Deoptimization

- URL: https://www.thenodebook.com/node-arch/v8-engine-intro
- Source: src/content/node-arch/v8-engine-intro.mdx
- Book position: Chapter 1, subchapter 1.2
- Last updated: 2026-05-23
- Tags: v8, jit, optimization, performance, compiler
- Summary: The V8 JavaScript engine in Node.js v24 parses JavaScript, emits Ignition bytecode, gathers runtime feedback, and moves hot functions through Sparkplug, Maglev, and TurboFan. It also owns garbage collection, object maps, inline caches, value representation, and deoptimization. Node supplies system APIs around V8, while callbacks and modules execute under V8 compiler and heap rules. Shape stability, element kinds, call-site feedback, and numeric representation decide whether hot JavaScript stays optimized or falls back to lower tiers.

#### 1.3 Node.js Event Loop Explained: Phases, Microtasks, nextTick, and setImmediate

- URL: https://www.thenodebook.com/node-arch/event-loop-intro
- Source: src/content/node-arch/event-loop-intro.mdx
- Book position: Chapter 1, subchapter 1.3
- Last updated: 2026-05-23
- Tags: event-loop, async, libuv, concurrency
- Summary: The Node.js event loop in v24 combines libuv's phase loop with Node-managed scheduling around JavaScript callback return points. Timers, pending callbacks, idle/prepare, poll, check, and close callbacks are libuv phases. Node drains process.nextTick callbacks and V8 promise microtasks at specific checkpoints around those phases. Timers come from libuv timer processing, I/O readiness usually enters through poll, setImmediate() runs in check, and ordering changes across CommonJS, ES modules, callbacks, and active microtask drains.

#### 1.4 Node.js Process Lifecycle: Normal Behavior, Startup, Signals, and Shutdown

- URL: https://www.thenodebook.com/node-arch/node-process-lifecycle
- Source: src/content/node-arch/node-process-lifecycle.mdx
- Book position: Chapter 1, subchapter 1.4
- Last updated: 2026-05-23
- Tags: process, lifecycle, shutdown, bootstrap, signals
- Summary: The Node.js process lifecycle begins when the node executable parses startup flags, initializes V8 and libuv, creates a runtime environment, runs internal bootstrap code, and loads the entry module. After top-level code runs, the process stays alive while referenced handles or active requests remain: servers, sockets, timers, workers, child processes, file streams, and pending native work all count. Exit begins when work drains, process.exit() forces termination, process.exitCode is left for natural shutdown, or a signal handler moves the service into graceful shutdown.

### Chapter 2: Buffers & Binary Data

#### 2.1 What Is a Buffer in Node.js? Bytes, Encoding, and TypedArray Memory

- URL: https://www.thenodebook.com/buffers/what-is-buffer
- Source: src/content/buffers/what-is-buffer.mdx
- Book position: Chapter 2, subchapter 2.1
- Last updated: 2026-05-23
- Tags: buffers, binary-data, memory, encoding
- Summary: A Buffer in Node.js v24 is a fixed-size mutable byte view used at binary I/O paths. File reads, TCP sockets, TLS records, compressed payloads, image headers, hashes, and protocol frames arrive as bytes before any format gives them meaning. A Buffer stores byte values from 0 to 255, exposes indexed access, inherits from Uint8Array, and carries Node-specific helpers for encoding, decoding, allocation, slicing, copying, and numeric reads. The main decision is ownership: copied bytes, shared backing memory, pooled slabs, and retained views behave differently.

#### 2.2 Buffer Allocation

- URL: https://www.thenodebook.com/buffers/allocation-patterns
- Source: src/content/buffers/allocation-patterns.mdx
- Book position: Chapter 2, subchapter 2.2
- Last updated: 2026-05-14
- Tags: buffers, memory-allocation, performance, pooling
- Summary: How Buffer.alloc, Buffer.allocUnsafe, Buffer.from, slab pooling, and large Buffer allocation affect memory safety and performance in Node.js.

#### 2.3 Buffer Operations

- URL: https://www.thenodebook.com/buffers/working-with-buffers
- Source: src/content/buffers/working-with-buffers.mdx
- Book position: Chapter 2, subchapter 2.3
- Last updated: 2026-05-14
- Tags: buffers, binary-operations, memory-ownership, zero-copy
- Summary: How Buffer views, copies, TypedArray interop, worker transfer, and zero-copy parsing affect byte ownership in Node.js.

#### 2.4 Buffer Fragmentation, Retained Views, and External Memory

- URL: https://www.thenodebook.com/buffers/fragmentation-and-challenges
- Source: src/content/buffers/fragmentation-and-challenges.mdx
- Book position: Chapter 2, subchapter 2.4
- Last updated: 2026-05-14
- Tags: buffers, fragmentation, memory-management, troubleshooting
- Summary: How Buffer allocation can fragment external memory, pin large backing stores, interact with V8 accounting, and create performance problems in Node.js.

### Chapter 3: Streams

#### 3.1 Stream Foundations

- URL: https://www.thenodebook.com/streams/foundation-of-streams
- Source: src/content/streams/foundation-of-streams.mdx
- Book position: Chapter 3, subchapter 3.1
- Last updated: 2026-05-14
- Tags: streams, async-io, backpressure, flow-control
- Summary: How Node.js moves chunked data through stream queues, consumption modes, and backpressure without treating every input as one value.

#### 3.2 Node.js Readable Streams: Modes, Buffers, and Backpressure

- URL: https://www.thenodebook.com/streams/readable-streams
- Source: src/content/streams/readable-streams.mdx
- Book position: Chapter 3, subchapter 3.2
- Last updated: 2026-05-23
- Tags: streams, readable, data-flow, custom-streams
- Summary: A Readable stream in Node.js v24 is the producer side of the stream state machine. It owns a readable buffer, asks the underlying source for chunks through _read(), and hands chunks to consumers through data events, read() calls, piping, or async iteration. highWaterMark controls when the stream stops asking for more data. Flowing mode pushes chunks as they arrive, paused mode keeps chunks buffered until the consumer pulls, and backpressure depends on the source respecting push() returning false.

#### 3.3 Writable Streams

- URL: https://www.thenodebook.com/streams/writable-streams
- Source: src/content/streams/writable-streams.mdx
- Book position: Chapter 3, subchapter 3.3
- Last updated: 2026-05-14
- Tags: streams, writable, backpressure, custom-streams
- Summary: How Writable streams accept chunks, buffer writes, use highWaterMark, return false from write, and emit drain for backpressure.

#### 3.4 Transform Streams

- URL: https://www.thenodebook.com/streams/transform-streams
- Source: src/content/streams/transform-streams.mdx
- Book position: Chapter 3, subchapter 3.4
- Last updated: 2026-05-14
- Tags: streams, transform, duplex, data-processing, custom-streams
- Summary: How Transform and Duplex streams work in Node.js, how _transform and _flush emit output, and how backpressure crosses both sides.

#### 3.5 Stream Pipeline

- URL: https://www.thenodebook.com/streams/modern-pipelines-error-handling
- Source: src/content/streams/modern-pipelines-error-handling.mdx
- Book position: Chapter 3, subchapter 3.5
- Last updated: 2026-05-14
- Tags: streams, pipelines, error-handling, async, backpressure
- Summary: How pipe, stream.pipeline, finished, async pipeline stages, AbortSignal, side outputs, and partial-output cleanup work in current Node.js stream pipelines.

#### 3.6 Zero-Copy Streams

- URL: https://www.thenodebook.com/streams/zero-copy-scatter-gather
- Source: src/content/streams/zero-copy-scatter-gather.mdx
- Book position: Chapter 3, subchapter 3.6
- Last updated: 2026-05-14
- Tags: streams, zero-copy, scatter-gather, writev, buffer-pooling, performance
- Summary: How Buffer ownership, fs.copyFile, writev, _writev, cork, and copy-path measurement shape hot Node.js stream paths.

### Chapter 4: File System

#### 4.1 File Descriptors & Handles

- URL: https://www.thenodebook.com/file-system/file-descriptors-and-handles
- Source: src/content/file-system/01-file-descriptors-and-handles.md
- Book position: Chapter 4, subchapter 4.1
- Last updated: 2026-05-14
- Tags: nodejs, file-system, file-descriptors, fs, posix
- Summary: How file descriptors and FileHandle objects map to OS file state, open flags, close behavior, libuv work, and EMFILE failures.

#### 4.2 File I/O

- URL: https://www.thenodebook.com/file-system/reading-writing-files
- Source: src/content/file-system/02-reading-writing-files.md
- Book position: Chapter 4, subchapter 4.2
- Last updated: 2026-05-14
- Tags: nodejs, file-system, fs, readFile, writeFile
- Summary: How Node.js reads and writes files through whole-file helpers, streams, low-level read/write calls, append mode, and durable flushes.

#### 4.3 fs.promises & FileHandle

- URL: https://www.thenodebook.com/file-system/fs-promises-filehandle
- Source: src/content/file-system/03-fs-promises-filehandle.md
- Book position: Chapter 4, subchapter 4.3
- Last updated: 2026-05-14
- Tags: nodejs, file-system, fs-promises, FileHandle, async-await
- Summary: How fs.promises and FileHandle work in Node.js, including async file operations, descriptor ownership, stream lifecycles, cleanup, and controlled concurrency.

#### 4.4 fs.watch & Atomic Writes

- URL: https://www.thenodebook.com/file-system/watching-atomic-writes
- Source: src/content/file-system/04-watching-atomic-writes.md
- Book position: Chapter 4, subchapter 4.4
- Last updated: 2026-05-14
- Tags: nodejs, file-system, fs-watch, atomic-writes, inotify
- Summary: How fs.watch, fs.watchFile, OS watcher backends, and atomic replacement patterns interact in real file workflows.

#### 4.5 Permissions & Metadata

- URL: https://www.thenodebook.com/file-system/permissions-metadata-edge-cases
- Source: src/content/file-system/05-permissions-metadata-edge-cases.md
- Book position: Chapter 4, subchapter 4.5
- Last updated: 2026-05-14
- Tags: nodejs, file-system, permissions, stat, symlinks, metadata
- Summary: How Node.js exposes file permissions, ownership, stat metadata, symlinks, inodes, sparse files, special paths, and filesystem edge cases.

### Chapter 5: Process & OS

#### 5.1 process Object

- URL: https://www.thenodebook.com/process-os/process-object
- Source: src/content/process-os/01-process-object.md
- Book position: Chapter 5, subchapter 5.1
- Last updated: 2026-05-14
- Tags: nodejs, process, environment, argv, memory-usage
- Summary: How the Node.js process object exposes env, argv, pid, cwd, exit state, memory usage, versions, IPC, and native process bindings.

#### 5.2 Signals & Exit Codes

- URL: https://www.thenodebook.com/process-os/signals-exit-codes
- Source: src/content/process-os/02-signals-exit-codes.md
- Book position: Chapter 5, subchapter 5.2
- Last updated: 2026-05-14
- Tags: nodejs, signals, exit-codes, SIGINT, SIGTERM, graceful-shutdown
- Summary: How Node.js handles SIGTERM, SIGINT, exit codes, beforeExit, exit, uncaught exceptions, and graceful shutdown across process scopes.

#### 5.3 os Module

- URL: https://www.thenodebook.com/process-os/os-module
- Source: src/content/process-os/03-os-module.md
- Book position: Chapter 5, subchapter 5.3
- Last updated: 2026-05-14
- Tags: nodejs, os-module, cpu, memory, network-interfaces, platform
- Summary: How the Node.js os module reports CPU counts, available parallelism, memory, load average, network interfaces, paths, users, and platform data.

#### 5.4 Standard I/O

- URL: https://www.thenodebook.com/process-os/standard-io
- Source: src/content/process-os/04-standard-io.md
- Book position: Chapter 5, subchapter 5.4
- Last updated: 2026-05-14
- Tags: nodejs, stdin, stdout, stderr, TTY, pipes
- Summary: How Node.js standard input, output, and error streams map to file descriptors, TTYs, pipes, console output, and backpressure.

### Chapter 6: The Module System

#### 6.1 CJS require() Internals

- URL: https://www.thenodebook.com/modules/cjs-require
- Source: src/content/modules/01-cjs-require.md
- Book position: Chapter 6, subchapter 6.1
- Last updated: 2026-05-23
- Tags: nodejs, modules, require, CommonJS, module-cache
- Summary: How Node.js require works internally through resolution, Module._load, source wrapping, compilation, module.exports, and require.cache.

#### 6.2 Module Resolution

- URL: https://www.thenodebook.com/modules/resolution-algorithm
- Source: src/content/modules/02-resolution-algorithm.md
- Book position: Chapter 6, subchapter 6.2
- Last updated: 2026-05-14
- Tags: nodejs, modules, resolution, node_modules, package-exports
- Summary: How Node.js resolves module specifiers through built-ins, relative paths, node_modules lookup, package.json main, exports, imports, and symlinks.

#### 6.3 ES Modules

- URL: https://www.thenodebook.com/modules/esm-import-export
- Source: src/content/modules/03-esm-import-export.md
- Book position: Chapter 6, subchapter 6.3
- Last updated: 2026-05-14
- Tags: nodejs, modules, ESM, import, export, static-analysis
- Summary: How ES Modules work in Node.js through static import/export syntax, module format detection, parse-link-evaluate phases, and live bindings.

#### 6.4 CommonJS/ESM Interop

- URL: https://www.thenodebook.com/modules/cjs-esm-interop
- Source: src/content/modules/04-cjs-esm-interop.md
- Book position: Chapter 6, subchapter 6.4
- Last updated: 2026-05-14
- Tags: nodejs, modules, CJS-ESM-interop, dual-packages, conditional-exports
- Summary: How CommonJS and ES Modules interoperate in Node.js through CJS namespaces, require(esm), conditional exports, and dual package design.

#### 6.5 import.meta & ESM Caching

- URL: https://www.thenodebook.com/modules/import-meta-caching
- Source: src/content/modules/05-import-meta-caching.md
- Book position: Chapter 6, subchapter 6.5
- Last updated: 2026-05-14
- Tags: nodejs, modules, import-meta, module-cache, circular-dependencies
- Summary: How import.meta, import.meta.url, import.meta.dirname, the ESM module cache, circular dependencies, and module state work in Node.js.

### Chapter 7: Async Patterns

#### 7.1 Error-First Callbacks

- URL: https://www.thenodebook.com/async-patterns/callback-patterns
- Source: src/content/async-patterns/01-callback-patterns.md
- Book position: Chapter 7, subchapter 7.1
- Last updated: 2026-05-14
- Tags: nodejs, callbacks, error-first, async-patterns, control-flow
- Summary: How Node.js error-first callbacks work, why the first argument carries errors, and how callback dispatch connects native async work back to JavaScript.

#### 7.2 Node.js Microtasks: Promise Jobs, process.nextTick, and Timer Order

- URL: https://www.thenodebook.com/async-patterns/promises-microtasks
- Source: src/content/async-patterns/02-promises-microtasks.md
- Book position: Chapter 7, subchapter 7.2
- Last updated: 2026-05-23
- Tags: nodejs, promises, microtasks, async-patterns, v8
- Summary: Node.js v24 schedules Promise reactions as V8 microtasks and process.nextTick callbacks in a separate Node-managed queue. At a CommonJS main-script checkpoint, Node drains process.nextTick first, then V8 promise jobs and queueMicrotask callbacks, then event-loop callbacks such as timers, poll callbacks, and setImmediate. ES module top-level evaluation already runs inside the microtask machinery, so promise jobs can run before nearby nextTick callbacks. Inside an active microtask drain, new V8 microtasks continue before nextTick callbacks created during that drain.

#### 7.3 Async/Await

- URL: https://www.thenodebook.com/async-patterns/async-await
- Source: src/content/async-patterns/03-async-await.md
- Book position: Chapter 7, subchapter 7.3
- Last updated: 2026-05-14
- Tags: nodejs, async-await, state-machine, v8, async-patterns
- Summary: How async functions and await work in Node.js through promise wrapping, suspension, resumption, microtasks, errors, and V8 state machines.

#### 7.4 EventEmitter Internals

- URL: https://www.thenodebook.com/async-patterns/eventemitter-internals
- Source: src/content/async-patterns/04-eventemitter-internals.md
- Book position: Chapter 7, subchapter 7.4
- Last updated: 2026-05-14
- Tags: nodejs, eventemitter, events, async-patterns, observer-pattern
- Summary: How EventEmitter stores listeners, dispatches emit synchronously, handles error events, preserves listener order, and reports possible leaks.

#### 7.5 Async Iterators

- URL: https://www.thenodebook.com/async-patterns/async-iterators
- Source: src/content/async-patterns/05-async-iterators.md
- Book position: Chapter 7, subchapter 7.5
- Last updated: 2026-05-14
- Tags: nodejs, async-iterators, for-await-of, async-generators, async-patterns
- Summary: How async iterators work in Node.js through Symbol.asyncIterator, for await...of, async generators, stream consumption, and backpressure.

#### 7.6 Promise Combinators

- URL: https://www.thenodebook.com/async-patterns/promise-combinators
- Source: src/content/async-patterns/06-promise-combinators.md
- Book position: Chapter 7, subchapter 7.6
- Last updated: 2026-05-14
- Tags: nodejs, promise-combinators, promise-all, promise-race, async-patterns
- Summary: How Promise.all, allSettled, race, and any behave in Node.js, including short-circuiting, failure propagation, cancellation gaps, and concurrency limits.

### Chapter 8: Runtime Platform APIs & Tooling

#### 8.1 CLI Flags

- URL: https://www.thenodebook.com/runtime-platform/cli-runtime-configuration
- Source: src/content/runtime-platform/01-cli-runtime-configuration.md
- Book position: Chapter 8, subchapter 8.1
- Last updated: 2026-05-14
- Tags: nodejs, cli-flags, runtime-configuration, node-options, startup
- Summary: How Node.js consumes startup flags, NODE_OPTIONS, preloads, V8 options, source maps, conditions, warnings, diagnostics, memory flags, node --run, and experimental config files.

#### 8.2 .env Files

- URL: https://www.thenodebook.com/runtime-platform/env-files-configuration
- Source: src/content/runtime-platform/02-env-files-configuration.md
- Book position: Chapter 8, subchapter 8.2
- Last updated: 2026-05-14
- Tags: nodejs, env-files, configuration, dotenv, process-env
- Summary: How Node.js loads .env files with --env-file, parses DotEnv syntax, resolves precedence, handles NODE_OPTIONS, uses process.loadEnvFile() and util.parseEnv(), and turns raw strings into validated config.

#### 8.3 Web Platform APIs

- URL: https://www.thenodebook.com/runtime-platform/web-platform-apis
- Source: src/content/runtime-platform/03-web-platform-apis.md
- Book position: Chapter 8, subchapter 8.3
- Last updated: 2026-05-14
- Tags: nodejs, web-platform, fetch, undici, web-streams
- Summary: How Node.js exposes web-compatible globals including fetch, Request, Response, Web Streams, Blob, File, FormData, URL, and structuredClone.

#### 8.4 TypeScript & Compile Cache

- URL: https://www.thenodebook.com/runtime-platform/typescript-compile-cache
- Source: src/content/runtime-platform/04-typescript-compile-cache.md
- Book position: Chapter 8, subchapter 8.4
- Last updated: 2026-05-14
- Tags: nodejs, typescript, type-stripping, compile-cache, runtime
- Summary: How Node.js v24.15 runs TypeScript through type stripping, handles .ts module formats, rejects unsupported syntax, and stores compile cache data.

#### 8.5 REPL, Inspector, Watch & SEA

- URL: https://www.thenodebook.com/runtime-platform/repl-inspector-watch-sea
- Source: src/content/runtime-platform/05-repl-inspector-watch-sea.md
- Book position: Chapter 8, subchapter 8.5
- Last updated: 2026-05-14
- Tags: nodejs, repl, inspector, watch-mode, single-executable
- Summary: How Node.js REPL, inspector sessions, watch mode, and single executable applications evaluate code, expose debugging state, restart, and package apps.

### Chapter 9: HTTP Servers, Clients & Proxies

#### 9.1 HTTP/1.1 Wire Format and Semantics in Node.js

- URL: https://www.thenodebook.com/http/http11-wire-format
- Source: src/content/http/01-http11-wire-format.md
- Book position: Chapter 9, subchapter 9.1
- Last updated: 2026-06-28
- Tags: nodejs, http, http11, networking, protocols
- Summary: HTTP/1.1 turns ordered TCP bytes into messages with a start line, header section, empty-line delimiter, and optional body. In Node.js, the HTTP parser reads those bytes incrementally, separates request or response metadata from body bytes, applies framing rules such as Content-Length and chunked transfer coding, and determines when the same connection can carry another message. Methods, status codes, headers, keep-alive state, and interim responses all come from that parsed wire format.

#### 9.2 Node.js http.Server Request/Response Lifecycle

- URL: https://www.thenodebook.com/http/http-server-lifecycle
- Source: src/content/http/02-http-server-lifecycle.md
- Book position: Chapter 9, subchapter 9.2
- Last updated: 2026-06-28
- Tags: nodejs, http, server, request, response
- Summary: Node.js http.Server extends the lower net.Server socket path, then adds HTTP parsing and response writing on top of each accepted connection. For every parsed request, Node creates an IncomingMessage for request metadata and body bytes, pairs it with a ServerResponse for outbound headers and body writes, and emits the request event. Header commit timing, early request bodies, parser errors, timeouts, aborted sockets, and keep-alive reuse all depend on that per-connection lifecycle.

#### 9.3 Node.js HTTP Parsing with llhttp

- URL: https://www.thenodebook.com/http/http-parsing-llhttp
- Source: src/content/http/03-http-parsing-llhttp.md
- Book position: Chapter 9, subchapter 9.3
- Last updated: 2026-06-28
- Tags: nodejs, http, llhttp, parsing, http1
- Summary: Node.js feeds HTTP/1.1 bytes from each socket into llhttp, a native parser that walks request and response syntax incrementally. llhttp reports parser callbacks for URL bytes, header fields, header values, body chunks, message completion, trailers, and upgrade boundaries. Node maps those callbacks into IncomingMessage state, stream reads, parser errors, timeout behavior, and connection reuse decisions. Header limits, malformed syntax, chunked framing, and upgrade handoff are enforced before ordinary handler code owns the message.

#### 9.4 Node.js HTTP Routing and Middleware Without a Framework

- URL: https://www.thenodebook.com/http/raw-routing-middleware
- Source: src/content/http/04-raw-routing-middleware.md
- Book position: Chapter 9, subchapter 9.4
- Last updated: 2026-06-28
- Tags: nodejs, http, routing, middleware
- Summary: Framework-free routing in Node.js starts with the request event and builds method checks, URL parsing, path matching, middleware sequencing, body limits, JSON parsing, and response helpers as normal JavaScript control flow. The router decides which handler owns a request after Node has already parsed HTTP metadata. Middleware wraps that handler path with shared concerns such as logging, auth checks, body parsing, error mapping, and response finalization. Bounded reads and explicit errors keep malformed or oversized requests from leaking into application logic.

#### 9.5 Node.js HTTP Keep-Alive, Agents, and Connection Pools

- URL: https://www.thenodebook.com/http/keepalive-agents-pools
- Source: src/content/http/05-keepalive-agents-pools.md
- Book position: Chapter 9, subchapter 9.5
- Last updated: 2026-06-28
- Tags: nodejs, http, keep-alive, agents, connection-pooling
- Summary: HTTP keep-alive lets Node.js run multiple HTTP/1.1 exchanges over one TCP connection when message framing and connection headers permit reuse. On the client side, http.Agent owns socket pools, free socket lists, active socket counts, and reuse limits for each origin. On the server side, idle timers and request limits decide how long a connection stays available after a response finishes. Stale pooled sockets, maxSockets pressure, freeSocketTimeout, server keepAliveTimeout, and maxRequestsPerSocket shape latency, resource use, and failure behavior.

#### 9.6 Node.js HTTP Clients: fetch, Undici, and http.request

- URL: https://www.thenodebook.com/http/fetch-undici-client
- Source: src/content/http/06-fetch-undici-client.md
- Book position: Chapter 9, subchapter 9.6
- Last updated: 2026-06-28
- Tags: nodejs, http, fetch, undici, http-client
- Summary: Outbound HTTP in Node.js has two public surfaces. The classic node:http client creates ClientRequest objects, uses http.Agent for connection reuse, and exposes IncomingMessage responses as Node streams. The global fetch implementation runs through Undici, which owns dispatchers, pools, request scheduling, redirects, body streams, decompression behavior, abort handling, and pipelining. Both paths send HTTP over sockets, but they expose different APIs, error shapes, stream models, and pooling controls.

#### 9.7 Node.js Reverse Proxies, Static Files, and Streaming Bodies

- URL: https://www.thenodebook.com/http/proxies-static-streaming
- Source: src/content/http/07-proxies-static-streaming.md
- Book position: Chapter 9, subchapter 9.7
- Last updated: 2026-06-28
- Tags: nodejs, http, proxies, streams, static-files
- Summary: Node.js can sit at an HTTP boundary by forwarding requests upstream, streaming inbound and outbound bodies, filtering hop-by-hop headers, and serving file-backed responses from disk. A reverse proxy must preserve method, target, headers, body flow, status, trailers, and backpressure while removing connection-specific metadata that belongs only to one transport hop. Static file handling adds path normalization, content metadata, conditional requests, byte ranges, stream errors, and response timing. The same stream mechanics control both proxy bodies and file responses.

### Chapter 10: TLS, HTTPS & HTTP/2

#### 10.1 Node.js TLS Handshake: Cipher Negotiation and Session Reuse

- URL: https://www.thenodebook.com/http2-tls/tls-handshake
- Source: src/content/http2-tls/01-tls-handshake.md
- Book position: Chapter 10, subchapter 10.1
- Last updated: 2026-06-28
- Tags: nodejs, tls, https, openssl, networking
- Summary: Node.js performs the TLS handshake through OpenSSL beneath the node:tls module. The client hello advertises TLS versions, cipher suites, key-share data, and SNI; the server hello selects from that offer under its own policy. Node v24 defaults to the TLS 1.2 through TLS 1.3 range. Ephemeral ECDHE key exchange derives traffic keys, Finished messages verify the transcript, and secureConnect fires once the connection reaches its secure state. Session resumption reuses earlier TLS state to shorten later handshakes.

#### 10.2 Node.js TLS Certificates: Chains, CAs, and Trust Stores

- URL: https://www.thenodebook.com/http2-tls/certificate-chains-trust
- Source: src/content/http2-tls/02-certificate-chains-trust.md
- Book position: Chapter 10, subchapter 10.2
- Last updated: 2026-06-28
- Tags: nodejs, tls, https, certificates, security
- Summary: Node.js delegates certificate validation to OpenSSL, which builds a path from the server leaf certificate through intermediates to a trust anchor in the configured CA set. Validation checks each signature, the validity dates on every certificate in the path, and certificate purpose. Node then runs hostname verification, comparing the requested name against SAN entries of the matching type and falling back to subject CN for DNS names when no SAN is present. The ca option replaces the default trust list rather than extending it.

#### 10.3 Node.js HTTPS Servers and Clients: TLS, SNI, and Agents

- URL: https://www.thenodebook.com/http2-tls/https-servers-clients
- Source: src/content/http2-tls/03-https-servers-clients.md
- Book position: Chapter 10, subchapter 10.3
- Last updated: 2026-06-28
- Tags: nodejs, https, tls, certificates, http-client
- Summary: Node.js HTTPS runs the same HTTP server and client code over a TLS connection from node:tls. https.createServer builds a default secure context from key and cert, and SNICallback selects per-hostname contexts during the handshake before HTTP parsing. The hostname, servername, and Host header address three separate layers. https.request and https.Agent manage TLS socket pooling and session caching. TLS termination can sit in Node or a reverse proxy, which decides which component reads the client certificate and forwarded headers.

#### 10.4 Node.js Mutual TLS: Client Certificates and requestCert

- URL: https://www.thenodebook.com/http2-tls/mutual-tls
- Source: src/content/http2-tls/04-mutual-tls.md
- Book position: Chapter 10, subchapter 10.4
- Last updated: 2026-06-28
- Tags: nodejs, tls, https, mtls, certificates
- Summary: Mutual TLS adds client certificate authentication to the TLS handshake. A Node.js HTTPS server sets requestCert to ask for a client certificate and ca to name the client CA set it trusts, then OpenSSL builds a path from the client leaf to that CA and verifies the private-key proof. With rejectUnauthorized true, invalid peers fail during TLS setup before any request handler runs. The socket exposes authorized, authorizationError, and getPeerCertificate. TLS authentication identifies the peer; application code still maps that identity to permissions.

#### 10.5 Node.js ALPN: Negotiating HTTP/2 vs HTTP/1.1 over TLS

- URL: https://www.thenodebook.com/http2-tls/alpn-negotiation
- Source: src/content/http2-tls/05-alpn-negotiation.md
- Book position: Chapter 10, subchapter 10.5
- Last updated: 2026-06-28
- Tags: nodejs, tls, https, http2, alpn
- Summary: ALPN, Application-Layer Protocol Negotiation, is a TLS extension that selects the application protocol during the handshake, before any application bytes move. The client sends an ordered ALPNProtocols list such as h2 and http/1.1, and the server picks one by its own list order. Node exposes the result as tlsSocket.alpnProtocol. https.createServer serves HTTP/1.1, http2.createSecureServer serves HTTP/2, and allowHTTP1 controls fallback. A client offering no overlapping protocol fails the handshake with no_application_protocol; sending no ALPN leaves alpnProtocol false.

#### 10.6 Node.js HTTP/2: Multiplexing, Flow Control, and Streams

- URL: https://www.thenodebook.com/http2-tls/http2-multiplexing-flow-control
- Source: src/content/http2-tls/06-http2-multiplexing-flow-control.md
- Book position: Chapter 10, subchapter 10.6
- Last updated: 2026-06-28
- Tags: nodejs, http2, tls, multiplexing, flow-control
- Summary: After ALPN selects h2, Node.js represents the HTTP/2 connection as an Http2Session and each request-response exchange as an Http2Stream backed by nghttp2. Messages travel as binary frames tagged with stream IDs, so one connection multiplexes many concurrent streams with interleaved frames. HPACK compresses header blocks as connection state, SETTINGS frames carry per-direction limits such as MAX_CONCURRENT_STREAMS, and flow control runs two byte-credit windows, one per stream and one per connection. GOAWAY, RST_STREAM, and PING manage shutdown at session and stream scope.

### Chapter 11: Realtime & Streaming APIs

#### 11.1 Node.js WebSocket Servers: HTTP Upgrade and Frame Parsing

- URL: https://www.thenodebook.com/realtime/websocket-protocol-node
- Source: src/content/realtime/01-websocket-protocol-node.md
- Book position: Chapter 11, subchapter 11.1
- Last updated: 2026-06-28
- Tags: nodejs, websocket, realtime, http, networking
- Summary: A WebSocket connection in Node begins as an HTTP/1.1 GET carrying Upgrade: websocket. The server validates the handshake, derives Sec-WebSocket-Accept, and responds with 101 Switching Protocols. After that the HTTP parser stops and a frame parser owns the socket. Frames carry an opcode, mask bit, and length; clients mask payloads, servers do not. Control frames handle ping, pong, and close. Size limits, UTF-8 validation, and close codes guard the connection.

#### 11.2 Node.js Server-Sent Events and Long Polling Transports

- URL: https://www.thenodebook.com/realtime/sse-long-polling
- Source: src/content/realtime/02-sse-long-polling.md
- Book position: Chapter 11, subchapter 11.2
- Last updated: 2026-06-28
- Tags: nodejs, realtime, sse, long-polling, http
- Summary: Server-Sent Events keep one HTTP response open and stream text/event-stream blocks, each ended by a blank line, until either side closes. EventSource parses the body, fires named events, and reconnects with Last-Event-ID so the server can replay from a cursor. Long polling holds a request for a bounded interval, answers when an event arrives or the timer fires, then the client polls again. Both run over ordinary HTTP, so cleanup, timeouts, and replay windows decide reliability.

#### 11.3 Node.js Realtime Backpressure: Queues and Slow Consumers

- URL: https://www.thenodebook.com/realtime/realtime-backpressure
- Source: src/content/realtime/03-realtime-backpressure.md
- Book position: Chapter 11, subchapter 11.3
- Last updated: 2026-06-28
- Tags: nodejs, realtime, websocket, sse, backpressure
- Summary: Realtime backpressure in Node comes from each connection draining slower than the server fills it. The fix is a bounded per-connection send queue with limits on bytes, message count, and age. When a connection overflows, policy decides whether to drop, coalesce latest-value updates, close, or replay from stored history. Sequence numbers let clients detect gaps. Broadcast fanout keeps pressure per recipient so one slow consumer never stalls the rest, and bufferedAmount reports transport-side queueing only.

#### 11.4 Node.js WebSocket Auth, Reconnects, Heartbeats, Presence

- URL: https://www.thenodebook.com/realtime/realtime-auth-presence
- Source: src/content/realtime/04-realtime-auth-presence.md
- Book position: Chapter 11, subchapter 11.4
- Last updated: 2026-06-28
- Tags: nodejs, realtime, websocket, sse, presence
- Summary: A realtime connection authenticates during the HTTP upgrade or request, then stores a server-side auth context that every later message reads. Browser handshakes need an Origin check to block cross-site WebSocket hijacking. Long-lived sockets outlive their tokens, so the server enforces expiry with a timer and accepts in-place refresh messages. Reconnects carry a resume token and cursor within a bounded window. Application heartbeats prove liveness, and the server computes presence from observed connection state through one lifecycle record.

#### 11.5 Node.js Realtime Fanout, Rooms, and Horizontal Scaling

- URL: https://www.thenodebook.com/realtime/fanout-rooms-scaling
- Source: src/content/realtime/05-fanout-rooms-scaling.md
- Book position: Chapter 11, subchapter 11.5
- Last updated: 2026-06-28
- Tags: nodejs, realtime, websocket, scaling
- Summary: Realtime fanout turns one event into many sends. Inside a process, a connection registry and a room registry expand a routing key into connection IDs, and a local loop enqueues the payload per connection through bounded queues. Across processes, each process sees only its own sockets, so a backplane such as Redis pub/sub carries events between them, with origin metadata preventing loops. Sticky sessions keep reconnects near local state, and shards partition room ownership once per-process backplane traffic or room size becomes the limiting cost.

### Chapter 12: API Design, Contracts & Frameworks

#### 12.1 Node.js REST API Design: Resource Modeling and Semantics

- URL: https://www.thenodebook.com/api-design/rest-resource-modeling
- Source: src/content/api-design/01-rest-resource-modeling.md
- Book position: Chapter 12, subchapter 12.1
- Last updated: 2026-06-28
- Tags: nodejs, api-design, rest, http, contracts
- Summary: Resource-oriented REST design in Node.js separates the API surface from the contract clients depend on. The resource model names addressable concepts as collections, items, and subresources, each carrying a stable identifier in the route pattern. HTTP methods map to protocol operations, status codes report resource-level outcomes, and representations expose a chosen slice of state through a view function. Route names, field names, enum values, and status behavior all harden into compatibility constraints once clients ship against them.

#### 12.2 Node.js API Validation: OpenAPI and JSON Schema Boundaries

- URL: https://www.thenodebook.com/api-design/openapi-json-schema-validation
- Source: src/content/api-design/02-openapi-json-schema-validation.md
- Book position: Chapter 12, subchapter 12.2
- Last updated: 2026-06-28
- Tags: nodejs, api-design, openapi, json-schema, validation
- Summary: OpenAPI and JSON Schema do separate jobs in a Node.js API. The OpenAPI document describes paths, operations, parameters, request bodies, and responses as a machine-readable contract. JSON Schema validates actual JSON values at runtime. Validators run at the point where external input enters the service, applying coercion, defaults, and unknown-field policy as configured. Schemas compile once at startup. TypeScript types are erased before execution, so a runtime validator still guards every input. Contract drift opens whenever the document, handler, and generated clients stop agreeing.

#### 12.3 Node.js Express and Fastify Internals: Request Lifecycle

- URL: https://www.thenodebook.com/api-design/express-fastify-internals
- Source: src/content/api-design/03-express-fastify-internals.md
- Book position: Chapter 12, subchapter 12.3
- Last updated: 2026-06-28
- Tags: nodejs, api-design, express, fastify
- Summary: Express and Fastify sit on the same Node.js HTTP server lifecycle and diverge in how they run a request. Express walks an ordered middleware stack where next() advances control and registration order is the contract. Fastify matches a route, then runs fixed lifecycle phases with schema-driven validation and serialization attached to the route record. Express matches by stack order; Fastify gives static routes priority over parametric ones. Encapsulation scopes Fastify hooks and decorators, while returned promise rejections route to framework error handling in both.

#### 12.4 Node.js API Behavior: Errors, Idempotency, and Pagination

- URL: https://www.thenodebook.com/api-design/api-behavior-contracts
- Source: src/content/api-design/04-api-behavior-contracts.md
- Book position: Chapter 12, subchapter 12.4
- Last updated: 2026-06-28
- Tags: nodejs, api-design, idempotency, pagination
- Summary: API behavior contracts cover what clients depend on after schema validation passes. Errors use a stable envelope with a machine-readable code, a human message, and a field-level validation map, optionally following RFC 9457 Problem Details. Idempotency keys tie repeated writes to one durable record, returning the stored result or a conflict. Pagination favors cursors over offsets for changing collections and requires a unique tie-breaker in the sort key. Filtering, sorting, and field projection run against documented allow-lists rather than internal columns.

#### 12.5 Node.js GraphQL: Schemas, Resolvers, and N+1 Batching

- URL: https://www.thenodebook.com/api-design/graphql-schema-resolvers
- Source: src/content/api-design/05-graphql-schema-resolvers.md
- Book position: Chapter 12, subchapter 12.5
- Last updated: 2026-06-28
- Tags: nodejs, api-design, graphql, schemas, resolvers
- Summary: GraphQL combines a typed schema with an execution model. The schema is the API surface, publishing object types, fields, arguments, enums, and nullability that clients select from. Each request runs a selection set, and the executor calls one resolver per field, where the value a resolver returns becomes the parent for its children. Non-null markers propagate errors upward to the nearest nullable field. Nested list resolvers create the N+1 query problem, which request-scoped DataLoader batching collapses into single queries. Mutations run serially.

#### 12.6 Node.js gRPC and Protocol Buffers: Stubs, Streams, Status

- URL: https://www.thenodebook.com/api-design/grpc-protobuf
- Source: src/content/api-design/06-grpc-protobuf.md
- Book position: Chapter 12, subchapter 12.6
- Last updated: 2026-06-28
- Tags: nodejs, grpc, protobuf, api-design, http2
- Summary: gRPC is an RPC system built on Protocol Buffers, generated stubs, and HTTP/2 transport. The .proto file is the source artifact, defining services, methods, and message types. Each field carries a number that is the wire contract; field names never appear in the encoded bytes. Calls run as unary or one of three streaming modes, and the gRPC status arrives in trailers, so an HTTP 200 can still carry a failure. Channels stay long-lived per target. Schema evolution depends on field-number discipline and reservations.

#### 12.7 Node.js API Versioning and Gateways: Contract Evolution

- URL: https://www.thenodebook.com/api-design/api-versioning-gateways
- Source: src/content/api-design/07-api-versioning-gateways.md
- Book position: Chapter 12, subchapter 12.7
- Last updated: 2026-06-28
- Tags: nodejs, api-design, versioning, gateways, contracts
- Summary: API evolution changes a contract over time while existing consumers keep making requests. Each change classifies as breaking, backward-compatible, or additive at the point the consumer observes it, not by the size of the server diff. Versioning carries the selected contract through the URI, a request header, or a media type, with an explicit default. Deprecation, sunset, and migration move each contract element through a defined lifecycle. Gateways route requests to upstreams by version, while BFFs and compatibility facades keep old consumers working as the implementation changes.

## Retrieval Notes

- Treat this file as a curated context surface, not a ranking directive.
- Prefer /browse for the complete published chapter index.
- Prefer /pricing for current paid product details and checkout routing.
- Do not infer testimonials, rankings, guarantees, customer counts, or business outcomes from this file.
- This file is generated from digital/epub/manifest.json, chapter frontmatter, and src/config/prices.json.