diff --git a/.claude/article-brief-template.md b/.claude/article-brief-template.md
new file mode 100644
index 0000000..f40e940
--- /dev/null
+++ b/.claude/article-brief-template.md
@@ -0,0 +1,144 @@
+# Article Brief Template
+
+Use this template when planning new blog articles for Node.js Design Patterns.
+
+---
+
+## [Article Title]
+
+**Target keyword:** [primary keyword]
+**Secondary keywords:** [comma-separated list]
+**Estimated search volume:** [monthly searches]
+**Search intent:** [informational / tutorial / reference]
+**Buyer stage:** [awareness / consideration / implementation]
+**Content pillar:** [Core APIs / Modern Features / Patterns & Architecture]
+
+---
+
+### Outline
+
+1. **Introduction**
+   - Problem statement / why this matters
+   - What readers will learn
+
+2. **Quick Answer** (for featured snippets)
+   - 2-3 sentence summary
+   - Code snippet if applicable
+
+3. **Main Content**
+   - Section 1: [topic]
+   - Section 2: [topic]
+   - Section 3: [topic]
+   - (Add more sections as needed)
+
+4. **Best Practices / Common Mistakes**
+   - List of dos and don'ts
+   - Common pitfalls to avoid
+
+5. **Related Book Content** (if applicable)
+   - Light excerpt or reference to relevant chapter
+   - Connection to book patterns
+
+6. **FAQ Section**
+   - 3-5 frequently asked questions
+   - Keep answers concise (2-3 sentences)
+
+7. **Conclusion**
+   - Summary of key points
+   - CTA: Free chapter download
+
+---
+
+### Code Examples Checklist
+
+- [ ] Modern ESM syntax (`import`/`export`)
+- [ ] `async`/`await` patterns (avoid callbacks)
+- [ ] Proper error handling included
+- [ ] Practical, real-world examples
+- [ ] Comments explain non-obvious code
+- [ ] No external dependencies unless necessary
+
+---
+
+### Internal Links
+
+Link to related existing articles:
+
+- [ ] [Article 1 title](/blog/slug)
+- [ ] [Article 2 title](/blog/slug)
+
+Link to book chapters:
+
+- [ ] [Relevant chapter](/)
+
+---
+
+### SEO Checklist
+
+- [ ] Keyword in title
+- [ ] Keyword in H1
+- [ ] Keyword in first paragraph
+- [ ] Keyword in at least one H2
+- [ ] Meta description (150-160 characters)
+- [ ] Alt text for all images
+- [ ] FAQ section with 3-5 questions (for FAQ schema)
+- [ ] Internal links to 2+ related articles
+- [ ] External links to official docs where relevant
+
+---
+
+### Frontmatter Template
+
+```yaml
+---
+date: YYYY-MM-DDTHH:MM:SS
+updatedAt: YYYY-MM-DDTHH:MM:SS
+title: [Article Title]
+slug: [url-friendly-slug]
+description: [150-160 character meta description with target keyword]
+authors: ['luciano-mammino']
+tags: ['blog']
+faq:
+  - question: [FAQ Question 1]?
+    answer: [Concise 2-3 sentence answer]
+  - question: [FAQ Question 2]?
+    answer: [Concise 2-3 sentence answer]
+  - question: [FAQ Question 3]?
+    answer: [Concise 2-3 sentence answer]
+---
+```
+
+---
+
+### Content Calendar Reference
+
+| Month | #   | Article                          | Primary Keyword                 | Est. Volume |
+| ----- | --- | -------------------------------- | ------------------------------- | ----------- |
+| 1-2   | 1   | HTTP request in Node.js          | "node js http request"          | 15,000+     |
+| 1-2   | 2   | Environment variables in Node.js | "node js environment variables" | 8,000+      |
+| 1-2   | 3   | Using Node.js built-in SQLite    | "node js sqlite"                | 5,000+      |
+| 1-2   | 4   | Writing a CLI with Node.js       | "node js cli"                   | 4,000+      |
+| 3-4   | 5   | API server in Node.js (no deps)  | "node js http server"           | 6,000+      |
+| 3-4   | 6   | Hashing files with Node.js       | "node js hash file"             | 2,000+      |
+| 3-4   | 7   | Base64 encode/decode             | "base64 node js"                | 3,000+      |
+| 3-4   | 8   | Files and paths (node:path)      | "node js path"                  | 4,000+      |
+| 5-6   | 9   | Node.js Event Emitter            | "node js event emitter"         | 6,000+      |
+| 5-6   | 10  | Interactive streams guide        | "node js streams"               | 10,000+     |
+| 5-6   | 11  | How CommonJS works               | "commonjs node js"              | 3,000+      |
+| 5-6   | 12  | Node.js console tips             | "node js console"               | 2,000+      |
+| 7-8   | 13  | Type-stripping in Node.js        | "node js typescript"            | Growing     |
+| 7-8   | 14  | Node.js built-in test runner     | "node js test runner"           | 3,000+      |
+| 7-8   | 15  | Import maps in Node.js           | "node js import maps"           | 1,000+      |
+| 7-8   | 16  | Encrypting files with Node.js    | "node js encrypt file"          | 1,500+      |
+
+---
+
+### Success Metrics
+
+After publishing, track:
+
+- Organic traffic (Google Search Console)
+- Keyword rankings for target terms
+- Free chapter downloads from blog CTAs
+- Time on page and scroll depth
+- Internal link clicks to book pages
diff --git a/.claude/content-calendar.md b/.claude/content-calendar.md
new file mode 100644
index 0000000..8bc8615
--- /dev/null
+++ b/.claude/content-calendar.md
@@ -0,0 +1,125 @@
+# Content Calendar - Node.js Design Patterns Blog
+
+**Publishing cadence:** 2 articles/month
+**Primary goal:** SEO traffic → Build authority → Drive book sales
+**Content approach:** Original content with light book excerpts
+
+---
+
+## Content Pillars
+
+1. **Node.js Core APIs & Built-ins** - High-volume foundational topics
+2. **Modern Node.js Features** - New capabilities (22+, 23+) with early-mover SEO advantage
+3. **Node.js Patterns & Architecture** - Advanced patterns (light connection to book)
+
+---
+
+## 12-Month Calendar
+
+### Month 1-2: Foundation
+
+| #   | Status      | Article                          | Primary Keyword                 | Est. Volume | Pillar    |
+| --- | ----------- | -------------------------------- | ------------------------------- | ----------- | --------- |
+| 1   | COMPLETE    | **HTTP request in Node.js**      | "node js http request"          | 15,000+     | Core APIs |
+| 2   | NOT STARTED | Environment variables in Node.js | "node js environment variables" | 8,000+      | Core APIs |
+| 3   | NOT STARTED | Using Node.js built-in SQLite    | "node js sqlite"                | 5,000+      | Modern    |
+| 4   | NOT STARTED | Writing a CLI with Node.js       | "node js cli"                   | 4,000+      | Core APIs |
+
+### Month 3-4: Core APIs
+
+| #   | Status      | Article                         | Primary Keyword       | Est. Volume | Pillar    |
+| --- | ----------- | ------------------------------- | --------------------- | ----------- | --------- |
+| 5   | NOT STARTED | API server in Node.js (no deps) | "node js http server" | 6,000+      | Core APIs |
+| 6   | NOT STARTED | Hashing files with Node.js      | "node js hash file"   | 2,000+      | Core APIs |
+| 7   | NOT STARTED | Base64 encode/decode            | "base64 node js"      | 3,000+      | Core APIs |
+| 8   | NOT STARTED | Files and paths (node:path)     | "node js path"        | 4,000+      | Core APIs |
+
+### Month 5-6: Patterns (Book-Adjacent)
+
+| #   | Status      | Article                     | Primary Keyword         | Est. Volume | Pillar    |
+| --- | ----------- | --------------------------- | ----------------------- | ----------- | --------- |
+| 9   | NOT STARTED | Node.js Event Emitter guide | "node js event emitter" | 6,000+      | Patterns  |
+| 10  | NOT STARTED | Interactive streams guide   | "node js streams"       | 10,000+     | Patterns  |
+| 11  | NOT STARTED | How CommonJS works          | "commonjs node js"      | 3,000+      | Patterns  |
+| 12  | NOT STARTED | Node.js console tips        | "node js console"       | 2,000+      | Core APIs |
+
+### Month 7-8: Modern Node.js
+
+| #   | Status      | Article                       | Primary Keyword        | Est. Volume | Pillar    |
+| --- | ----------- | ----------------------------- | ---------------------- | ----------- | --------- |
+| 13  | NOT STARTED | Type-stripping in Node.js     | "node js typescript"   | Growing     | Modern    |
+| 14  | NOT STARTED | Node.js built-in test runner  | "node js test runner"  | 3,000+      | Modern    |
+| 15  | NOT STARTED | Import maps in Node.js        | "node js import maps"  | 1,000+      | Modern    |
+| 16  | NOT STARTED | Encrypting files with Node.js | "node js encrypt file" | 1,500+      | Core APIs |
+
+### Month 9-12: Advanced & Experimental
+
+| #   | Status      | Article                        | Primary Keyword | Notes                 |
+| --- | ----------- | ------------------------------ | --------------- | --------------------- |
+| 17+ | NOT STARTED | Rust/Zig + Node.js integration | niche           | Thought leadership    |
+| 18+ | NOT STARTED | TBD based on analytics         | TBD             | Iterate based on data |
+
+---
+
+## Existing Content
+
+| Topic                    | Coverage | Link                                                     |
+| ------------------------ | -------- | -------------------------------------------------------- |
+| Reading/writing files    | COMPLETE | /blog/reading-writing-files-nodejs                       |
+| Stream consumers         | COMPLETE | /blog/node-js-stream-consumer                            |
+| Async iterators          | COMPLETE | /blog/javascript-async-iterators                         |
+| Race conditions          | COMPLETE | /blog/node-js-race-conditions                            |
+| Checking Node.js version | COMPLETE | /blog/checking-node-js-version                           |
+| Installing Node.js       | UPDATED  | /blog/5-ways-to-install-node-js                          |
+| Docker development       | COMPLETE | /blog/node-js-development-with-docker-and-docker-compose |
+
+---
+
+## Internal Linking Map
+
+```
+HTTP Requests
+    └── links to → API Server (no deps)
+    └── links to → Reading/Writing Files (existing)
+
+Environment Variables
+    └── links to → CLI with parseArgs
+
+Files & Paths
+    └── links to → Reading/Writing Files (existing)
+    └── links to → Hashing Files
+    └── links to → Encrypting Files
+
+Streams Guide
+    └── links to → Stream Consumer (existing)
+    └── links to → Async Iterators (existing)
+    └── links to → Reading/Writing Files (existing)
+
+Event Emitter
+    └── links to → Streams Guide
+    └── links to → Race Conditions (existing)
+
+Installing Node.js
+    └── links to → Checking Node.js version (existing)
+    └── links to → Docker development (existing)
+```
+
+---
+
+## Quick Wins Checklist
+
+- [x] Add FAQ schema support to blog layout
+- [x] Update "5 Ways to Install Node.js" with fnm, Volta, Docker
+- [x] Cross-link existing articles
+- [x] Add CTAs for free chapter download to all posts
+- [ ] Monitor keyword rankings for existing content
+- [ ] A/B test CTA placements
+
+---
+
+## Notes
+
+- Focus on zero-dependency approaches using modern Node.js built-ins
+- Most competing articles still recommend axios/got first - opportunity to differentiate
+- New Node.js features (22+, 23+) have early-mover advantage
+- Light book excerpts where relevant (Ch 6 streams, Ch 10 testing)
diff --git a/.claude/settings.local.json b/.claude/settings.local.json
index d6c1aa5..fd00c29 100644
--- a/.claude/settings.local.json
+++ b/.claude/settings.local.json
@@ -3,7 +3,16 @@
     "allow": [
       "Bash(pnpm build:*)",
       "Bash(pnpm exec astro build:*)",
-      "Bash(pnpm install:*)"
+      "Bash(pnpm install:*)",
+      "Skill(marketing-skills:content-strategy)",
+      "Bash(find:*)",
+      "Bash(npm run build:*)",
+      "WebSearch",
+      "Bash(node fetch-get.js:*)",
+      "Bash(node fetch-post.js)",
+      "Bash(node http-get.js:*)",
+      "Bash(node http-post.js:*)",
+      "Bash(node:*)"
     ]
   }
 }
diff --git a/src/Layout.astro b/src/Layout.astro
index 294a85c..fb4f136 100644
--- a/src/Layout.astro
+++ b/src/Layout.astro
@@ -26,7 +26,7 @@ export interface Props {
   ogDescription?: string
   ogImage?: string
   canonical?: string
-  additionalSchema?: object
+  additionalSchema?: object | object[]
   noindex?: boolean
 }
 
@@ -143,12 +143,20 @@ const {
     </script>
 
     {
-      additionalSchema && (
-        <script
-          type="application/ld+json"
-          set:html={JSON.stringify(additionalSchema)}
-        />
-      )
+      additionalSchema &&
+        (Array.isArray(additionalSchema) ? (
+          additionalSchema.map((schema) => (
+            <script
+              type="application/ld+json"
+              set:html={JSON.stringify(schema)}
+            />
+          ))
+        ) : (
+          <script
+            type="application/ld+json"
+            set:html={JSON.stringify(additionalSchema)}
+          />
+        ))
     }
 
     <script>
diff --git a/src/components/blog/BlogLayout.astro b/src/components/blog/BlogLayout.astro
index 58bdaee..fd02814 100644
--- a/src/components/blog/BlogLayout.astro
+++ b/src/components/blog/BlogLayout.astro
@@ -8,7 +8,7 @@ import Footer from '@components/Footer.astro'
 import BookPromo from '@components/blog/BookPromo.astro'
 import { List } from '@lucide/astro'
 import { calculateReadingTime, formatDate } from '@lib/utils'
-import { generateBlogPostingSchema } from '@lib/schema'
+import { generateBlogPostingSchema, generateFAQPageSchema } from '@lib/schema'
 import Breadcrumb from './Breadcrumb.astro'
 import BlogCard from './BlogCard.astro'
 
@@ -31,7 +31,7 @@ type NestedCollectionHeadingsItem = CollectionEntryHeadingsItem & {
 }
 
 const { post, authors, prevPost, nextPost } = Astro.props
-const { title, description, date, updatedAt } = post.data
+const { title, description, date, updatedAt, faq } = post.data
 
 const formattedDate = formatDate(date)
 
@@ -54,6 +54,10 @@ const blogPostingSchema = generateBlogPostingSchema({
   siteUrl: SITE_URL,
 })
 
+// Generate FAQ schema if FAQ items are present
+const faqSchema = faq && faq.length > 0 ? generateFAQPageSchema(faq) : null
+const schemas = faqSchema ? [blogPostingSchema, faqSchema] : blogPostingSchema
+
 // Groups ToC in a way that it's easier to render as nested lists
 const nestedToc: NestedCollectionHeadingsItem[] = []
 let lastNestedTocEntry: NestedCollectionHeadingsItem | null = null
@@ -78,7 +82,7 @@ if (post.rendered?.metadata?.headings) {
   ogTitle={title}
   ogDescription={description}
   canonical={`${SITE_URL}/blog/${post.id}/`}
-  additionalSchema={blogPostingSchema}
+  additionalSchema={schemas}
 >
   <main class="min-h-screen bg-base-100">
     <!-- Blog Header -->
diff --git a/src/content.config.ts b/src/content.config.ts
index 8aa12f4..c7db366 100644
--- a/src/content.config.ts
+++ b/src/content.config.ts
@@ -63,6 +63,14 @@ const blog = defineCollection({
     description: z.string(),
     authors: z.array(reference('authors')),
     tags: z.array(z.string()),
+    faq: z
+      .array(
+        z.object({
+          question: z.string(),
+          answer: z.string(),
+        }),
+      )
+      .optional(),
   }),
 })
 
diff --git a/src/content/blog/checking-node-js-version/index.md b/src/content/blog/checking-node-js-version/index.md
index fca6fcf..4edccc8 100644
--- a/src/content/blog/checking-node-js-version/index.md
+++ b/src/content/blog/checking-node-js-version/index.md
@@ -1,11 +1,20 @@
 ---
 date: 2025-09-09T10:00:00
-updatedAt: 2025-09-09T10:00:00
+updatedAt: 2026-01-29T12:00:00
 title: How to check Node.js version and package manager versions
 slug: checking-node-js-version
 description: Learn how to check your current Node.js version and the versions of popular package managers including npm, pnpm, and yarn
 authors: ['luciano-mammino']
 tags: ['blog']
+faq:
+  - question: How do I check my Node.js version?
+    answer: Run 'node --version' or 'node -v' in your terminal. This will display your current Node.js version, such as v22.0.0.
+  - question: How do I check my npm version?
+    answer: Run 'npm --version' or 'npm -v' in your terminal. npm comes bundled with Node.js, so if you have Node.js installed, npm is already available.
+  - question: How do I check which Node.js version a project requires?
+    answer: Check the project's package.json file for an 'engines' field, or look for a .nvmrc, .node-version, or .tool-versions file in the project root. These files specify the required Node.js version.
+  - question: What Node.js version should I use?
+    answer: For production applications, use the Active LTS (Long Term Support) version. LTS releases receive critical bug fixes for 30 months. Check the official Node.js releases page for the current LTS version.
 ---
 
 Whether you're debugging compatibility issues, ensuring you're running the right version for a project, or just curious about your current setup, knowing how to check your Node.js version and package manager versions is essential for any Node.js developer.
@@ -174,3 +183,9 @@ Checking versions is a quick but essential task for Node.js developers:
 - **yarn**: `yarn --version` or `yarn -v`
 
 Keep these commands handy, and you'll always know what versions you're working with!
+
+:::tip[Level Up Your Node.js Skills]
+Now that you know how to check your Node.js version, why not deepen your Node.js knowledge? **Node.js Design Patterns** covers everything from async patterns to scalable architectures.
+
+[Get a FREE chapter →](/#free-chapter)
+:::
diff --git a/src/content/blog/installing-node-js/index.md b/src/content/blog/installing-node-js/index.md
index b2e69c1..3fe1a5d 100644
--- a/src/content/blog/installing-node-js/index.md
+++ b/src/content/blog/installing-node-js/index.md
@@ -1,14 +1,25 @@
 ---
 date: 2020-12-24T18:30:00
-updatedAt: 2020-12-30T16:00:00
+updatedAt: 2026-01-29T12:00:00
 title: 5 Ways to install Node.js
 slug: 5-ways-to-install-node-js
-description: Learn what are the most common ways to install Node.js in your development machine
+description: Learn what are the most common ways to install Node.js in your development machine. Covers nvm, fnm, Volta, n, official installers, Docker, and more.
 authors: ['luciano-mammino']
 tags: ['blog']
+faq:
+  - question: What is the best way to install Node.js?
+    answer: For most developers, using a version manager like nvm, fnm, or Volta is the best approach. These tools allow you to easily switch between Node.js versions, install multiple versions simultaneously, and avoid permission issues with global packages.
+  - question: What is the difference between nvm and fnm?
+    answer: Both nvm and fnm are Node.js version managers, but fnm is written in Rust and is significantly faster. fnm also has native Windows support and cross-platform compatibility. nvm has a larger community and more documentation, while fnm offers better performance.
+  - question: Should I use the LTS or Current version of Node.js?
+    answer: For production applications and most development work, use the LTS (Long Term Support) version. LTS releases receive critical bug fixes for 30 months. Use the Current version only if you need the latest features or are testing compatibility with upcoming releases.
+  - question: How do I switch between Node.js versions?
+    answer: With version managers like nvm, fnm, or Volta, you can switch versions using simple commands. For nvm use 'nvm use <version>', for fnm use 'fnm use <version>', and Volta automatically switches based on your project's package.json.
+  - question: Can I install multiple versions of Node.js on the same machine?
+    answer: Yes, using a version manager like nvm, fnm, n, or Volta allows you to install and maintain multiple Node.js versions simultaneously. You can easily switch between them based on your project requirements.
 ---
 
-In this article, we will explore some of the most common ways to install Node.js in your development system. We will see how to install Node.js using the official installer for various platforms, how to use a Node.js version manager such as `n` or `nvm` and, finally, we will also see how to compile and install Node.js from source. Along the way, we will try to disclose one or two tips to get you even more productive with Node.js!
+In this article, we will explore the most common ways to install Node.js in your development system. We will cover modern version managers like `fnm`, `nvm`, `Volta`, and `n`, the official installer for various platforms, how to use Docker for Node.js development, and how to compile Node.js from source. Along the way, we will share tips to help you choose the right approach and get productive with Node.js!
 
 Let's get started!
 
@@ -18,7 +29,8 @@ There are many different ways to install Node.js and every one of them comes wit
 
 ### TLDR;
 
-- Use `nvm` or `n` if you develop with Node.js frequently and you expect to be needing to switch Node.js version while moving from one project to another or to debug potential compatibility issues in your project or library.
+- Use a version manager like `fnm`, `nvm`, `Volta`, or `n` if you develop with Node.js frequently and you expect to be needing to switch Node.js version while moving from one project to another or to debug potential compatibility issues in your project or library.
+- `fnm` is the recommended choice for most developers: it's fast, cross-platform, and easy to use.
 - Use the system package manager like `apt`, `brew` or `winget` if you tend to install all your software this way and if you don't expect to be needing to switch or upgrade Node.js version too often.
 - Install Node.js from source if you are an advanced user and if you want to contribute back to Node.js itself.
 - Use the official Node.js installer if you don't fall in any of the previous options...
@@ -51,11 +63,9 @@ Node.js offers 2 main release lines:
 
 Finally, the release coming from the current _master_ branch is considered **Unstable**. This is generally a release dedicated to people maintaining Node.js or developers who want to explore new experimental features that haven't been yet included in any of the major releases.
 
-Node.js publishes an [official timeline of current and future releases](https://nodejs.org/en/about/releases/). At the time of writing (December 2020), this how the timeline looks like:
+Node.js publishes an [official timeline of current and future releases](https://nodejs.org/en/about/releases/). You can always check the current release schedule on the official Node.js website.
 
-[![Node.js release timeline](./nodejs-release-schedule.svg)]()
-
-If you are still wondering which release should you use, going with the _Active LTS_ is almost always the best choice, especially if you are building production applications.
+If you are still wondering which release should you use, going with the _Active LTS_ is almost always the best choice, especially if you are building production applications. As of 2026, Node.js 22 is the current Active LTS version.
 
 ## Install Node.js using n
 
@@ -116,6 +126,85 @@ In summary, this is where `n` shines or falls short:
 - 👍 It keeps all the installed versions cached, so you can switch quickly between versions (no full re-install)
 - 👍 Allows to keep the setup local to the user so you don't have to use admin permission to install global packages
 
+## Install Node.js using fnm
+
+[`fnm`](https://github.com/Schniz/fnm) (Fast Node Manager) is a modern, cross-platform Node.js version manager written in Rust. It has become increasingly popular due to its speed and simplicity. Unlike `n`, fnm works on Windows, macOS, and Linux.
+
+### Installing fnm
+
+On macOS with Homebrew:
+
+```bash
+brew install fnm
+```
+
+On Windows with Winget:
+
+```bash
+winget install Schniz.fnm
+```
+
+On Linux/macOS with the install script:
+
+```bash
+curl -fsSL https://fnm.vercel.app/install | bash
+```
+
+After installation, you need to set up your shell. Add the following to your shell configuration file (`.bashrc`, `.zshrc`, or equivalent):
+
+```bash
+eval "$(fnm env --use-on-cd)"
+```
+
+The `--use-on-cd` flag enables automatic version switching when you enter a directory with a `.node-version` or `.nvmrc` file.
+
+### Using fnm
+
+Here are the most common fnm commands:
+
+```bash
+# Install the latest LTS version
+fnm install --lts
+
+# Install a specific version
+fnm install 22
+
+# List installed versions
+fnm list
+
+# Use a specific version
+fnm use 22
+
+# Set a default version
+fnm default 22
+
+# Show current version
+fnm current
+```
+
+fnm also supports `.node-version` and `.nvmrc` files for per-project version management:
+
+```bash
+# Create a .node-version file in your project
+echo "22" > .node-version
+
+# fnm will automatically switch to this version when you cd into the directory
+# (if you enabled --use-on-cd in your shell setup)
+```
+
+### Why fnm is fast
+
+fnm is written in Rust and uses symbolic links instead of modifying your PATH for each version switch. This makes version switching nearly instantaneous, even when you have many versions installed.
+
+Here are the pros and cons of fnm:
+
+- 👍 **Blazingly fast** - written in Rust, version switching is nearly instant
+- 👍 **Cross-platform** - native support for Windows, macOS, and Linux
+- 👍 **Simple** - easy to install and use with a clean CLI
+- 👍 **Compatible** - supports `.nvmrc` files from nvm
+- 👍 **Automatic switching** - can automatically switch versions based on project configuration
+- 👎 Smaller community compared to nvm (but growing quickly)
+
 ## Install Node.js using nvm
 
 With more than 45 thousand stars on GitHub, [`nvm`](https://github.com/nvm-sh/nvm), which stands for "Node.js Version Manager" (no surprises!), is probably the most famous Node.js version manager currently available.
@@ -125,11 +214,10 @@ With more than 45 thousand stars on GitHub, [`nvm`](https://github.com/nvm-sh/nv
 The easiest way to install `nvm` on your system is to use the official installer script:
 
 ```bash
-VERSION=v0.37.2
-curl -o- "https://raw.githubusercontent.com/nvm-sh/nvm/${VERSION}/install.sh" | bash
+curl -o- "https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh" | bash
 ```
 
-**Note**: At the time of writing, version `v0.37.2` is the latest version available. Make sure to check out if there is any new version available if you are installing `nvm` following this tutorial.
+**Note**: Check the [nvm releases page](https://github.com/nvm-sh/nvm/releases) for the latest version available.
 
 Once `nvm` is installed in your system, here are some examples showing what you can do with it:
 
@@ -192,7 +280,63 @@ Finally, here are some pros and cons of `nvm`:
 - 👍 You can run once off commands on a given version of Node.js without having to switch the entire system to that version.
 - 👎 You might have to take a bit of time to go through the documentation and make sure you install it and use it correctly.
 
-**Note**: if you like to use version managers like `n` or `nvm`, you can also check out [`volta.sh`](https://volta.sh/), another interesting alternative in this space, which defines itself as _"The Hassle-Free JavaScript Tool Manager"_.
+## Install Node.js using Volta
+
+[Volta](https://volta.sh/) is a JavaScript tool manager that takes a different approach to version management. Instead of manually switching versions, Volta automatically detects and uses the right Node.js version based on your project's configuration.
+
+### Installing Volta
+
+On Unix systems (macOS, Linux):
+
+```bash
+curl https://get.volta.sh | bash
+```
+
+On Windows, download and run the installer from the [Volta website](https://volta.sh/).
+
+### Using Volta
+
+Volta's key feature is automatic version management through your `package.json`:
+
+```bash
+# Install a Node.js version
+volta install node@22
+
+# Pin a Node.js version to your project
+volta pin node@22
+```
+
+The `volta pin` command adds the Node.js version to your `package.json`:
+
+```json
+{
+  "volta": {
+    "node": "22.0.0"
+  }
+}
+```
+
+When anyone with Volta installed enters your project directory, Volta automatically uses the correct Node.js version without any manual intervention.
+
+```bash
+# Install npm or yarn globally (Volta manages these too)
+volta install npm
+volta install yarn
+
+# Pin package manager versions to your project
+volta pin npm@10
+```
+
+### Why choose Volta
+
+Volta excels at team environments where everyone needs to use the same tool versions:
+
+- 👍 **Zero configuration switching** - automatically uses the right version per project
+- 👍 **Team friendly** - versions stored in `package.json`, tracked in git
+- 👍 **Fast** - written in Rust, near-instant version switching
+- 👍 **Cross-platform** - works on Windows, macOS, and Linux
+- 👍 **Manages multiple tools** - handles Node.js, npm, and Yarn versions
+- 👎 Less flexibility for ad-hoc version testing compared to nvm/fnm
 
 ## Install Node.js using the official installer
 
@@ -300,7 +444,11 @@ Finally, here is the usual summary of pros and cons:
 
 ## Node.js with Docker
 
-If you just want to "play" a bit with a Node.js REPL, you don't need to install Node.js in your system. If you have `docker` installed in your system, running a Node.js REPL in a container is as easy as running:
+Docker is an excellent option both for quick experiments and for production deployments. If you have Docker installed, you can run Node.js without installing it on your system.
+
+### Quick experiments with Docker
+
+Run a Node.js REPL instantly:
 
 ```bash
 docker run -it node
@@ -310,34 +458,88 @@ Here's a super quick demo:
 
 ![Running a Node.js REPL using Docker](./node-repl-with-docker.gif)
 
-If you want to run a shell in a container with Node.js and `npm` installed, then you can do the following:
+Run a shell with Node.js and npm available:
 
 ```bash
 docker run -it node bash
 ```
 
-This way you can install third-party modules using `npm`, create your own scripts and run them with `node`. When you close the session the container and all the generated files will be destroyed.
+Run a specific Node.js version:
+
+```bash
+# Run Node.js 22
+docker run -it node:22
+
+# Run Node.js 20 LTS
+docker run -it node:20-alpine
+```
+
+### Development with Docker
 
-This is the perfect environment for quick and dirty experiments.
+For development, you can mount your project directory into the container:
 
-Note, that you can also use Docker as a complete environment for development and not just for quick tests. Docker is actually great for keeping different Node.js version and other dependencies isolated on a per-project basis. Exploring this setup goes beyond the scope of this article, but there is ton of reference on the web about how you might use Docker for Node.js development.
+```bash
+# Run your project in a container
+docker run -it -v $(pwd):/app -w /app node:22 npm start
 
-## Node.js online
+# Or start a development shell
+docker run -it -v $(pwd):/app -w /app node:22 bash
+```
+
+### Docker Compose for Node.js development
+
+For a more complete development setup, create a `docker-compose.yml`:
+
+```yaml
+services:
+  app:
+    image: node:22-alpine
+    working_dir: /app
+    volumes:
+      - .:/app
+      - node_modules:/app/node_modules
+    ports:
+      - '3000:3000'
+    command: npm run dev
+
+volumes:
+  node_modules:
+```
+
+Then start your development environment with:
+
+```bash
+docker compose up
+```
 
-But what if you don't have docker installed and still want to have an environment where you can write and run some Node.js code?
+This approach keeps Node.js versions isolated per project and ensures everyone on your team uses the same environment. Check out our detailed guide on [Node.js Development with Docker and Docker Compose](/blog/node-js-development-with-docker-and-docker-compose) for more advanced setups.
 
-Well, there is no shortage of platforms online that will give you a Node.js environment and an IDE that you can use to write and run JavaScript online.
+### Pros and cons of Docker for Node.js
 
-These environments often offer delightful additional features like collaborative edit and the possibility to host and share your applications.
+- 👍 **Perfect isolation** - each project can have its own Node.js version and dependencies
+- 👍 **Reproducible environments** - same setup for development, CI, and production
+- 👍 **No system pollution** - nothing installed on your host machine
+- 👍 **Easy cleanup** - remove containers when done
+- 👎 Additional complexity compared to version managers
+- 👎 Requires Docker to be installed and running
+- 👎 Slight performance overhead (especially on macOS/Windows)
 
-Here's a non-exhaustive list of services that you might want to try if you just need a quick way to write and share some Node.js examples:
+## Node.js online
 
-- [CodeSandbox](https://codesandbox.io/)
-- [Repl.it](https://repl.it/)
-- [Glitch](https://glitch.com/)
-- [Stackblitz](https://stackblitz.com/)
+If you don't want to install anything locally, several cloud-based development environments provide Node.js out of the box.
 
-Most of these services offer a quite generous free plan, so you only need to sign up to start coding!
+These platforms offer features like collaborative editing, instant deployment, and the ability to share your projects easily.
+
+Here are some popular options:
+
+- [StackBlitz](https://stackblitz.com/) - Runs Node.js directly in your browser using WebContainers technology
+- [CodeSandbox](https://codesandbox.io/) - Feature-rich cloud IDE with great npm integration
+- [GitHub Codespaces](https://github.com/features/codespaces) - Full VS Code environment in the cloud
+- [Gitpod](https://gitpod.io/) - Cloud development environments from any Git repository
+- [Replit](https://replit.com/) - Simple and beginner-friendly online IDE
+- [Glitch](https://glitch.com/) - Great for quick prototypes and learning
+
+Most of these services offer generous free tiers, making them perfect for learning, prototyping, or quick experiments.
 
 ## Conclusion
 
@@ -345,6 +547,12 @@ This concludes our list of ways to install Node.js. At this point, I hope you fe
 
 If you enjoyed this article please consider sharing it and don't hesitate to reach out to me [on Twitter](https://twitter.com/loige). I am quite curious to find out what is your favourite way to install Node.js and why!
 
+:::tip[Ready to Master Node.js?]
+Now that you have Node.js installed, take your skills to the next level with **Node.js Design Patterns**. Learn async patterns, streams, scalable architectures, and more.
+
+[Get a FREE chapter →](/#free-chapter)
+:::
+
 Until next time!
 
 ### Credits
diff --git a/src/content/blog/javascript-async-iterators/index.md b/src/content/blog/javascript-async-iterators/index.md
index 14d6448..3ce182f 100644
--- a/src/content/blog/javascript-async-iterators/index.md
+++ b/src/content/blog/javascript-async-iterators/index.md
@@ -1,6 +1,6 @@
 ---
 date: 2021-05-04T13:10:00
-updatedAt: 2021-05-04T13:10:00
+updatedAt: 2026-01-29T12:00:00
 title: JavaScript async iterators
 slug: javascript-async-iterators
 description: An in-depth exploration of JavaScript iteration protocols with a special focus on async iterators
@@ -564,7 +564,7 @@ Synchronous iterable objects and the `for...of` syntax are quite widespread, so
 
 ### Node.js readable streams and async iterators
 
-One interesting detail that needs a bit more visibility is that Node.js _Readable_ streams are async iterable objects since Node.js 11.14.
+One interesting detail that needs a bit more visibility is that Node.js _Readable_ streams are async iterable objects since Node.js 11.14. For a comprehensive guide on reading and writing files in Node.js, including streams, check out our article on [Reading and Writing Files in Node.js](/blog/reading-writing-files-nodejs/).
 
 This basically means that we can consume data from a Readable stream using `for await...of`.
 
diff --git a/src/content/blog/node-js-development-with-docker-and-docker-compose/index.md b/src/content/blog/node-js-development-with-docker-and-docker-compose/index.md
index 1515612..a182b8f 100644
--- a/src/content/blog/node-js-development-with-docker-and-docker-compose/index.md
+++ b/src/content/blog/node-js-development-with-docker-and-docker-compose/index.md
@@ -1,6 +1,6 @@
 ---
 date: 2021-04-07T18:00:00
-updatedAt: 2021-04-07T18:00:00
+updatedAt: 2026-01-29T12:00:00
 title: Node.js development with Docker and Docker Compose
 slug: node-js-development-with-docker-and-docker-compose
 description: Using Docker and Docker Compose to develop Node.js projects can be a good option, especially if working in a team. This article provides a walk-through a possible setup and discuss pros and cons of this approach
@@ -392,6 +392,12 @@ That's all! Hopefully you found this article interesting and you will decide to
 
 You can check out the code examples in the following repository: https://github.com/giuseppemorelli/docker-node-example. If you liked this article, please consider giving it a star, everyone needs some vanity metrics, after all! :)
 
+:::tip[Take Your Node.js Skills Further]
+Whether you're using Docker or not, understanding Node.js patterns and best practices is essential. **Node.js Design Patterns** covers async patterns, streams, scalable architectures, and more.
+
+[Get a FREE chapter →](/#free-chapter)
+:::
+
 ## About the author
 
 Giuseppe Morelli is the guest author of this post. This is Giuseppe's bio.
diff --git a/src/content/blog/node-js-race-conditions/index.md b/src/content/blog/node-js-race-conditions/index.md
index 9b19e6e..03513bc 100644
--- a/src/content/blog/node-js-race-conditions/index.md
+++ b/src/content/blog/node-js-race-conditions/index.md
@@ -1,11 +1,20 @@
 ---
 date: 2021-01-24T18:35:00
-updatedAt: 2021-01-24T19:35:00
+updatedAt: 2026-01-29T12:00:00
 title: Node.js race conditions
 slug: node-js-race-conditions
 description: Can there be race conditions with Node.js? Actually yes, let's see some examples and some solutions.
 authors: ['luciano-mammino']
 tags: ['blog']
+faq:
+  - question: Can Node.js have race conditions even though it's single-threaded?
+    answer: Yes, Node.js can have race conditions despite being single-threaded. While multiple threads don't compete for resources, asynchronous operations from different logical transactions can be scheduled on the event loop and interleaved, causing stale reads and inconsistent data.
+  - question: What is a mutex in Node.js?
+    answer: A mutex (mutual exclusion) is a synchronization mechanism that allows exclusive access to a shared resource. In Node.js, you can use libraries like async-mutex or implement a simple mutex using promise chaining to ensure only one operation accesses a critical section at a time.
+  - question: How do I fix race conditions in Node.js?
+    answer: You can fix race conditions by serializing access to shared resources using techniques like mutexes, promise chaining, or relying on database-level transactions. The key is ensuring that operations that read and modify shared data complete atomically without interleaving.
+  - question: Does using a mutex affect Node.js performance?
+    answer: Yes, using a mutex can impact performance because it serializes operations that would otherwise run concurrently. Tasks must wait in line for exclusive access, which can slow down your application. Use mutexes sparingly and keep critical paths as short as possible.
 ---
 
 A single-threaded event loop like the one used by JavaScript and Node.js, makes it somewhat harder to have race conditions, but, SPOILER ALERT: race conditions are still possible!
@@ -157,7 +166,7 @@ This approach is similar to writing the following code:
 await Promise.all([sellGrapes(), sellOlives()])
 ```
 
-Using `Promise.all()` is a more commonly used way to schedule different tasks to run concurrently.
+Using `Promise.all()` is a more commonly used way to schedule different tasks to run concurrently. If you want to learn more about JavaScript async patterns including async iterators, check out our article on [JavaScript async iterators](/blog/javascript-async-iterators/).
 
 Note that with `Promise.all()`, the resulting promise will reject as soon as any of the promises rejects. In our previous example, since we await the two promises independently, we will always catch errors in `transaction1` before `transaction2`.
 
diff --git a/src/content/blog/nodejs-http-request/index.md b/src/content/blog/nodejs-http-request/index.md
new file mode 100644
index 0000000..6312aa5
--- /dev/null
+++ b/src/content/blog/nodejs-http-request/index.md
@@ -0,0 +1,923 @@
+---
+date: 2026-01-29T16:30:00
+updatedAt: 2026-01-29T12:00:00
+title: How to make an HTTP request in Node.js
+slug: nodejs-http-request
+description: Learn to make HTTP requests in Node.js using built-in fetch(), http/https modules. Covers POST, authentication, streaming, and testing with code examples.
+authors: ['luciano-mammino']
+tags: ['blog']
+faq:
+  - question: What is the easiest way to make an HTTP request in Node.js?
+    answer: The easiest way is using the built-in fetch() API, available since Node.js 18. Simply call fetch(url) and await the response. No external packages are required.
+  - question: Does Node.js have a built-in fetch function?
+    answer: Yes, since Node.js 18, fetch() is available as a built-in global function. You don't need to install any packages like node-fetch or axios to make HTTP requests.
+  - question: How do I make a POST request with JSON in Node.js?
+    answer: Use fetch() with method set to POST, set the Content-Type header to application/json, and pass your data through JSON.stringify() in the body option.
+  - question: When should I use http/https modules instead of fetch?
+    answer: For most use cases, use fetch(). The http/https modules are primarily useful when (1) working with Node.js versions before 18, (2) maintaining legacy codebases, or (3) integrating with libraries that expect http.IncomingMessage or http.ClientRequest objects. Modern fetch() supports streaming too, so that's no longer a reason to prefer the older modules.
+  - question: Do I need axios or got to make HTTP requests in Node.js?
+    answer: No, modern Node.js (18+) includes a built-in fetch() API that handles most use cases. External libraries like axios or got are optional and mainly useful for advanced features like automatic retries, request interceptors, or progress events.
+---
+
+Making HTTP requests is one of the most common tasks in Node.js development. Whether you're calling a REST API, fetching data from an external service, or building a web scraper, you'll need to know how to make HTTP requests effectively.
+
+The good news is that modern Node.js includes everything you need to make HTTP requests without installing any external packages. If you've done HTTP requests in the browser before, what you'll learn today will feel very familiar. In this guide, we'll explore the built-in options and when to use each one.
+
+:::note[Prerequisites]
+The examples in this guide use **top-level `await`**, which requires ESM (ECMAScript Modules). To use these examples, either:
+
+- Set `"type": "module"` in your `package.json`, or
+- Use the `.mjs` file extension
+
+All examples assume Node.js 18 or later.
+:::
+
+## Quick Answer: Use `fetch()`
+
+I get it, you don't have time to become an expert on everything there's to know about making HTTP requests with Node.js, so here's the quick answer you might be looking for.
+
+If you're using Node.js 18 or later, the simplest way to make an HTTP request is with the built-in `fetch()` function:
+
+```javascript
+const response = await fetch('https://api.example.com/data')
+const data = await response.json()
+console.log(data)
+```
+
+That's it. No packages to install, no complex setup. But if you ship this to production, you might run into problems: hanging requests, silent failures, memory leaks from unhandled streams, and more. Keep reading to learn the patterns that will give you confidence when shipping code that makes HTTP requests to production.
+
+## Using the Built-in `fetch()` API
+
+As we just said, `fetch()` is the recommended way to make HTTP requests in modern Node.js. Let's dive into the extra details you need to use it effectively.
+
+Since Node.js 18, the `fetch()` API is available globally without any imports. This is the same `fetch()` you might know from browser JavaScript, making it familiar and easy to use.
+
+### Basic GET Request
+
+```javascript
+// fetch-get.js
+try {
+  const response = await fetch('https://jsonplaceholder.typicode.com/posts/1')
+
+  if (!response.ok) {
+    throw new Error(`HTTP error! status: ${response.status}`)
+  }
+
+  const data = await response.json()
+  console.log('Post title:', data.title)
+} catch (error) {
+  console.error('Failed to fetch:', error.message)
+}
+```
+
+A few important points about this example:
+
+- `fetch()` returns a Promise that resolves to a Response object
+- The promise only rejects on network errors, not on semantic HTTP errors (4xx, 5xx). This distinction matters: **network errors** mean the request couldn't be completed at all (DNS failures, connection refused, timeouts), while **semantic HTTP errors** mean the request reached the server and got a valid HTTP response, but that response indicates something went wrong, either a client error (4xx) or a server error (5xx)
+- Always check `response.ok` to handle semantic HTTP errors
+- Use `.json()`, `.text()`, or `.blob()` to parse the response body and load it into memory
+
+:::tip[Why does fetch require two steps?]
+Some HTTP libraries hide this complexity and give you the full response body in one call, so why does fetch make you do it in two steps? This is because the HTTP protocol splits responses into headers and body.
+
+The first `fetch()` call establishes the connection, sends the request, and parses **only the headers**. At this point, you can check the status code and decide whether to continue reading from the underlying socket. If the status is bad, you can stop right there and save bandwidth.
+
+The body might be huge (think _downloading_ a video file or an AI model file!), so you get to choose how to read it:
+
+- **Stream the response in chunks** (e.g. to a file), ideal for large response bodies
+- **Load as binary, text, or JSON** for small responses (a few MBs max)
+  :::
+
+### POST Request with JSON Body
+
+POST requests are used when you need to attach data to your request. The request will have a body containing your payload, and the encoding depends on what the server expects. You tell the server how your data is encoded using the `Content-Type` header.
+
+In this example, we use JSON (`application/json`), which is the most common format for APIs. Other common content types include:
+
+- `multipart/form-data` for file uploads
+- `application/x-www-form-urlencoded` for traditional HTML form submissions
+
+```javascript
+// fetch-post.js
+try {
+  const response = await fetch('https://jsonplaceholder.typicode.com/posts', {
+    method: 'POST',
+    headers: {
+      'Content-Type': 'application/json',
+    },
+    body: JSON.stringify({
+      title: 'My New Post',
+      body: 'This is the content of my post.',
+      userId: 1,
+    }),
+  })
+
+  if (!response.ok) {
+    throw new Error(`HTTP error! status: ${response.status}`)
+  }
+
+  const data = await response.json()
+  console.log('Created post:', data)
+} catch (error) {
+  console.error('Failed to create post:', error.message)
+}
+```
+
+### Adding Headers and Authentication
+
+In the previous section, we already saw how to add headers to specify the content type. But there are other important use cases for headers, especially authentication.
+
+```javascript
+// fetch-auth.js
+const token = process.env.API_TOKEN
+
+try {
+  const response = await fetch('https://api.example.com/protected', {
+    headers: {
+      Authorization: `Bearer ${token}`,
+      Accept: 'application/json',
+      'X-Custom-Header': 'custom-value',
+    },
+  })
+
+  if (response.status === 401) {
+    throw new Error('Unauthorized: Check your API token')
+  }
+
+  if (!response.ok) {
+    throw new Error(`HTTP error! status: ${response.status}`)
+  }
+
+  const data = await response.json()
+  console.log(data)
+} catch (error) {
+  console.error('Request failed:', error.message)
+}
+```
+
+The `Authorization: Bearer <token>` pattern shown above is called Bearer token authentication, defined in [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750). It's the most common authentication method for REST APIs.
+
+Some services like AWS use more complex authentication schemes. For example, [AWS Signature V4](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html) uses special headers like `Credential`, `SignedHeaders`, and `Signature` to sign requests.
+
+In the snippet above you might be wondering what the `Accept` header is for. The `Accept` header tells the server what response format you prefer. For instance, some servers can return data as JSON, XML, or plain text depending on this header. For example, this is particularly useful when working with LLM-optimized APIs and websites. Without the right Accept header, they might default to verbose HTML format, making you burn precious tokens. Learn more about the [Accept header on MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept).
+
+### Setting Timeouts
+
+It's good practice not to let requests hang forever. This is especially important when HTTP requests are on the critical path of your workflows, a hanging request can slow down everything downstream.
+
+Modern Node.js provides a simple way to add timeouts using `AbortSignal.timeout()`:
+
+```javascript
+// fetch-timeout.js
+try {
+  const response = await fetch('https://api.example.com/data', {
+    signal: AbortSignal.timeout(5000), // Abort after 5 seconds
+  })
+
+  if (!response.ok) {
+    throw new Error(`HTTP error! status: ${response.status}`)
+  }
+
+  const data = await response.json()
+  console.log(data)
+} catch (error) {
+  if (error.name === 'TimeoutError') {
+    console.error('Request timed out')
+  } else {
+    console.error('Request failed:', error.message)
+  }
+}
+```
+
+`AbortSignal.timeout()` is available since Node.js 18 (or 17.3+).
+
+### Handling Different Response Types
+
+Remember the two-step process we discussed earlier? Here are some shorthand approaches for common scenarios:
+
+```javascript
+// fetch-response-types.js
+
+// JSON response
+const jsonData = await fetch(url).then((res) => res.json())
+
+// Text response (HTML, plain text)
+const textData = await fetch(url).then((res) => res.text())
+
+// Binary data (images, files)
+const blobData = await fetch(url).then((res) => res.blob())
+const arrayBuffer = await fetch(url).then((res) => res.arrayBuffer())
+
+// Get response headers
+const response = await fetch(url)
+console.log('Content-Type:', response.headers.get('Content-Type'))
+console.log('All headers:', Object.fromEntries(response.headers))
+```
+
+The `.then()` syntax is equivalent to a second `await`, but it allows you to write concise one-liners when you don't need to check the response status first.
+
+### Streaming Requests and Responses
+
+When dealing with large request bodies (like uploading a video file) or large response bodies (like downloading a dataset), you don't want to load everything into memory at once. Loading large payloads into memory can slow down your process or even crash it when it runs out of memory. For reliable systems, you want to keep memory usage constant and predictable regardless of the payload size. Streaming lets you process data in chunks as it flows through, using only a small buffer at any given time.
+
+#### Streaming Uploads
+
+To upload a large file without loading it entirely into memory, you can stream the file directly as the request body:
+
+```javascript
+// fetch-stream-upload.js
+import { createReadStream } from 'node:fs'
+import { stat } from 'node:fs/promises'
+
+async function uploadLargeFile(url, filePath) {
+  const fileStats = await stat(filePath)
+  const fileStream = createReadStream(filePath)
+
+  const response = await fetch(url, {
+    method: 'PUT',
+    headers: {
+      'Content-Type': 'application/octet-stream',
+      'Content-Length': fileStats.size.toString(),
+    },
+    body: fileStream,
+    duplex: 'half', // Required for streaming request bodies
+  })
+
+  if (!response.ok) {
+    throw new Error(`Upload failed: ${response.status}`)
+  }
+
+  return response.json()
+}
+
+// Usage
+await uploadLargeFile('https://api.example.com/upload', './large-video.mp4')
+```
+
+The `duplex: 'half'` option is required when using a stream as the request body. It tells fetch that we're sending data in one direction while potentially receiving data in the other.
+
+#### Streaming Downloads
+
+For large responses, you might want to process data as it arrives rather than waiting for the entire response. The `response.body` property gives you access to a `ReadableStream`:
+
+```javascript
+// fetch-stream.js
+const response = await fetch('https://example.com/large-file')
+
+if (!response.ok) {
+  throw new Error(`HTTP error! status: ${response.status}`)
+}
+
+// response.body is a ReadableStream
+const reader = response.body.getReader()
+const decoder = new TextDecoder()
+
+while (true) {
+  const { done, value } = await reader.read()
+  if (done) break
+
+  const chunk = decoder.decode(value, { stream: true })
+  process.stdout.write(chunk)
+}
+```
+
+This approach is useful for processing [NDJSON streams](https://en.wikipedia.org/wiki/JSON_streaming), [Server-Sent Events (SSE)](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events), or any large response where you want to show progress or process data incrementally. For more advanced patterns, check out our guide on [JavaScript Async Iterators](/blog/javascript-async-iterators/).
+
+For downloading files, you can pipe the response directly to disk using `Readable.fromWeb()`:
+
+```javascript
+// fetch-download.js
+import { createWriteStream } from 'node:fs'
+import { Readable } from 'node:stream'
+import { pipeline } from 'node:stream/promises'
+
+const response = await fetch('https://example.com/large-file.zip')
+
+if (!response.ok) {
+  throw new Error(`HTTP error! status: ${response.status}`)
+}
+
+const nodeStream = Readable.fromWeb(response.body)
+await pipeline(nodeStream, createWriteStream('./download.zip'))
+console.log('Download complete!')
+```
+
+## Making Multiple Concurrent Requests
+
+When you need to make multiple HTTP requests, you can run them concurrently for better performance:
+
+```javascript
+// concurrent-requests.js
+async function fetchMultipleUsers(userIds) {
+  const requests = userIds.map((id) =>
+    fetch(`https://jsonplaceholder.typicode.com/users/${id}`).then((res) =>
+      res.json(),
+    ),
+  )
+
+  // Wait for all requests to complete
+  const users = await Promise.all(requests)
+  return users
+}
+
+// Usage
+const users = await fetchMultipleUsers([1, 2, 3, 4, 5])
+console.log(`Fetched ${users.length} users`)
+users.forEach((user) => console.log(`- ${user.name}`))
+```
+
+If some requests might fail but you want to continue with the successful ones, use `Promise.allSettled()`:
+
+```javascript
+// concurrent-requests-settled.js
+async function fetchMultipleWithFallback(urls) {
+  const requests = urls.map((url) => fetch(url).then((res) => res.json()))
+
+  const results = await Promise.allSettled(requests)
+
+  return results.map((result, index) => {
+    if (result.status === 'fulfilled') {
+      return { url: urls[index], data: result.value, error: null }
+    } else {
+      return { url: urls[index], data: null, error: result.reason.message }
+    }
+  })
+}
+```
+
+When dealing with a large number of items (hundreds or thousands), firing all requests at once can overwhelm the server or exhaust your system's resources. In these cases, you need **limited concurrency**: running requests concurrently but with a maximum number of requests in flight at any given time. In **[Node.js Design Patterns](/)**, we dedicate multiple chapters to this topic, showing how to implement these patterns using callbacks, promises, and async/await. You might also want to read about [Node.js Race Conditions](/blog/node-js-race-conditions/) to understand common concurrency pitfalls.
+
+## Handling Common Scenarios
+
+### Retrying Failed Requests
+
+Network requests can fail for many transient reasons: the server might be temporarily overloaded, a network blip might interrupt the connection, you might hit a rate limit, or a downstream service might be restarting. These failures are often temporary, and the same request might succeed if you just try again.
+
+Implementing a retry mechanism is good practice for most HTTP requests, especially for critical operations. Here's a simple retry helper:
+
+```javascript
+// fetch-retry.js
+async function fetchWithRetry(url, options = {}, maxRetries = 3) {
+  let lastError
+
+  for (let attempt = 1; attempt <= maxRetries; attempt++) {
+    try {
+      const response = await fetch(url, options)
+
+      if (!response.ok) {
+        throw new Error(`HTTP error! status: ${response.status}`)
+      }
+
+      return await response.json()
+    } catch (error) {
+      lastError = error
+      console.log(`Attempt ${attempt} failed: ${error.message}`)
+
+      if (attempt < maxRetries) {
+        // Exponential backoff: wait longer between retries
+        const delay = Math.pow(2, attempt) * 100
+        await new Promise((resolve) => setTimeout(resolve, delay))
+      }
+    }
+  }
+
+  throw new Error(`Failed after ${maxRetries} attempts: ${lastError.message}`)
+}
+```
+
+This `fetchWithRetry` helper wraps `fetch()` and automatically retries failed requests up to `maxRetries` times. It uses exponential backoff between attempts (200ms, 400ms, 800ms...), giving the server time to recover. Both network errors and non-OK HTTP responses trigger a retry.
+
+Note that this example is opinionated: it always parses the response as JSON and treats any non-OK status code as an error worth retrying. For a more flexible approach, you could return the raw response and let the caller decide how to parse it, or add logic to only retry on specific status codes (like 429 Too Many Requests or 503 Service Unavailable).
+
+:::caution[Idempotency Warning]
+This retry helper works best with **idempotent** GET requests. For POST/PUT/DELETE requests, retrying may cause duplicate side effects (like creating multiple orders). Additionally, if `options.body` is a stream, it can only be consumed once and retries will fail. For non-idempotent operations, either disable retries or implement request-specific retry logic.
+:::
+
+### Form Data and File Uploads
+
+The earlier [Streaming Uploads](#streaming-uploads) section shows how to stream a file as raw bytes, where the entire request body is just the file content. That approach works when the API accepts a raw binary body, but most real-world APIs expect the `multipart/form-data` format instead. This format follows web standards (it's the same encoding used by HTML forms with `enctype="multipart/form-data"`) and lets you include metadata fields like descriptions, tags, or user IDs alongside the file.
+
+To send `multipart/form-data` requests, use the `FormData` API:
+
+```javascript
+// fetch-upload.js
+import { readFile } from 'node:fs/promises'
+
+async function uploadFile(url, filePath) {
+  const fileContent = await readFile(filePath)
+
+  const formData = new FormData()
+  formData.append('file', new Blob([fileContent]), 'upload.txt')
+  formData.append('description', 'My uploaded file')
+
+  const response = await fetch(url, {
+    method: 'POST',
+    body: formData,
+    // Note: Don't set Content-Type header - fetch will set it automatically
+    // with the correct boundary for multipart/form-data
+  })
+
+  if (!response.ok) {
+    throw new Error(`Upload failed: ${response.status}`)
+  }
+
+  return await response.json()
+}
+```
+
+:::caution[Memory usage warning]
+This example uses `readFile()` which loads the entire file into memory before uploading. This works fine for small files (a few megabytes), but will cause problems with large files. Your process might slow down or crash if you try to upload a multi-gigabyte video this way.
+
+For large file uploads, see the streaming approach below.
+:::
+
+#### Streaming Large Files with FormData
+
+To avoid loading large files into memory while still using `multipart/form-data`, you can create a file-like object with a `stream()` method:
+
+```javascript
+// fetch-upload-stream-formdata.js
+import { createReadStream } from 'node:fs'
+import { basename } from 'node:path'
+
+async function uploadLargeFileWithFormData(url, filePath, metadata) {
+  const fileName = basename(filePath)
+
+  const formData = new FormData()
+
+  // Add metadata fields alongside the file
+  formData.append('description', metadata.description)
+  formData.append('category', metadata.category)
+
+  // Add the file as a stream (not loaded into memory)
+  formData.append('file', {
+    [Symbol.toStringTag]: 'File',
+    name: fileName,
+    stream: () => createReadStream(filePath),
+  })
+
+  const response = await fetch(url, {
+    method: 'POST',
+    body: formData,
+  })
+
+  if (!response.ok) {
+    throw new Error(`Upload failed: ${response.status}`)
+  }
+
+  return response.json()
+}
+
+// Usage
+await uploadLargeFileWithFormData(
+  'https://api.example.com/videos',
+  './large-video.mp4',
+  { description: 'My vacation video', category: 'travel' },
+)
+```
+
+The trick here is creating a file-like object with a `stream()` method that returns a readable stream. Node.js's `fetch()` (powered by undici) recognizes this pattern and streams the file content instead of loading it into memory. The `[Symbol.toStringTag]: 'File'` property makes FormData accept the object as a valid file.
+
+:::note
+This technique is specific to Node.js and relies on how undici handles file-like objects. It won't work in browsers, which have their own `File` API.
+:::
+
+### Handling URL Query Parameters
+
+When building URLs with query parameters, it's tempting to concatenate strings manually: `` `${baseUrl}?query=${userInput}` ``. This is dangerous. If `userInput` contains special characters like `&`, `=`, or `#`, your URL will break or behave unexpectedly. Worse, if the input comes from users, attackers could inject additional parameters or manipulate the URL structure.
+
+Always use the `URL` and `URLSearchParams` APIs to build URLs safely. They handle encoding automatically:
+
+```javascript
+// fetch-query-params.js
+function buildUrl(baseUrl, params) {
+  const url = new URL(baseUrl)
+
+  for (const [key, value] of Object.entries(params)) {
+    if (value !== undefined && value !== null) {
+      url.searchParams.append(key, value)
+    }
+  }
+
+  return url.toString()
+}
+
+// Usage
+const url = buildUrl('https://api.example.com/search', {
+  query: 'node.js',
+  page: 1,
+  limit: 20,
+  sort: 'date',
+})
+
+console.log(url)
+// https://api.example.com/search?query=node.js&page=1&limit=20&sort=date
+
+const response = await fetch(url)
+```
+
+The `buildUrl` helper creates a `URL` object and uses `searchParams.append()` to add each parameter. This automatically encodes special characters. For example, a query like `"c++ & c#"` becomes `c%2B%2B%20%26%20c%23`, ensuring the URL remains valid and secure. The helper also skips `undefined` and `null` values, which is useful when some parameters are optional.
+
+## Testing with Mocked HTTP Requests
+
+When writing unit tests for code that makes HTTP requests, you don't want to hit real APIs. Mocking lets you control responses, test error scenarios, and run tests quickly without network dependencies.
+
+Node.js's `fetch()` is powered by [undici](https://undici.nodejs.org/), which provides `MockAgent` for intercepting requests. While undici powers the built-in `fetch()`, the mocking utilities aren't exposed as globals. You need to install undici as a dependency to access them:
+
+```bash
+npm install undici --save-dev
+```
+
+:::important
+Even though `fetch()` is built into Node.js, the `MockAgent` and other testing utilities come from the undici package, which you must install separately.
+:::
+
+Combined with the built-in test runner, you can write effective unit tests without external mocking libraries.
+
+### Basic Mocking with MockAgent
+
+Let's say you have a function that fetches user data:
+
+```javascript
+// user-service.js
+export async function getUser(id) {
+  const response = await fetch(`https://api.example.com/users/${id}`)
+
+  if (!response.ok) {
+    throw new Error(`Failed to fetch user: ${response.status}`)
+  }
+
+  return response.json()
+}
+```
+
+Here's how to test it with mocked responses:
+
+```javascript
+// user-service.test.js
+import assert from 'node:assert/strict'
+import { afterEach, beforeEach, describe, it } from 'node:test'
+import { MockAgent, setGlobalDispatcher, getGlobalDispatcher } from 'undici'
+import { getUser } from './user-service.js'
+
+describe('getUser', () => {
+  let mockAgent
+  let originalDispatcher
+
+  beforeEach(() => {
+    originalDispatcher = getGlobalDispatcher()
+    mockAgent = new MockAgent()
+    mockAgent.disableNetConnect() // Prevent accidental real requests
+    setGlobalDispatcher(mockAgent)
+  })
+
+  afterEach(async () => {
+    await mockAgent.close()
+    setGlobalDispatcher(originalDispatcher) // Restore original dispatcher
+  })
+
+  it('returns user data for valid id', async () => {
+    const mockUser = { id: 1, name: 'Alice', email: 'alice@example.com' }
+
+    mockAgent
+      .get('https://api.example.com')
+      .intercept({ path: '/users/1', method: 'GET' })
+      .reply(200, mockUser)
+
+    const user = await getUser(1)
+
+    assert.deepEqual(user, mockUser)
+  })
+
+  it('throws an error when user not found', async () => {
+    mockAgent
+      .get('https://api.example.com')
+      .intercept({ path: '/users/999', method: 'GET' })
+      .reply(404, { error: 'Not found' })
+
+    await assert.rejects(() => getUser(999), {
+      message: 'Failed to fetch user: 404',
+    })
+  })
+})
+```
+
+The `afterEach` cleanup is important: it closes the mock agent (releasing resources) and restores the original dispatcher. This prevents test pollution where mocks from one test leak into another, and avoids resource leaks if you're running many tests. The `disableNetConnect()` call adds an extra safety net by ensuring tests fail fast if they accidentally try to make real HTTP requests.
+
+Let's break down what's happening in this test file. We import `describe`, `it`, and `beforeEach` from Node.js's built-in test runner (`node:test`), along with `assert` for assertions. In the `beforeEach` hook, we create a fresh `MockAgent` and register it as the global dispatcher using `setGlobalDispatcher()`. This tells undici (and therefore `fetch()`) to route all requests through our mock.
+
+Each test then uses `mockAgent.get()` to target a specific origin, `.intercept()` to match a path and method, and `.reply()` to define the mocked response. When our `getUser()` function calls `fetch()`, it gets the mocked response instead of making a real network request.
+
+Run the test with:
+
+```bash
+node --test user-service.test.js
+```
+
+### Mocking POST Requests
+
+You can mock POST requests the same way. This is useful for testing functions that create or update resources:
+
+```javascript
+// api-client.test.js
+it('creates a new post', async () => {
+  const newPost = { title: 'Hello', body: 'World', userId: 1 }
+  const createdPost = { id: 42, ...newPost }
+
+  mockAgent
+    .get('https://api.example.com')
+    .intercept({ path: '/posts', method: 'POST' })
+    .reply(201, createdPost)
+
+  const response = await fetch('https://api.example.com/posts', {
+    method: 'POST',
+    headers: { 'Content-Type': 'application/json' },
+    body: JSON.stringify(newPost),
+  })
+
+  const data = await response.json()
+  assert.equal(data.id, 42)
+})
+```
+
+## Best Practices
+
+Now that we've covered the mechanics of making HTTP requests, let's consolidate the key practices that will help you write reliable, maintainable code. These guidelines apply whether you're using `fetch()` or any other HTTP library.
+
+1. **Always handle errors**: Network requests can fail. Use try/catch and check response status codes.
+
+2. **Set timeouts**: Don't let requests hang indefinitely. Use AbortController or library timeout options.
+
+3. **Validate responses**: Don't assume the response structure. Validate before accessing properties.
+
+4. **Use environment variables for URLs and tokens**: Never hardcode API keys or sensitive URLs.
+
+5. **Consider rate limiting**: Respect API rate limits. Implement backoff strategies for retries.
+
+6. **Log requests in development**: Add logging to debug issues, but be careful not to log sensitive data.
+
+Here's an example wrapper function that demonstrates these practices:
+
+```javascript
+// Example: Wrapper with best practices
+async function apiRequest(endpoint, options = {}) {
+  // [Practice #4] Load sensitive values from environment variables
+  const baseUrl = process.env.API_BASE_URL
+  const token = process.env.API_TOKEN
+
+  // [Practice #1] Wrap in try/catch to handle errors
+  try {
+    const response = await fetch(`${baseUrl}${endpoint}`, {
+      ...options,
+      signal: AbortSignal.timeout(10000), // [Practice #2] Set 10s timeout
+      headers: {
+        Authorization: `Bearer ${token}`, // [Practice #4] Use env var for token
+        'Content-Type': 'application/json',
+        ...options.headers,
+      },
+    })
+
+    // [Practice #1] Check response status and handle errors
+    if (!response.ok) {
+      const errorBody = await response.text()
+      throw new Error(`API error ${response.status}: ${errorBody}`)
+    }
+
+    // [Practice #3] Parse response (caller should validate structure)
+    return await response.json()
+  } catch (error) {
+    // [Practice #2] Handle timeout specifically
+    if (error.name === 'TimeoutError') {
+      throw new Error(`Request to ${endpoint} timed out`)
+    }
+
+    throw error
+  }
+}
+```
+
+## When to Use External Libraries
+
+While Node.js built-ins handle most use cases, external libraries like [axios](https://axios-http.com/), [got](https://github.com/sindresorhus/got), or [ky](https://github.com/sindresorhus/ky) offer additional features:
+
+- **Automatic retries** with configurable strategies
+- **Request/response interceptors** for logging, auth token refresh
+- **Progress events** for large uploads/downloads
+- **Built-in timeout handling** without AbortController boilerplate
+- **Proxy support** out of the box
+- **Request cancellation** with simpler APIs
+
+For simple applications, stick with built-in `fetch()`. Consider external libraries when you need their specific features or want to reduce boilerplate in complex applications.
+
+## Using the `http` and `https` Modules
+
+The examples above all use `fetch()`, which is the recommended approach for modern Node.js. However, you may encounter or need to use the lower-level `http`/`https` modules in these scenarios:
+
+- **Working with Node.js versions before 18** where `fetch()` isn't available
+- **Integrating with libraries** that expect `http.IncomingMessage` or `http.ClientRequest` objects
+- **Migrating legacy codebases** gradually to modern patterns
+- **Advanced use cases** requiring direct access to the underlying socket or connection
+
+The `node:http` and `node:https` modules have been part of Node.js since its early days, and you'll still encounter them in many codebases. These are lower-level APIs that give you direct access to the request and response streams.
+
+What's the difference between the two? The `http` module is for plain HTTP connections (typically port 80), while `https` is for encrypted TLS/SSL connections (typically port 443). For most real-world APIs, you'll use `https` since modern services require encrypted connections.
+
+### Basic GET Request with `https`
+
+```javascript
+// http-get.js
+import https from 'node:https'
+
+function httpsGet(url) {
+  return new Promise((resolve, reject) => {
+    https
+      .get(url, (response) => {
+        // Handle redirects
+        if (
+          response.statusCode >= 300 &&
+          response.statusCode < 400 &&
+          response.headers.location
+        ) {
+          return resolve(httpsGet(response.headers.location))
+        }
+
+        if (response.statusCode !== 200) {
+          reject(new Error(`HTTP error! status: ${response.statusCode}`))
+          response.resume() // Consume response to free up memory
+          return
+        }
+
+        const chunks = []
+
+        response.on('data', (chunk) => chunks.push(chunk))
+
+        response.on('end', () => {
+          const body = Buffer.concat(chunks).toString()
+          resolve(JSON.parse(body))
+        })
+
+        response.on('error', reject)
+      })
+      .on('error', reject)
+  })
+}
+
+// Usage
+const data = await httpsGet('https://jsonplaceholder.typicode.com/posts/1')
+console.log('Post title:', data.title)
+```
+
+This approach requires more code than `fetch()`, but it gives you access to the raw stream and complete control over how data is processed.
+
+### POST Request with `http.request()`
+
+For POST requests and more control, use `http.request()`:
+
+```javascript
+// http-post.js
+import https from 'node:https'
+
+function httpsPost(url, data) {
+  return new Promise((resolve, reject) => {
+    const urlObj = new URL(url)
+    const postData = JSON.stringify(data)
+
+    const options = {
+      hostname: urlObj.hostname,
+      port: urlObj.port || 443,
+      path: urlObj.pathname + urlObj.search,
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+        'Content-Length': Buffer.byteLength(postData),
+      },
+    }
+
+    const req = https.request(options, (response) => {
+      const chunks = []
+
+      response.on('data', (chunk) => chunks.push(chunk))
+
+      response.on('end', () => {
+        const body = Buffer.concat(chunks).toString()
+
+        if (response.statusCode >= 200 && response.statusCode < 300) {
+          resolve(JSON.parse(body))
+        } else {
+          reject(new Error(`HTTP ${response.statusCode}: ${body}`))
+        }
+      })
+    })
+
+    req.on('error', reject)
+
+    // Set timeout
+    req.setTimeout(10000, () => {
+      req.destroy(new Error('Request timed out'))
+    })
+
+    // Write data and end request
+    req.write(postData)
+    req.end()
+  })
+}
+
+// Usage
+const newPost = await httpsPost('https://jsonplaceholder.typicode.com/posts', {
+  title: 'My Post',
+  body: 'Content here',
+  userId: 1,
+})
+console.log('Created:', newPost)
+```
+
+### Streaming with `http`/`https`
+
+The `http`/`https` modules provide direct access to Node.js streams. While `fetch()` also supports streaming (as shown earlier), you may encounter this pattern in older codebases:
+
+```javascript
+// http-stream.js
+import https from 'node:https'
+import { createWriteStream } from 'node:fs'
+import { pipeline } from 'node:stream/promises'
+
+async function downloadFile(url, destPath) {
+  return new Promise((resolve, reject) => {
+    https
+      .get(url, async (response) => {
+        if (response.statusCode !== 200) {
+          reject(new Error(`Failed to download: ${response.statusCode}`))
+          response.resume()
+          return
+        }
+
+        const fileStream = createWriteStream(destPath)
+
+        try {
+          await pipeline(response, fileStream)
+          console.log(`Downloaded to ${destPath}`)
+          resolve()
+        } catch (error) {
+          reject(error)
+        }
+      })
+      .on('error', reject)
+  })
+}
+
+// Usage
+await downloadFile(
+  'https://nodejs.org/dist/v22.0.0/node-v22.0.0.tar.gz',
+  './node-source.tar.gz',
+)
+```
+
+For more on streaming and file operations, check out our guide on [Reading and Writing Files in Node.js](/blog/reading-writing-files-nodejs/).
+
+## Summary
+
+Modern Node.js provides excellent built-in options for making HTTP requests:
+
+| Method            | Best For                                             | Node.js Version   |
+| ----------------- | ---------------------------------------------------- | ----------------- |
+| `fetch()`         | Most use cases: GET, POST, streaming, file downloads | 18+ (recommended) |
+| `http.request()`  | Unencrypted HTTP connections, legacy codebases       | All versions      |
+| `https.request()` | Encrypted HTTPS connections, legacy codebases        | All versions      |
+
+For most developers, **`fetch()` is the recommended choice**. It's familiar from browser JavaScript, promise-based, supports streaming, and requires no external dependencies.
+
+The `http.request()` and `https.request()` functions are lower-level alternatives available in all Node.js versions. The key difference between them is that you must explicitly choose the protocol: `http.request()` for unencrypted connections and `https.request()` for encrypted ones. If you need a unified abstraction that handles both protocols, you'll need to build it yourself or use `fetch()`, which handles this automatically based on the URL.
+
+:::tip[Ready to Master Node.js?]
+HTTP requests are just the beginning. **Node.js Design Patterns** covers async patterns, streams, scalable architectures, and more - everything you need to build production-grade Node.js applications.
+
+[Get a FREE chapter →](/#free-chapter)
+:::
+
+## Frequently Asked Questions
+
+### What is the easiest way to make an HTTP request in Node.js?
+
+The easiest way is using the built-in `fetch()` API, available since Node.js 18. Simply call `fetch(url)` and await the response. No external packages are required.
+
+### Does Node.js have a built-in fetch function?
+
+Yes, since Node.js 18, `fetch()` is available as a built-in global function. You don't need to install any packages like node-fetch or axios to make HTTP requests.
+
+### How do I make a POST request with JSON in Node.js?
+
+Use `fetch()` with `method` set to `'POST'`, set the `Content-Type` header to `'application/json'`, and pass your data through `JSON.stringify()` in the `body` option.
+
+### When should I use http/https modules instead of fetch?
+
+For most use cases, you should use `fetch()`. The `http`/`https` modules are primarily useful when:
+
+1. You're working with Node.js versions before 18
+2. You're maintaining legacy codebases
+3. You're integrating with libraries that expect `http.IncomingMessage` or `http.ClientRequest` objects
+
+Modern `fetch()` supports streaming too, so that's no longer a reason to prefer the older modules.
+
+### Do I need axios or got to make HTTP requests in Node.js?
+
+No, modern Node.js (18+) includes a built-in `fetch()` API that handles most use cases. External libraries like axios or got are optional and mainly useful for advanced features like automatic retries, request interceptors, or progress events.
diff --git a/src/content/blog/nodejs-stream-consumers-utilities/index.md b/src/content/blog/nodejs-stream-consumers-utilities/index.md
index 909abc3..81d1029 100644
--- a/src/content/blog/nodejs-stream-consumers-utilities/index.md
+++ b/src/content/blog/nodejs-stream-consumers-utilities/index.md
@@ -1,6 +1,6 @@
 ---
 date: 2022-03-11T12:30:00
-updatedAt: 2022-03-11T21:20:00
+updatedAt: 2026-01-29T12:00:00
 title: Node.js stream consumer utilities
 slug: node-js-stream-consumer
 description: How to easily read all the content of a readable stream using async await
@@ -200,10 +200,16 @@ By processing the data in chunks, we can keep the amount of memory being allocat
 
 When we accumulate an entire stream we are effectively defeating all the advantages of Node.js streams, so this is something that is recommended only when you are absolutely certain you are dealing with small amounts of data.
 
-## Wapping up
+## Wrapping up
 
 This is all for this article, feel free to [reach out to me on Twitter](https://twitter.com/loige) if you found this article interesting and if you think you learned something useful.
 
 If you are curious, you can also [read the code of the `stream/consumers` module](https://github.com/nodejs/node/blob/main/lib/stream/consumers.js), it's actually a really thin layer (less than 100 lines) and you can learn a trick or two by doing that.
 
+:::tip[Want to Master Node.js Streams?]
+Streams are a fundamental concept in Node.js. Our book **Node.js Design Patterns** has an entire chapter dedicated to streams, covering readable, writable, transform streams, and advanced patterns.
+
+[Get a FREE chapter →](/#free-chapter)
+:::
+
 See you in the next article!
diff --git a/src/content/blog/reading-writing-files-nodejs/index.md b/src/content/blog/reading-writing-files-nodejs/index.md
index 2941524..f4bc835 100644
--- a/src/content/blog/reading-writing-files-nodejs/index.md
+++ b/src/content/blog/reading-writing-files-nodejs/index.md
@@ -1,6 +1,6 @@
 ---
 date: 2025-10-12T23:40:00
-updatedAt: 2025-10-12T23:40:00
+updatedAt: 2026-01-29T12:00:00
 title: Reading and Writing Files in Node.js - The Complete Modern Guide
 slug: reading-writing-files-nodejs
 description: Learn the modern way to read and write files in Node.js using promises, streams, and file handles. Master memory-efficient file operations for production applications.
@@ -964,6 +964,8 @@ The beauty of this approach is its declarative nature - we describe _what_ we wa
 
 :::tip[Learn More About Streams]
 There are many stream details we've glossed over here - transform streams, duplex streams, and advanced composition patterns. For a deep dive into Node.js streams, check out the [FREE streams chapter from our Node.js Design Patterns book](/#free-chapter).
+
+If you need to consume an entire stream into memory (for small files), check out our article on [Node.js stream consumer utilities](/blog/node-js-stream-consumer/).
 :::
 
 :::tip[Using pipeline() with Generators]