DEV Community: Pratham

Linux File System Hunting: What I Found When I Stopped Running Commands and Started Reading the OS

Pratham — Sun, 10 May 2026 17:04:47 +0000

A web dev student goes on a system investigation — and discovers that Linux's entire brain lives in plain text files.

I've been using Linux terminals for months now — mostly just ls, cd, npm install, running Node.js servers. I knew the basics. I knew it worked.

But I never really looked at it.

This assignment changed that. Instead of running commands to do things, I started reading what the system had to say about itself. I opened files. I traced how one file referenced another. I followed the chain from a browser DNS request all the way to the physical network interface. And what I found was genuinely surprising — Linux isn't hiding anything. Its entire nervous system is right there in plain text, waiting to be read.

Here are the 10 most interesting things I discovered.

Finding 1: `/etc/hostname` — Your Machine's Identity in One Line

File: /etc/hostname

$ cat /etc/hostname
devbox

That's it. One word. The entire hostname of the machine — the name every other machine on the network uses to identify this server.

Why it exists: When multiple machines talk to each other, they need names. The hostname is this machine's name. The OS reads this file at boot time and sets the system identity.

What's interesting: I always assumed hostnames were configured deep inside some binary configuration. But they're stored in the most minimal file possible. One string, one file.

What blew my mind more: this file is what gets sent as the hostname in HTTP request headers when your Node.js server makes a request to another service. The chain from /etc/hostname → process environment → HTTP header is entirely automatic, invisible, and stored as plain text.

Why it matters for a web developer: In Docker containers, every container has its own /etc/hostname — that's how services in a Docker network identify each other. Understanding that it's just a file makes debugging container networking much less scary.

Finding 2: `/etc/hosts` — The Original Internet Directory

File: /etc/hosts

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   devbox
::1         localhost ip6-localhost

Before DNS servers existed, this file was the internet. Every computer on ARPAnet had a copy of a central HOSTS.TXT file that mapped every hostname to an IP address. You can still feel that history here.

Why it exists: It provides a local override for DNS resolution. When your system needs to resolve a hostname, it checks /etc/hosts first before ever asking a DNS server.

What I discovered: You can add any entry here, and it will resolve system-wide instantly, without touching any network service. I added:

127.0.0.1   api.local

And immediately, http://api.local:3000 worked in my browser — pointing to my local Node.js server. No DNS propagation wait. No registrar. Instant, local, and powerful.

The security insight: This is also a common malware tactic. Malware injects entries like 0.0.0.0 updates.microsoft.com to block update servers. Or <attacker-ip> paypal.com to redirect users to phishing sites. The file that makes development convenient is also a fundamental attack surface.

Finding 3: `/etc/resolv.conf` — Where Your DNS Requests Actually Go

File: /etc/resolv.conf

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

This file determines which DNS server your machine asks when it needs to resolve a domain name.

Why it exists: When your Node.js app calls fetch("https://api.example.com"), the OS needs to resolve api.example.com to an IP address. /etc/resolv.conf tells the system where to send that DNS query.

What I discovered: On modern Ubuntu, this doesn't point to 8.8.8.8 (Google) directly. It points to 127.0.0.53 — which is systemd-resolved, a local caching DNS stub resolver running as a service. The actual upstream servers are configured inside systemd-resolved.

This means DNS resolution involves:

Your app → /etc/resolv.conf → systemd-resolved (127.0.0.53) → Real DNS server

There's an entire caching layer between your code and the internet, and it lives at that 127.0.0.53 loopback address. I had no idea.

The discovery that surprised me: You can see the full chain by checking /run/systemd/resolve/resolv.conf — this is the actual upstream server list that systemd-resolved uses. On my machine: 8.8.8.8 and 8.8.4.4 (Google's DNS). The /etc/resolv.conf is just a pointer to the proxy.

Finding 4: `/etc/nsswitch.conf` — The Decision Engine for Name Resolution

File: /etc/nsswitch.conf

$ cat /etc/nsswitch.conf
hosts:   files mdns4_minimal [NOTFOUND=return] dns myhostname

This file is the one that actually decides the order in which hostname lookups happen. And it's the answer to a question I always wondered: how does the OS know to check /etc/hosts before asking DNS?

Why it exists: Linux systems have multiple ways to look up information — files, DNS, LDAP, NIS. nsswitch.conf defines the lookup priority for each type of query. The hosts line says: check files (i.e., /etc/hosts) first, then mdns4_minimal (local network discovery), then fall back to dns.

The insight: The entire resolution chain is configurable from this one file. A system administrator could reverse the priority — checking DNS before local files — just by changing the order of words on this line. The Linux networking stack has an entire plugin system for name resolution, and it's all controlled by human-readable text.

Finding 5: `/proc/net/route` — Your Machine's Routing Table as a File

File: /proc/net/route

$ cat /proc/net/route
Iface    Destination  Gateway   Flags  ...  Mask        Metric
eth0     00000000     0101A8C0  0003        00000000    100
eth0     0001A8C0     00000000  0001        00FFFFFF    100

The values are in hexadecimal little-endian format. After converting:

Destination: 0.0.0.0    → Default route (everything not matched)
Gateway:     192.168.1.1 → My router

Why it exists: The kernel maintains a routing table that decides where to send every outgoing network packet. Every time your Node.js server makes an outbound HTTP request, the kernel checks this table to determine which network interface and which gateway to use.

What blew my mind: This isn't a config file. This is a live window into the kernel's memory. The /proc filesystem doesn't exist on disk at all — it's generated dynamically by the kernel in real time. When you cat /proc/net/route, you're not reading a file. You're querying the kernel for its current routing state.

/proc is a virtual filesystem. The kernel pretends it has files there, but the "files" are kernel data structures made to look like files so you can read them with standard Unix tools.

Finding 6: `/proc/[pid]/` — Every Process Exposes Itself as a Folder

Directory: /proc/[pid]/

$ ls /proc/$(pgrep node)
cmdline  cwd  environ  exe  fd  maps  net  net/  ...

Every single running process has its own directory inside /proc named after its Process ID. And inside that directory is a complete picture of everything about that process.

What I found inside:

/proc/<pid>/cmdline   → The exact command that started the process
/proc/<pid>/environ   → ALL environment variables the process can see
/proc/<pid>/cwd       → A symlink to the process's current working directory
/proc/<pid>/exe       → A symlink to the binary being executed
/proc/<pid>/fd/       → Every file descriptor the process has open
/proc/<pid>/maps      → Memory layout: code, stack, heap, shared libraries
/proc/<pid>/net/      → This SPECIFIC process's network view (containers!)

The discovery that changed how I think: I ran my Node.js server and then checked /proc/<pid>/environ. There were all my environment variables — NODE_ENV, PORT, my database URL — completely visible to anyone with enough permissions to read that file.

$ cat /proc/$(pgrep node)/environ | tr '\0' '\n' | grep DB
DATABASE_URL=mongodb://localhost:27017/myapp

This is why process isolation and file permissions are critical. On a shared server, if another process can read your /proc/<pid>/environ, it can steal your database credentials.

Finding 7: `/etc/passwd` and `/etc/shadow` — The Split Permission Model

Files: /etc/passwd and /etc/shadow

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
pratham:x:1000:1000:Pratham Bhardwaj:/home/pratham:/bin/bash

$ cat /etc/shadow
pratham:$6$rounds=5000$salt$hashed_password_here:19478:0:99999:7:::

Why they're split: Originally, Linux stored hashed passwords directly in /etc/passwd. The problem: /etc/passwd must be world-readable (the ls -l command itself reads it to display usernames). So passwords — even hashed — were exposed to every user on the system.

The fix was to introduce /etc/shadow, which stores the actual hashes and is readable only by root. /etc/passwd now has x where the hash used to be, meaning "look in shadow."

What I learned: The $6$ prefix in shadow means SHA-512. $1$ means MD5. $2y$ means bcrypt. You can tell exactly which algorithm was used just from the prefix of the hash. This is how modern password systems allow algorithm upgrades — old hashes have the old prefix, new passwords get the new prefix, and the system handles both.

The web dev angle: This exact pattern — separate readable metadata from secret data — is the right way to design any system that handles credentials. The concept of /etc/passwd + /etc/shadow is architecturally similar to why you store the username publicly in a database but the password hash in a separate access-controlled column.

Finding 8: `/etc/systemd/system/` — Every Service is a File

Directory: /etc/systemd/system/

$ ls /etc/systemd/system/
multi-user.target.wants/  nginx.service  node-app.service  ...

$ cat /etc/systemd/system/nginx.service
[Unit]
Description=A high performance web server
After=network.target

[Service]
Type=forking
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Every system service — Nginx, SSH, your Node.js app, the DNS resolver — is defined by a plain-text "unit file" inside /etc/systemd/system/.

What the sections mean:

[Unit] — What this service is, what it depends on
[Service] — How to start, stop, and reload it
[Install] — When in the boot sequence to start it

The discovery: WantedBy=multi-user.target means "start this service when the system reaches multi-user mode" — which is normal operating mode. Linux boot is essentially a chain of targets, and multi-user.target is just another file that lists what should be running.

Why this matters: You can deploy your own Node.js app as a system service by creating a file in this directory. No Docker needed. Just a text file that says "start node server.js on boot, restart it if it crashes, run it as user pratham." The entire deployment config is a 15-line text file.

Finding 9: `/var/log/` — The Server's Diary

Directory: /var/log/

$ ls /var/log/
auth.log   kern.log   syslog   nginx/   apt/   ...

$ tail -f /var/log/auth.log
May 10 16:42:01 devbox sshd[1234]: Failed password for pratham from 45.33.32.156 port 48652 ssh2
May 10 16:42:03 devbox sshd[1234]: Failed password for pratham from 45.33.32.156 port 48654 ssh2
May 10 16:42:05 devbox sshd[1234]: Failed password for pratham from 45.33.32.156 port 48656 ssh2

When I ran tail -f /var/log/auth.log, I was watching failed SSH login attempts in real time. My dev server — a basic cloud VM — was being scanned and attacked within minutes of being created.

What the logs revealed:

auth.log — every login attempt (successful and failed), sudo usage, SSH activity
syslog — general system messages, kernel events, service starts/stops
kern.log — kernel-specific messages (hardware, driver events)
nginx/access.log — every single HTTP request to the web server

The insight that stuck with me: The failed login attempts weren't targeted attacks. They're automated bots constantly scanning the internet for open SSH ports with default credentials. The internet is hostile by default, and your server is being probed constantly. Logs make this visible.

$ grep "Failed password" /var/log/auth.log | wc -l
847

847 failed password attempts in one day on a fresh server. With password authentication disabled and SSH keys only, all of those attempts are just noise. But without that security config, one of those 847 attempts could have succeeded.

Finding 10: `/proc/net/tcp` — Open Sockets as a File

File: /proc/net/tcp

$ cat /proc/net/tcp
sl  local_address  rem_address  st  ...
0:  00000000:0016  00000000:00  0A  ← Port 22 (SSH) listening
1:  0100007F:0035  00000000:00  0A  ← Port 53 (DNS)
2:  00000000:1F40  00000000:00  0A  ← Port 8000 (my Node.js)

The addresses are in hex little-endian: 0016 = port 22, 0035 = port 53, 1F40 = port 8000.

Why it exists: This is the kernel's live list of every open TCP socket. What's listening. What's connected. What's in various states (listening = 0A, established = 01).

The insight: When you run ss -tlnp or netstat -tlnp to see open ports, those tools are just reading and formatting /proc/net/tcp. The actual source of truth isn't a network daemon — it's a kernel-virtual file in /proc.

I could write my own network monitoring tool just by reading and parsing /proc/net/tcp. No special privileges. No special libraries. Just reading a file.

The Pattern Behind Everything

After exploring all of this, I noticed one design philosophy that runs through the entire Linux file system:

"Everything is a file."

It's not just a slogan. The routing table is a file. Open processes are directories. Network sockets are files. DNS configuration is a file. Service definitions are files. System identity is a file.

This means every piece of knowledge about the system — its configuration, its current state, its history — is accessible with the same set of tools: cat, grep, tail, find. You don't need special admin dashboards. You don't need to know proprietary configuration formats. You need to know where to look and how to read.

For a web developer, this is deeply practical. When your Node.js app fails in production:

Check its logs in /var/log/ or journalctl -u your-service
Inspect its environment in /proc/<pid>/environ
Verify it's listening on the right port via /proc/net/tcp
Confirm DNS resolution is working via /etc/resolv.conf and /run/systemd/resolve/resolv.conf

Linux isn't a black box. It's a system that documents itself, constantly, in plain text — you just have to know where to look.

Wrapping Up

This assignment was supposed to be a file system exploration. It turned into understanding how the entire operating system works.

I used to think the OS was a magic layer under my code. Now I think of it as a collection of text files that a very smart kernel reads and acts on. The more you understand those files, the more control you have over your production environment.

I'm going through all of this as part of the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. The moment "Linux knowledge" stopped being about memorizing commands and started being about understanding why these files exist is when it finally became interesting.

Connect with me on LinkedIn or visit PrathamDEV.in.

Happy hunting! 🐧

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Storing Uploaded Files and Serving Them in Express

Pratham — Sun, 10 May 2026 13:30:44 +0000

Where do files go after you upload them, and how do you get them back?

You've set up Multer. You've sent a POST request with an image. The server didn't crash, and you got a success response. But... where did the file actually go? And more importantly, how do you show that uploaded profile picture on your frontend?

When I first learned file uploads in the ChaiCode Web Dev Cohort 2026, I thought the hard part was receiving the file. It turned out the trickiest part was figuring out how to store it securely and serve it back to the client.

If you don't handle this correctly, your server's hard drive will fill up with junk, your URLs will break, or worse — you'll expose a massive security vulnerability. Let's break down exactly how to store and serve files in Express.

Where Are Uploaded Files Stored?

When a user uploads a file, the server has to put the binary data somewhere. You essentially have two options: Local Storage or External Storage.

Local Storage (The Default)

Local storage means saving the file directly onto the hard drive of the server running your Express app.

Your Server:
  app.js
  package.json
  node_modules/
  uploads/          ← Files go here
    profile-1.jpg
    doc-42.pdf

This is how Multer works out of the box when you use dest: 'uploads/'.

Pros	Cons
Super easy to set up	If your server crashes/restarts (like on Heroku), files are deleted
Zero external dependencies	Doesn't scale (what if you have 3 load-balanced servers?)
Fast read/write times	Server hard drive can fill up quickly
Perfect for learning	Not ideal for modern production apps

External Storage (Cloud)

External storage means sending the file to a dedicated storage service (like Amazon S3, Google Cloud Storage, or Cloudinary) instead of keeping it on your server.

Your Server:
  (Receives file) → (Uploads to Cloud) → (Saves Cloud URL to Database)

AWS S3 / Cloudinary:
  profile-1.jpg  ← Files live here

Pros	Cons
Infinite scalability	Harder to set up
Files survive server restarts	Costs money (usually)
Reduces load on your Express server	Requires managing API keys and SDKs
CDN integration for fast global delivery	Adds latency to the upload process

For this article, we'll focus on Local Storage. It's the foundation you must understand before moving to the cloud.

The Upload Storage Folder Structure

When storing files locally, you need a predictable, organized folder structure. Dumping 100,000 files into a single uploads/ folder will eventually cause performance issues on your OS.

Here is a clean, production-ready local storage structure:

project-root/
├── app.js
├── public/                 ← Static files you ship with your app
│   ├── css/
│   └── images/
└── uploads/                ← Files uploaded by users (excluded from git)
    ├── avatars/            ← Grouped by resource type
    │   ├── user-1-1715.jpg
    │   └── user-2-1715.png
    └── documents/
        └── invoice-88.pdf

Multer Storage Configuration

To achieve this, we use Multer's diskStorage to dynamically route files to the correct folder:

const multer = require("multer");
const fs = require("fs");
const path = require("path");

// Ensure folders exist (create them if they don't)
const avatarDir = path.join(__dirname, "uploads/avatars");
if (!fs.existsSync(avatarDir)) fs.mkdirSync(avatarDir, { recursive: true });

const storage = multer.diskStorage({
  destination: (req, file, cb) => {
    // Route files based on the field name
    if (file.fieldname === "avatar") {
      cb(null, "uploads/avatars/");
    } else {
      cb(null, "uploads/misc/");
    }
  },
  filename: (req, file, cb) => {
    // Unique name: timestamp-random-originalExt
    const ext = path.extname(file.originalname);
    const uniqueSuffix = Date.now() + '-' + Math.round(Math.random() * 1E9);
    cb(null, `avatar-${uniqueSuffix}${ext}`);
  }
});

const upload = multer({ storage });

Serving Static Files in Express

Okay, the file is saved at uploads/avatars/user-1.jpg. Now, your React frontend requests:

GET http://localhost:3000/uploads/avatars/user-1.jpg

If you try this, Express will return a 404 Not Found.

Why? Because Express is secure by default. It does not expose your server's file system to the internet. If it did, someone could request http://localhost:3000/app.js or http://localhost:3000/.env and steal your source code.

To make a folder accessible to the public, you have to explicitly tell Express to serve it using the express.static middleware.

The `express.static` Middleware

const express = require("express");
const app = express();

// Tell Express: "Make everything inside the 'uploads' folder publicly accessible"
app.use(express.static("uploads"));

Now, if a file exists at uploads/avatars/user-1.jpg, you can access it at:

http://localhost:3000/avatars/user-1.jpg

Notice that "uploads" is missing from the URL. express.static("uploads") mounts the contents of the folder at the root of your domain.

Virtual Path Prefix (The Better Way)

Usually, you want the URL to explicitly show that the file is an upload. You can define a "virtual" path prefix:

// Map the URL path '/uploads' to the local folder 'uploads'
app.use("/uploads", express.static("uploads"));

Now the URL perfectly matches the folder structure:

Local File: project-root/uploads/avatars/user-1.jpg
URL:        http://localhost:3000/uploads/avatars/user-1.jpg

Static File Serving Flow

Here is exactly what happens when a browser requests an image:

Browser requests: GET /uploads/avatars/user-1.jpg
                │
                ↓
┌────────────────────────────────────────────────────────┐
│                   EXPRESS PIPELINE                     │
│                                                        │
│  1. app.use("/uploads", express.static("uploads"))     │
│     → URL starts with "/uploads"? YES.                 │
│     → Strips "/uploads" from URL.                      │
│     → Looks for "avatars/user-1.jpg" inside local      │
│       "uploads" directory.                             │
│                                                        │
│  2. Does the file exist on the hard drive?             │
│                                                        │
│     YES ───────────────┐           NO ──────────────┐  │
│                        │                            │  │
│     Stream file        │           Call next()      │  │
│     to client          │           to continue      │  │
│     (Don't call next)  │           routing          │  │
│                        ↓                            ↓  │
│               Response sent: 200 OK          Route not found (404)
└────────────────────────────────────────────────────────┘

Accessing Uploaded Files via URL

When a user uploads a file, you need to save the URL (or relative path) in your database so you can send it back to the frontend later.

Saving the Path to the Database

app.post("/api/users/:id/avatar", upload.single("avatar"), async (req, res) => {
  if (!req.file) {
    return res.status(400).json({ error: "Please upload a file" });
  }

  const userId = req.params.id;

  // Construct the relative path
  // req.file.filename is "avatar-12345.jpg"
  const avatarPath = `/uploads/avatars/${req.file.filename}`;

  // Save this path to your database
  // await User.update(userId, { avatarUrl: avatarPath });

  res.json({
    message: "Avatar updated",
    avatarUrl: avatarPath, // Send back the URL for immediate display
  });
});

Displaying on the Frontend

When the frontend fetches the user profile, it gets the path:

{
  "id": 42,
  "name": "Pratham",
  "avatarUrl": "/uploads/avatars/avatar-12345.jpg"
}

The frontend (React, Vue, HTML) simply plugs that into an <img> tag:

<!-- Assuming the API and frontend are on the same domain -->
<img src="/uploads/avatars/avatar-12345.jpg" alt="Profile Picture" />

<!-- If API is on a different domain -->
<img src="http://localhost:3000/uploads/avatars/avatar-12345.jpg" />

Security Considerations for Uploads

Handling user uploads is inherently dangerous. If you let users upload anything and then serve it back, you are inviting attackers to compromise your server.

Here are the absolute non-negotiables for secure file handling:

1. Never Trust the Extension

A user can rename malware.exe to innocent.jpg. Checking the extension is not enough. You must validate the MIME type.

const upload = multer({
  fileFilter: (req, file, cb) => {
    // Check MIME type, not just extension
    const allowedMimeTypes = ["image/jpeg", "image/png", "image/webp"];

    if (allowedMimeTypes.includes(file.mimetype)) {
      cb(null, true);
    } else {
      cb(new Error("Invalid file type"), false);
    }
  }
});

2. Never Trust the Filename

Never use file.originalname to save the file. An attacker could name their file ../../../etc/passwd to overwrite critical server files (Directory Traversal attack).

Always generate a random, unique filename on the server.

// ❌ DANGEROUS:
filename: (req, file, cb) => cb(null, file.originalname)

// ✅ SECURE:
filename: (req, file, cb) => {
  const ext = path.extname(file.originalname);
  cb(null, `${Date.now()}-${Math.random().toString(36).substring(7)}${ext}`);
}

3. Limit File Size

Without a size limit, an attacker can upload a 50GB file and crash your server by filling up the disk or exhausting memory.

const upload = multer({
  limits: {
    fileSize: 2 * 1024 * 1024, // 2 MB maximum
  }
});

4. Prevent Execution

If you allow users to upload HTML or SVG files, an attacker can inject malicious JavaScript into them. When another user views that image, the script runs (Stored XSS).

Only allow safe image types (JPG, PNG, WebP).
Be extremely careful with PDFs or SVGs.
When in doubt, force downloads rather than displaying inline.

Let's Practice: Hands-On Assignment

Part 1: Build the Storage Architecture

Create a project with an uploads/ folder containing two subfolders: profiles/ and documents/.
Configure Multer to dynamically save images to profiles/ and PDFs to documents/.
Generate secure, random filenames for all uploads.

Part 2: Serve the Files

Use express.static to serve the uploads/ folder under the /media URL prefix.
Ensure http://localhost:3000/media/profiles/test.jpg works.

Part 3: Secure the Endpoint

Add a file size limit of 1MB for profiles and 5MB for documents.
Add a fileFilter that rejects any file that isn't a JPEG, PNG, or PDF.

Key Takeaways

Local storage saves files to your server's disk. It's easy but doesn't scale well. External storage (S3) is the industry standard for production.
By default, Express keeps your files private. You must explicitly use app.use(express.static()) to expose a folder to the internet.
Use a virtual path prefix (app.use("/uploads", express.static("uploads"))) to keep URLs organized and clearly map them to local directories.
When saving to a database, store the relative URL path (e.g., /uploads/image.jpg), not the absolute local path (C:/Users/...).
Security is critical: Never trust user-provided filenames, always validate MIME types (not just extensions), and enforce strict file size limits.

Wrapping Up

Handling the upload is only half the battle. Storing the file securely, organizing your directories, and cleanly serving the assets back to the client is what turns a quick script into a robust application.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. The moment I finally saw a profile picture I uploaded render back on the frontend using express.static, the whole full-stack cycle finally clicked. It's not magic; it's just moving data, saving it to disk, and giving it a public URL.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Handling File Uploads in Express with Multer

Pratham — Sun, 10 May 2026 13:16:18 +0000

How to accept profile pictures, documents, and any file your users throw at your server.

The first time I tried to handle a file upload in Express, I wrote something like this:

app.post("/upload", (req, res) => {
  console.log(req.body); // Where's my file?
});

I submitted a form with an image attached, checked req.body, and got... nothing. An empty object. The file had vanished into the void.

Turns out, express.json() and express.urlencoded() can't handle files. Files are sent in a completely different format called multipart/form-data, and Express has no built-in way to parse it. You need a middleware specifically designed for file uploads.

That middleware is Multer — and once I set it up in the ChaiCode Web Dev Cohort 2026, file uploads went from mysterious to straightforward. Let me show you.

Why File Uploads Need Middleware

When you send JSON data to Express, the body looks like this:

Content-Type: application/json

{"name": "Pratham", "email": "pratham@dev.in"}

express.json() knows how to parse this. Simple text, simple format.

But when you send a file, the body looks completely different:

Content-Type: multipart/form-data; boundary=----abc123

------abc123
Content-Disposition: form-data; name="name"

Pratham
------abc123
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

(binary image data — thousands of bytes of raw binary)
------abc123--

This is multipart/form-data — a format that can carry both text fields and binary file data in the same request. It splits the body into parts (separated by a boundary string), each with its own headers and content.

express.json() can't parse this. It sees binary data and has no idea what to do with it. You need a dedicated multipart parser — and that's Multer.

Form Data Types:

  application/json
  → Text only. Parsed by express.json()

  application/x-www-form-urlencoded
  → Text only (form fields). Parsed by express.urlencoded()

  multipart/form-data
  → Text AND binary files. Parsed by MULTER

What Is Multer?

Multer is a Node.js middleware for handling multipart/form-data. It processes file uploads and makes them available on req.file (single file) or req.files (multiple files).

Install

npm install multer

What Multer Does

Without Multer:
  req.body → {}          (empty — file data is lost)
  req.file → undefined

With Multer:
  req.body → { name: "Pratham" }   (text fields parsed)
  req.file → {
    fieldname: "avatar",
    originalname: "photo.jpg",
    mimetype: "image/jpeg",
    size: 245678,
    path: "uploads/abc123-photo.jpg"
  }

Multer parses the multipart request, extracts the file, saves it to disk (or keeps it in memory), and gives you all the file information on req.file.

Handling Single File Upload

Let's start with the most common scenario: uploading one file — like a profile picture.

Basic Setup

const express = require("express");
const multer = require("multer");

const app = express();
app.use(express.json());

// Configure multer — save files to "uploads/" folder
const upload = multer({ dest: "uploads/" });

// Single file upload route
app.post("/upload/avatar", upload.single("avatar"), (req, res) => {
  console.log("File:", req.file);
  console.log("Body:", req.body);

  res.json({
    message: "File uploaded successfully!",
    file: {
      originalName: req.file.originalname,
      size: req.file.size,
      path: req.file.path,
    },
  });
});

app.listen(3000, () => console.log("Server on http://localhost:3000"));

Key Points

multer({ dest: "uploads/" }) — tells Multer where to save files
upload.single("avatar") — expects ONE file in a field called "avatar"
After processing, file info is on req.file

The `req.file` Object

{
  fieldname: "avatar",        // Name of the form field
  originalname: "photo.jpg",  // Original filename from the user
  encoding: "7bit",           // File encoding
  mimetype: "image/jpeg",     // File type
  destination: "uploads/",    // Where it was saved
  filename: "a1b2c3d4e5f6",   // Generated filename (no extension!)
  path: "uploads/a1b2c3d4e5f6", // Full path to saved file
  size: 245678                // File size in bytes
}

Testing with curl

curl -X POST http://localhost:3000/upload/avatar \
  -F "avatar=@/path/to/photo.jpg" \
  -F "name=Pratham"

-F sends form data in multipart format. @ reads from a file.

Testing with an HTML Form

<form action="/upload/avatar" method="POST" enctype="multipart/form-data">
  <input type="text" name="name" placeholder="Your name" />
  <input type="file" name="avatar" />
  <button type="submit">Upload</button>
</form>

The enctype="multipart/form-data" attribute is essential — without it, the browser won't send the file as binary data.

Client → Server → Storage Upload Flow

┌────────────────┐
│     Client     │
│                │
│  <form>        │
│  enctype=      │
│  "multipart/   │
│   form-data"   │
│                │
│  [photo.jpg]   │
│  [name field]  │
└───────┬────────┘
        │
        │  POST /upload/avatar
        │  Content-Type: multipart/form-data
        ↓
┌────────────────────────────────────────────┐
│              EXPRESS SERVER                  │
│                                            │
│  1. Request arrives                        │
│                                            │
│  2. Multer middleware runs:                │
│     → Parses multipart body               │
│     → Extracts file binary data            │
│     → Saves file to disk (uploads/)        │
│     → Populates req.file with metadata     │
│     → Populates req.body with text fields  │
│                                            │
│  3. Route handler runs:                    │
│     → Reads req.file and req.body          │
│     → Sends response                      │
│                                            │
└───────────────────┬────────────────────────┘
                    │
                    ↓
        ┌───────────────────┐
        │   uploads/ folder  │
        │                   │
        │  a1b2c3d4e5f6     │  ← saved file
        │  (photo.jpg data) │
        └───────────────────┘

Handling Multiple File Uploads

Multiple Files — Same Field

For uploading multiple images at once (like a photo gallery):

// Accept up to 5 files from the "photos" field
app.post("/upload/gallery", upload.array("photos", 5), (req, res) => {
  console.log("Files:", req.files); // Array of file objects

  res.json({
    message: `${req.files.length} files uploaded!`,
    files: req.files.map((f) => ({
      name: f.originalname,
      size: f.size,
    })),
  });
});

upload.array("photos", 5) — accepts up to 5 files from the "photos" field
req.files is an array of file objects (same shape as req.file)

Multiple Files — Different Fields

For forms with separate file inputs (avatar + resume):

const multiUpload = upload.fields([
  { name: "avatar", maxCount: 1 },
  { name: "resume", maxCount: 1 },
]);

app.post("/upload/profile", multiUpload, (req, res) => {
  console.log("Avatar:", req.files["avatar"][0]);
  console.log("Resume:", req.files["resume"][0]);

  res.json({
    avatar: req.files["avatar"][0].originalname,
    resume: req.files["resume"][0].originalname,
  });
});

HTML Form for Multiple Files

<!-- Same field (gallery) -->
<input type="file" name="photos" multiple />

<!-- Different fields -->
<input type="file" name="avatar" />
<input type="file" name="resume" />

Upload Methods Summary

Method	Use Case	Access Files Via
`upload.single("fieldName")`	One file	`req.file`
`upload.array("fieldName", max)`	Multiple files, same field	`req.files` (array)
`upload.fields([{ name, maxCount }])`	Multiple files, different fields	`req.files["name"]`
`upload.none()`	No files (text fields only)	`req.body`

Storage Configuration

By default, multer({ dest: "uploads/" }) saves files with random names and no extension. For more control, use Multer's disk storage engine.

Custom Storage

const storage = multer.diskStorage({
  destination: (req, file, cb) => {
    cb(null, "uploads/"); // Save to uploads/ folder
  },
  filename: (req, file, cb) => {
    // Create unique filename: timestamp-originalname
    const uniqueName = `${Date.now()}-${file.originalname}`;
    cb(null, uniqueName);
  },
});

const upload = multer({ storage });

Now files are saved as 1715350000000-photo.jpg instead of a1b2c3d4e5f6.

Adding File Validation

const upload = multer({
  storage,
  limits: {
    fileSize: 5 * 1024 * 1024, // 5 MB max
  },
  fileFilter: (req, file, cb) => {
    // Only allow images
    const allowedTypes = ["image/jpeg", "image/png", "image/gif", "image/webp"];

    if (allowedTypes.includes(file.mimetype)) {
      cb(null, true); // Accept
    } else {
      cb(new Error("Only image files are allowed!"), false); // Reject
    }
  },
});

Handling Upload Errors

app.post("/upload/avatar", (req, res) => {
  upload.single("avatar")(req, res, (err) => {
    if (err instanceof multer.MulterError) {
      // Multer-specific error (file too large, too many files, etc.)
      return res.status(400).json({ error: err.message });
    }
    if (err) {
      // Custom error (wrong file type)
      return res.status(400).json({ error: err.message });
    }
    if (!req.file) {
      return res.status(400).json({ error: "No file uploaded" });
    }

    res.json({ message: "Upload successful!", file: req.file.originalname });
  });
});

Serving Uploaded Files

After uploading, you need to make the files accessible. Use Express's static file middleware:

// Serve the uploads folder as static files
app.use("/uploads", express.static("uploads"));

Now files are accessible via URL:

File saved at: uploads/1715350000000-photo.jpg
Accessible at: http://localhost:3000/uploads/1715350000000-photo.jpg

Complete Upload + Serve Example

const express = require("express");
const multer = require("multer");
const path = require("path");

const app = express();
app.use(express.json());

// Storage config
const storage = multer.diskStorage({
  destination: "uploads/",
  filename: (req, file, cb) => {
    const ext = path.extname(file.originalname);
    cb(null, `${Date.now()}-${Math.round(Math.random() * 1000)}${ext}`);
  },
});

const upload = multer({
  storage,
  limits: { fileSize: 5 * 1024 * 1024 },
  fileFilter: (req, file, cb) => {
    const allowed = [".jpg", ".jpeg", ".png", ".gif", ".webp"];
    const ext = path.extname(file.originalname).toLowerCase();
    if (allowed.includes(ext)) cb(null, true);
    else cb(new Error(`File type ${ext} not allowed`));
  },
});

// Serve uploads as static files
app.use("/uploads", express.static("uploads"));

// Upload endpoint
app.post("/api/upload", upload.single("image"), (req, res) => {
  if (!req.file) return res.status(400).json({ error: "No file" });

  const fileUrl = `${req.protocol}://${req.get("host")}/uploads/${req.file.filename}`;

  res.status(201).json({
    message: "Uploaded!",
    file: {
      name: req.file.originalname,
      size: `${(req.file.size / 1024).toFixed(1)} KB`,
      url: fileUrl,
    },
  });
});

// Serve upload form
app.get("/", (req, res) => {
  res.send(`
    <h1>File Upload</h1>
    <form action="/api/upload" method="POST" enctype="multipart/form-data">
      <input type="file" name="image" accept="image/*" />
      <button type="submit">Upload</button>
    </form>
  `);
});

app.listen(3000, () => console.log("Server on http://localhost:3000"));

Visit http://localhost:3000, upload an image, and the response will include a URL where you can view it.

Multer Middleware Execution Flow

POST /api/upload  (with file attached)
        │
        ↓
┌───────────────────────────────────────────────┐
│            MULTER MIDDLEWARE                    │
│                                               │
│  1. Check Content-Type                        │
│     → Is it multipart/form-data?              │
│     → NO  → skip (or error)                  │
│     → YES → continue                         │
│                                               │
│  2. Parse the multipart body                  │
│     → Separate text fields and file data      │
│                                               │
│  3. File filter check                         │
│     → Is this file type allowed?              │
│     → NO  → reject with error                │
│     → YES → continue                         │
│                                               │
│  4. Size limit check                          │
│     → Is file within size limit?              │
│     → NO  → reject with MulterError          │
│     → YES → continue                         │
│                                               │
│  5. Storage engine                            │
│     → Determine destination folder            │
│     → Generate filename                       │
│     → Write file to disk                     │
│                                               │
│  6. Populate request object                   │
│     → req.file = { originalname, path, ... }  │
│     → req.body = { text fields }              │
│                                               │
│  7. Call next()                               │
│     → Route handler runs                     │
│                                               │
└───────────────────────────────────────────────┘

Let's Practice: Hands-On Assignment

Part 1: Single File Upload

Build a server that:

Accepts a profile picture via POST /upload/avatar
Saves it to an uploads/ folder with a unique name
Returns the file URL in the response

Part 2: Multiple File Upload

Add a route POST /upload/gallery that:

Accepts up to 5 images
Returns info about all uploaded files

Part 3: Add Validation

Modify your upload to:

Only accept images (JPEG, PNG, GIF, WebP)
Limit file size to 2 MB
Return clear error messages when validation fails

Part 4: Serve and Display

Serve the uploads/ folder with express.static()
Create a GET /gallery route that returns HTML showing all uploaded images

Key Takeaways

Files need special handling because they're sent as multipart/form-data — a format that express.json() can't parse. Multer is the middleware that bridges this gap.
upload.single("field") handles one file (req.file). upload.array("field", max) handles multiple files from the same field (req.files). upload.fields() handles files from different fields.
Storage configuration controls where and how files are saved. Use multer.diskStorage() for custom filenames and destinations.
Always validate uploads — check file type with fileFilter, limit file size with limits, and handle errors gracefully.
Serve uploads with express.static("uploads") to make files accessible via URL.

Wrapping Up

File uploads are one of those features that seem intimidating until you set up Multer — then it's just another middleware in your Express pipeline. Parse the multipart data, validate the file, save it, serve it. The same pattern whether you're handling profile pictures, document uploads, or image galleries.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. File uploads were the feature that made my projects feel real — the moment users can upload their own images, the app stops being a demo and starts being a product.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

JWT Authentication in Node.js Explained Simply

Pratham — Sun, 10 May 2026 13:09:31 +0000

How to build a login system where the server doesn't need to remember anything about you.

Here's the problem with building any application that has user accounts: how does the server know that the person making a request is actually who they say they are?

You log in once. But then you visit 10 different pages, make 15 API calls, upload a file. Each of those is a separate HTTP request, and HTTP is stateless — every request is completely independent. The server has no memory of the previous one. So how does it know you're still logged in?

The answer is authentication tokens — and the most popular one is JWT (JSON Web Token). You log in, the server gives you a token, and you show that token with every request. No session storage. No database lookup. The token itself proves who you are.

Let me show you how this works from scratch in Node.js. This was one of the most practical things I've built in the ChaiCode Web Dev Cohort 2026.

What Does Authentication Mean?

Authentication answers one question: "Are you who you claim to be?"

Think of it like checking into a hotel:

You arrive and show your ID at the front desk → the hotel verifies your identity
The hotel gives you a room key card → proof that you've been verified
Every time you enter your room, you swipe the key card → the door trusts the card without calling the front desk again

In web terms:

Step 1: User sends credentials (email + password) → Login
Step 2: Server verifies and sends back a token    → "Here's your key card"
Step 3: User sends token with every request        → "Here's my key card"
Step 4: Server checks the token                    → "Valid card, come in"

The token is the key card. The server is the door lock. And JWT is the specific type of key card we're using.

What Is JWT?

JWT (JSON Web Token) is a compact, self-contained token that carries information about a user. The key word is self-contained — the token itself holds the user data. The server doesn't need to store anything or look anything up.

Why "Self-Contained"?

With a traditional session, the server gives you a random ID and stores your data:

Session approach:
  Token: "abc123"  (meaningless — server has to look it up)
  Server: "Let me check my database... abc123 = Pratham, developer"

JWT approach:
  Token: "eyJhbGci..." (contains user data inside it!)
  Server: "Let me verify the signature... valid!
           The token says id=1, name=Pratham, role=developer"

The server creates the JWT, sends it to the client, and forgets about it. When the client sends it back, the server can verify it using only the secret key — no storage, no database, no session state.

Structure of a JWT

Every JWT is a single string made up of three parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MSwibmFtZSI6IlByYXRoYW0iLCJyb2xlIjoiZGV2ZWxvcGVyIiwiaWF0IjoxNzE1MzQ4MDAwLCJleHAiOjE3MTU0MzQ0MDB9.kX9_7TgL2Rm5pVa0Q1sWnJkGYM7v3BcFhR9Xp2yNmW4
└─────────── Header ───────────┘└──────────────────────────── Payload ────────────────────────────┘└───────── Signature ─────────┘

Part 1: Header

The header tells the server how the token was signed.

{
  "alg": "HS256",
  "typ": "JWT"
}

alg — the algorithm used to create the signature (HS256 is common)
typ — the token type (always "JWT")

This JSON is Base64-encoded (not encrypted — anyone can decode it).

Part 2: Payload

The payload contains the actual data — called claims. This is where user information lives.

{
  "id": 1,
  "name": "Pratham",
  "role": "developer",
  "iat": 1715348000,
  "exp": 1715434400
}

id, name, role — your custom data (whatever you put in)
iat — "issued at" timestamp (when the token was created)
exp — "expires at" timestamp (when the token becomes invalid)

This is also Base64-encoded — readable by anyone. Never put passwords or sensitive data in a JWT payload.

Part 3: Signature

The signature is what makes JWT secure. It's created by combining the header, payload, and a secret key that only the server knows.

Signature = HMAC-SHA256(
  base64(header) + "." + base64(payload),
  "my-secret-key"
)

The signature ensures two things:

The token hasn't been tampered with — if anyone changes the payload, the signature won't match
The token was created by your server — only your server knows the secret key

JWT Security Model:

  ┌────────┐  ┌─────────┐  ┌───────────┐
  │ Header │  │ Payload │  │ Signature │
  │        │  │         │  │           │
  │ Anyone │  │ Anyone  │  │ Only the  │
  │ can    │  │ can     │  │ server    │
  │ READ   │  │ READ    │  │ can       │
  │ this   │  │ this    │  │ CREATE or │
  │        │  │         │  │ VERIFY    │
  │        │  │         │  │ this      │
  └────────┘  └─────────┘  └───────────┘

  The data is PUBLIC. The verification is PRIVATE.

Login Flow Using JWT

Here's the complete authentication flow from login to protected access:

JWT Login Authentication Flow

┌──────────┐                                ┌──────────────┐
│  Client  │                                │    Server    │
└────┬─────┘                                └──────┬───────┘
     │                                             │
     │  1. POST /login                             │
     │     { email: "pratham@dev.in",              │
     │       password: "mypassword" }              │
     │ ──────────────────────────────────────→      │
     │                                             │
     │                                    2. Find user in DB
     │                                    3. Compare password hash
     │                                    4. Password matches? ✅
     │                                    5. Create JWT:
     │                                       jwt.sign({
     │                                         id: 1,
     │                                         name: "Pratham",
     │                                         role: "developer"
     │                                       }, SECRET, { expiresIn: "7d" })
     │                                             │
     │  6. Response:                               │
     │     { token: "eyJhbGci..." }                │
     │ ←──────────────────────────────────────      │
     │                                             │
     │  7. Client stores the token                 │
     │     (localStorage, cookie, or memory)       │
     │                                             │
     │  8. GET /api/profile                        │
     │     Headers:                                │
     │       Authorization: Bearer eyJhbGci...     │
     │ ──────────────────────────────────────→      │
     │                                             │
     │                                    9. Extract token from header
     │                                   10. jwt.verify(token, SECRET)
     │                                   11. Valid? ✅ → extract user
     │                                             │
     │  12. Response:                              │
     │      { user: { id: 1, name: "Pratham" } }   │
     │ ←──────────────────────────────────────      │
     │                                             │
└────┴─────┘                                └──────┴───────┘

Step-by-Step Implementation

1. Project Setup

mkdir jwt-auth-demo
cd jwt-auth-demo
npm init -y
npm install express jsonwebtoken bcryptjs

express — web framework
jsonwebtoken — create and verify JWTs
bcryptjs — hash passwords securely

2. Complete Auth Server

const express = require("express");
const jwt = require("jsonwebtoken");
const bcrypt = require("bcryptjs");

const app = express();
app.use(express.json());

// Secret key — in production, use environment variables!
const JWT_SECRET = "my-super-secret-key-change-this-in-production";

// Simulated database
const users = [];

// ─── REGISTER ───
app.post("/register", async (req, res) => {
  const { name, email, password } = req.body;

  // Validation
  if (!name || !email || !password) {
    return res.status(400).json({ error: "All fields are required" });
  }

  // Check if user exists
  if (users.find((u) => u.email === email)) {
    return res.status(400).json({ error: "Email already registered" });
  }

  // Hash the password (NEVER store plain text passwords)
  const hashedPassword = await bcrypt.hash(password, 10);

  // Save user
  const newUser = {
    id: users.length + 1,
    name,
    email,
    password: hashedPassword,
  };
  users.push(newUser);

  res.status(201).json({
    message: "User registered successfully!",
    user: { id: newUser.id, name: newUser.name, email: newUser.email },
  });
});

// ─── LOGIN ───
app.post("/login", async (req, res) => {
  const { email, password } = req.body;

  // Find user
  const user = users.find((u) => u.email === email);
  if (!user) {
    return res.status(401).json({ error: "Invalid email or password" });
  }

  // Compare password with hash
  const isMatch = await bcrypt.compare(password, user.password);
  if (!isMatch) {
    return res.status(401).json({ error: "Invalid email or password" });
  }

  // Create JWT
  const token = jwt.sign(
    { id: user.id, name: user.name, email: user.email },
    JWT_SECRET,
    { expiresIn: "7d" },
  );

  res.json({
    message: "Login successful!",
    token,
  });
});

app.listen(3000, () => {
  console.log("Auth server running on http://localhost:3000");
});

Sending Token with Requests

Once the client has a token, it sends it with every request that needs authentication. The standard way is via the Authorization header:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

From a Frontend (React, Vanilla JS)

// After login, store the token
const loginResponse = await fetch("/login", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email: "pratham@dev.in", password: "mypassword" }),
});
const { token } = await loginResponse.json();

// Use the token for protected requests
const profileResponse = await fetch("/api/profile", {
  headers: {
    Authorization: `Bearer ${token}`,
  },
});
const profile = await profileResponse.json();
console.log(profile); // { user: { id: 1, name: "Pratham", ... } }

From curl (Terminal)

# Login and get token
curl -X POST http://localhost:3000/login \
  -H "Content-Type: application/json" \
  -d '{"email": "pratham@dev.in", "password": "mypassword"}'

# Use token for protected route
curl http://localhost:3000/api/profile \
  -H "Authorization: Bearer eyJhbGci..."

Where to Store the Token on the Client

Storage	Pros	Cons
`localStorage`	Easy to use, persists across tabs	Vulnerable to XSS attacks
`httpOnly` cookie	Can't be accessed by JS (XSS-safe)	Vulnerable to CSRF (mitigated with `sameSite`)
Memory (variable)	Most secure, gone on refresh	Lost when user refreshes the page

For learning: localStorage is fine. For production: httpOnly cookies are recommended.

Protecting Routes Using Tokens

This is where it all comes together. You create a middleware that checks for a valid JWT before allowing access to protected routes.

Auth Middleware

function authenticate(req, res, next) {
  // 1. Get the Authorization header
  const authHeader = req.headers.authorization;

  // 2. Check if it exists and starts with "Bearer "
  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    return res.status(401).json({ error: "Access denied. No token provided." });
  }

  // 3. Extract the token (remove "Bearer ")
  const token = authHeader.split(" ")[1];

  // 4. Verify the token
  try {
    const decoded = jwt.verify(token, JWT_SECRET);
    req.user = decoded; // Attach user data to the request
    next(); // Token valid — proceed to route handler
  } catch (error) {
    if (error.name === "TokenExpiredError") {
      return res.status(401).json({ error: "Token expired. Please log in again." });
    }
    return res.status(403).json({ error: "Invalid token." });
  }
}

Token Validation Lifecycle

Request arrives with: Authorization: Bearer eyJhbGci...
        │
        ↓
┌──────────────────────────────────────────────┐
│           AUTH MIDDLEWARE                      │
│                                              │
│  1. Header present?                          │
│     NO  → 401 "No token provided"           │
│     YES ↓                                    │
│                                              │
│  2. Starts with "Bearer "?                   │
│     NO  → 401 "No token provided"           │
│     YES ↓                                    │
│                                              │
│  3. Extract token after "Bearer "            │
│                                              │
│  4. jwt.verify(token, SECRET)                │
│     EXPIRED  → 401 "Token expired"          │
│     INVALID  → 403 "Invalid token"          │
│     VALID    ↓                               │
│                                              │
│  5. Attach decoded payload to req.user       │
│                                              │
│  6. Call next() → proceed to route handler   │
│                                              │
└──────────────────────────────────────────────┘
        │
        ↓
  Route handler runs with req.user available

Using the Middleware

// Public routes — anyone can access
app.post("/register", (req, res) => { /* ... */ });
app.post("/login", (req, res) => { /* ... */ });

// Protected routes — token required
app.get("/api/profile", authenticate, (req, res) => {
  res.json({ user: req.user });
});

app.get("/api/dashboard", authenticate, (req, res) => {
  res.json({
    message: `Welcome to your dashboard, ${req.user.name}!`,
    userId: req.user.id,
  });
});

app.get("/api/settings", authenticate, (req, res) => {
  res.json({
    user: req.user.name,
    settings: { theme: "dark", notifications: true },
  });
});

Every route with authenticate as a second argument requires a valid JWT. Without it, the user gets a 401 or 403 error. With it, req.user contains the decoded token data.

Role-Based Access Control

Once you have JWT auth working, adding role-based access is just one more middleware:

function authorize(...allowedRoles) {
  return (req, res, next) => {
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({
        error: "Forbidden — you don't have permission to access this resource",
      });
    }
    next();
  };
}

// Only admins
app.get("/api/admin/users", authenticate, authorize("admin"), (req, res) => {
  res.json({ users: users.map((u) => ({ id: u.id, name: u.name, email: u.email })) });
});

// Admins and moderators
app.delete("/api/posts/:id", authenticate, authorize("admin", "moderator"), (req, res) => {
  res.json({ message: `Post ${req.params.id} deleted` });
});

// Any authenticated user
app.get("/api/profile", authenticate, (req, res) => {
  res.json({ user: req.user });
});

The middleware chain: authenticate → authorize → route handler. Each layer adds a check.

Complete Working Example

Here's the full server with registration, login, and protected routes:

const express = require("express");
const jwt = require("jsonwebtoken");
const bcrypt = require("bcryptjs");

const app = express();
app.use(express.json());

const JWT_SECRET = "my-secret-key";
const users = [];

// Auth middleware
function authenticate(req, res, next) {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    return res.status(401).json({ error: "No token provided" });
  }

  try {
    const token = authHeader.split(" ")[1];
    req.user = jwt.verify(token, JWT_SECRET);
    next();
  } catch (err) {
    res.status(403).json({ error: "Invalid or expired token" });
  }
}

// Register
app.post("/register", async (req, res) => {
  const { name, email, password } = req.body;
  if (!name || !email || !password) {
    return res.status(400).json({ error: "All fields required" });
  }
  if (users.find((u) => u.email === email)) {
    return res.status(400).json({ error: "Email already exists" });
  }

  const hashed = await bcrypt.hash(password, 10);
  const user = { id: users.length + 1, name, email, password: hashed, role: "member" };
  users.push(user);

  res.status(201).json({ message: "Registered!", user: { id: user.id, name, email } });
});

// Login
app.post("/login", async (req, res) => {
  const { email, password } = req.body;
  const user = users.find((u) => u.email === email);
  if (!user || !(await bcrypt.compare(password, user.password))) {
    return res.status(401).json({ error: "Invalid credentials" });
  }

  const token = jwt.sign(
    { id: user.id, name: user.name, email: user.email, role: user.role },
    JWT_SECRET,
    { expiresIn: "24h" },
  );

  res.json({ message: "Login successful!", token });
});

// Protected routes
app.get("/api/profile", authenticate, (req, res) => {
  res.json({ user: req.user });
});

app.get("/api/dashboard", authenticate, (req, res) => {
  res.json({ message: `Welcome, ${req.user.name}!`, role: req.user.role });
});

// Public route
app.get("/", (req, res) => {
  res.json({ message: "Welcome! Please register or login." });
});

app.listen(3000, () => console.log("Server running on http://localhost:3000"));

Testing the Full Flow

# 1. Register
curl -X POST http://localhost:3000/register \
  -H "Content-Type: application/json" \
  -d '{"name":"Pratham","email":"pratham@dev.in","password":"pass123"}'

# 2. Login (copy the token from the response)
curl -X POST http://localhost:3000/login \
  -H "Content-Type: application/json" \
  -d '{"email":"pratham@dev.in","password":"pass123"}'

# 3. Access protected route (paste your token)
curl http://localhost:3000/api/profile \
  -H "Authorization: Bearer YOUR_TOKEN_HERE"

# 4. Try without token (should get 401)
curl http://localhost:3000/api/profile

Let's Practice: Hands-On Assignment

Part 1: Build the Auth System

Create a server with:

POST /register — hash password with bcrypt, save user
POST /login — verify credentials, return JWT
GET /api/profile — protected, return user data from token

Part 2: Add Token Expiry Handling

Set tokens to expire in 1 minute ({ expiresIn: "1m" }). Login, use the token, wait 2 minutes, try again — observe the "Token expired" error. Then change it to a reasonable time like 24h.

Part 3: Add Role-Based Access

Add a role field to users ("member" or "admin"). Create an authorize middleware that checks roles. Make a route like GET /api/admin that only admins can access.

Part 4: Decode a JWT

Go to jwt.io, paste your token, and see the decoded header and payload. Notice that the payload is fully readable — this is why you never put passwords in a JWT.

Key Takeaways

Authentication verifies identity. JWT is a token-based approach where the server creates a signed token at login and the client sends it with every request.
JWT has three parts: Header (algorithm), Payload (user data — readable by anyone), and Signature (proof of authenticity — only the server can create/verify).
The login flow: Client sends credentials → Server validates → Server creates JWT → Client stores token → Client sends token with every protected request.
Protect routes with middleware that extracts the token from the Authorization header, verifies it with jwt.verify(), and attaches the decoded user to req.user.
JWTs are stateless — the server stores nothing. This makes them perfect for APIs and microservices, but means tokens can't be truly revoked before expiry.

Wrapping Up

JWT authentication is the standard for modern APIs. Once you build this login → token → protected route flow once, every future project follows the same pattern. Register, login, get token, send token, verify token — that's the entire system.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. Building a real JWT auth system was the first time I felt like I was writing production-level backend code. It's the foundation for everything — user accounts, protected dashboards, role-based access, API security.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

Pratham — Sun, 10 May 2026 13:02:44 +0000

Three terms that get mixed up constantly — and a clear guide to what each one actually does.

When I first started building login systems, I was drowning in terminology. Sessions. Cookies. Tokens. JWT. Stateful. Stateless. Every tutorial used different words for what seemed like the same thing, and I couldn't figure out how the pieces fit together.

Here's what finally cleared the confusion: cookies, sessions, and JWTs are not the same category of thing. Comparing them is like comparing "envelopes," "letters," and "email" — they're related, but they serve different purposes.

A cookie is a transport mechanism — it carries data between client and server
A session is a server-side record of who you are
A JWT is a self-contained token that proves who you are

Once I understood what each one actually is, the authentication strategies built on top of them made perfect sense. Let me explain it the way it clicked for me in the ChaiCode Web Dev Cohort 2026.

What Are Cookies?

A cookie is a small piece of data that the server sends to the browser. The browser stores it and automatically sends it back with every subsequent request to that server.

Cookies aren't an authentication method — they're a delivery vehicle. They can carry anything: a session ID, a JWT, user preferences, tracking data.

How Cookies Work

1. Client sends login request:
   POST /login  { email: "pratham@dev.in", password: "secret" }
        │
        ↓
2. Server validates credentials and sets a cookie:
   Response headers:
   Set-Cookie: sessionId=abc123; HttpOnly; Secure; Path=/
        │
        ↓
3. Browser STORES the cookie automatically

4. Every future request to this server includes the cookie:
   GET /api/profile
   Cookie: sessionId=abc123    ← browser sends this automatically
        │
        ↓
5. Server reads the cookie and knows who you are

Key Cookie Properties

res.cookie("sessionId", "abc123", {
  httpOnly: true, // Can't be accessed by JavaScript (XSS protection)
  secure: true, // Only sent over HTTPS
  maxAge: 86400000, // Expires in 24 hours (milliseconds)
  sameSite: "strict", // Not sent with cross-site requests (CSRF protection)
});

Property	What It Does
`httpOnly`	Browser can't access it via `document.cookie` — safer
`secure`	Only sent over HTTPS connections
`maxAge`	How long the cookie lives (in milliseconds)
`sameSite`	Controls when cookie is sent with cross-site requests
`path`	Which routes the cookie applies to

Cookies are the envelope. What you put inside (a session ID or a JWT) determines your authentication strategy.

What Are Sessions?

A session is a record stored on the server that tracks information about a logged-in user. When a user logs in, the server creates a session, gives it a unique ID, and sends that ID to the client (usually via a cookie). The client sends the session ID with every request, and the server looks it up to know who the user is.

Session Authentication Flow

┌──────────┐                              ┌──────────────────┐
│  Client  │                              │     Server       │
│ (Browser)│                              │                  │
└────┬─────┘                              │  Session Store:  │
     │                                    │  ┌────────────┐  │
     │  1. POST /login                    │  │ (empty)    │  │
     │     { email, password }            │  └────────────┘  │
     │ ──────────────────────────────→    │                  │
     │                                    │  2. Validate     │
     │                                    │     credentials  │
     │                                    │                  │
     │                                    │  3. Create       │
     │                                    │     session:     │
     │                                    │  ┌────────────┐  │
     │                                    │  │ sid: abc123│  │
     │                                    │  │ user: {...}│  │
     │  4. Set-Cookie: sid=abc123         │  └────────────┘  │
     │ ←──────────────────────────────    │                  │
     │                                    │                  │
     │  5. GET /api/profile               │                  │
     │     Cookie: sid=abc123             │                  │
     │ ──────────────────────────────→    │                  │
     │                                    │  6. Look up      │
     │                                    │     session      │
     │                                    │     abc123       │
     │  7. Response: { user data }        │     → found!     │
     │ ←──────────────────────────────    │                  │
     │                                    │                  │
└────┴─────┘                              └──────────────────┘

Key Characteristics

The session data lives on the server (in memory, a database, or Redis)
The client only has a session ID — a meaningless string
The server must look up the session on every request
If the server restarts, sessions in memory are lost (unless stored externally)

Express Example

const express = require("express");
const session = require("express-session");

const app = express();
app.use(express.json());

app.use(
  session({
    secret: "my-secret-key",
    resave: false,
    saveUninitialized: false,
    cookie: { maxAge: 24 * 60 * 60 * 1000 }, // 24 hours
  }),
);

// Login — create session
app.post("/login", (req, res) => {
  const { email, password } = req.body;

  // Validate credentials (simplified)
  if (email === "pratham@dev.in" && password === "secret") {
    req.session.user = { id: 1, name: "Pratham", role: "developer" };
    res.json({ message: "Logged in!" });
  } else {
    res.status(401).json({ error: "Invalid credentials" });
  }
});

// Protected route — check session
app.get("/api/profile", (req, res) => {
  if (!req.session.user) {
    return res.status(401).json({ error: "Not authenticated" });
  }
  res.json({ user: req.session.user });
});

// Logout — destroy session
app.post("/logout", (req, res) => {
  req.session.destroy();
  res.json({ message: "Logged out!" });
});

app.listen(3000);

What Are JWT Tokens?

A JWT (JSON Web Token) is a self-contained token that carries user information inside it. Unlike sessions, the server doesn't need to store anything — all the data the server needs to identify the user is encoded in the token itself.

JWT Structure

A JWT has three parts, separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwibmFtZSI6IlByYXRoYW0ifQ.sG5_Kd7vFj2OqR3Xk1mZp8
└──────── Header ────────┘└──────── Payload ──────────────────┘└────── Signature ──────┘

Part	Contains	Encoded?
Header	Algorithm and token type	Base64 (readable, not encrypted)
Payload	User data (id, name, role, expiry)	Base64 (readable, not encrypted)
Signature	Verification hash (proves data wasn't tampered)	Cryptographic hash

The payload is not encrypted — anyone can decode and read it. The signature ensures that if anyone modifies the payload, the server will detect it.

JWT Authentication Flow

┌──────────┐                              ┌──────────────────┐
│  Client  │                              │     Server       │
│ (Browser/│                              │                  │
│  Mobile) │                              │  No session      │
└────┬─────┘                              │  store needed!   │
     │                                    │                  │
     │  1. POST /login                    │                  │
     │     { email, password }            │                  │
     │ ──────────────────────────────→    │                  │
     │                                    │  2. Validate     │
     │                                    │     credentials  │
     │                                    │                  │
     │                                    │  3. Create JWT:  │
     │                                    │     sign({       │
     │                                    │       id: 1,     │
     │                                    │       name: "P"  │
     │                                    │     }, secret)   │
     │  4. Response: { token: "eyJ..." }  │                  │
     │ ←──────────────────────────────    │                  │
     │                                    │                  │
     │  5. Client STORES token            │                  │
     │     (localStorage / cookie)        │                  │
     │                                    │                  │
     │  6. GET /api/profile               │                  │
     │     Authorization: Bearer eyJ...   │                  │
     │ ──────────────────────────────→    │                  │
     │                                    │  7. Verify JWT   │
     │                                    │     signature    │
     │                                    │     → valid!     │
     │                                    │     Extract user │
     │  8. Response: { user data }        │     from payload │
     │ ←──────────────────────────────    │                  │
     │                                    │                  │
└────┴─────┘                              └──────────────────┘

Key Difference From Sessions

The server doesn't store anything. It creates the token, sends it to the client, and forgets about it. When the client sends it back, the server verifies the signature and reads the payload — no database lookup needed.

Express Example

const express = require("express");
const jwt = require("jsonwebtoken");

const app = express();
app.use(express.json());

const SECRET = "my-jwt-secret-key";

// Login — create JWT
app.post("/login", (req, res) => {
  const { email, password } = req.body;

  if (email === "pratham@dev.in" && password === "secret") {
    const token = jwt.sign(
      { id: 1, name: "Pratham", role: "developer" },
      SECRET,
      { expiresIn: "24h" },
    );
    res.json({ message: "Logged in!", token });
  } else {
    res.status(401).json({ error: "Invalid credentials" });
  }
});

// Middleware — verify JWT
function authenticate(req, res, next) {
  const authHeader = req.headers.authorization;

  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    return res.status(401).json({ error: "No token provided" });
  }

  const token = authHeader.split(" ")[1];

  try {
    const decoded = jwt.verify(token, SECRET);
    req.user = decoded;
    next();
  } catch (error) {
    res.status(403).json({ error: "Invalid or expired token" });
  }
}

// Protected route
app.get("/api/profile", authenticate, (req, res) => {
  res.json({ user: req.user });
});

app.listen(3000);

Stateful vs Stateless Authentication

This is the fundamental architectural difference:

Stateful (Sessions)

The server remembers who you are. It stores session data and looks it up on every request.

Client:  "Here's my session ID: abc123"
Server:  "Let me check my records... abc123... found it!
          You're Pratham, developer. Here's your data."

Stateless (JWT)

The server doesn't remember anything. The token itself contains everything the server needs.

Client:  "Here's my JWT: eyJhbGci..."
Server:  "Let me verify the signature... valid!
          The token says you're Pratham, developer. Here's your data."
          (I never stored anything about you.)

STATEFUL (Session):
┌────────┐     session ID      ┌────────┐
│ Client │ ──────────────────→ │ Server │ ──→ Session Store
│        │ ←────────────────── │        │ ←── (lookup required)
└────────┘     user data       └────────┘

STATELESS (JWT):
┌────────┐     JWT token       ┌────────┐
│ Client │ ──────────────────→ │ Server │     No store needed!
│        │ ←────────────────── │        │     (verify + decode)
└────────┘     user data       └────────┘

Session vs JWT — Comparison Table

Feature	Sessions	JWT
Data stored on	Server (memory, DB, Redis)	Client (token contains the data)
Server state	Stateful — server remembers	Stateless — server forgets
Scalability	Harder — session store shared across servers	Easier — any server can verify the token
Performance	DB/store lookup on every request	Verify signature (no DB lookup)
Revocation	Easy — delete session from store	Hard — token valid until expiry
Storage	Server-side (memory/DB/Redis)	Client-side (cookie/localStorage)
Size	Small (just a session ID in cookie)	Larger (full payload in token)
Best for	Traditional web apps, server-rendered	APIs, mobile apps, microservices
Multiple servers	Need shared session store	Any server with the secret can verify
Logout	Destroy session — instant	Can't truly invalidate until expiry

When to Use Each Method

Use Sessions When:

You're building a traditional server-rendered web app (like with EJS or Pug templates)
You need easy logout — destroy the session and the user is immediately logged out
You want server-side control over active sessions (see who's logged in, force logout)
You're running on a single server or have a shared session store (Redis)
Security is the top priority — session IDs reveal nothing; data stays on the server

Use JWT When:

You're building a REST API consumed by a React frontend, mobile app, or third-party service
You need to scale across multiple servers without sharing state
You're building microservices where different services need to verify authentication independently
You want stateless architecture — no session store to manage
You're building a mobile app where cookies aren't native

The Decision Flowchart

"What am I building?"
     │
     ├── Server-rendered web app (EJS, templates)?
     │     → Use SESSIONS (with cookies)
     │
     ├── REST API + React/mobile frontend?
     │     → Use JWT (in Authorization header)
     │
     ├── Microservices architecture?
     │     → Use JWT (stateless, no shared store)
     │
     └── Need instant logout / session management?
           → Use SESSIONS (easy revocation)

How They Work Together

In practice, these approaches often combine:

JWT in a Cookie

You can store a JWT inside a cookie, getting the benefits of both: the self-contained nature of JWT and the automatic sending of cookies.

// Login — store JWT in an httpOnly cookie
app.post("/login", (req, res) => {
  const token = jwt.sign({ id: 1, name: "Pratham" }, SECRET, {
    expiresIn: "24h",
  });

  res.cookie("token", token, {
    httpOnly: true,
    secure: true,
    sameSite: "strict",
    maxAge: 24 * 60 * 60 * 1000,
  });

  res.json({ message: "Logged in!" });
});

// Protected route — read JWT from cookie
app.get("/api/profile", (req, res) => {
  const token = req.cookies.token;
  if (!token) return res.status(401).json({ error: "Not authenticated" });

  try {
    const user = jwt.verify(token, SECRET);
    res.json({ user });
  } catch (error) {
    res.status(403).json({ error: "Invalid token" });
  }
});

JWT in Authorization Header (API-style)

// Client sends:
fetch("/api/profile", {
  headers: {
    Authorization: `Bearer ${token}`,
  },
});

// Server reads:
const token = req.headers.authorization.split(" ")[1];

Cookie vs Header — When to Use Which

Approach	Best For	Pros
JWT in Cookie	Web apps (same domain)	Automatic, httpOnly (more secure)
JWT in Auth Header	APIs, mobile apps, cross-domain	Flexible, works everywhere

Common Misconceptions

❌ "JWTs are more secure than sessions"

Not necessarily. JWTs can't be revoked easily. If a JWT is stolen, it's valid until it expires. Sessions can be immediately destroyed.

❌ "Cookies are insecure"

Cookies with httpOnly, secure, and sameSite flags are quite secure. They're safer than storing tokens in localStorage because JavaScript can't access them (protecting against XSS attacks).

❌ "You have to choose one or the other"

You can absolutely use JWTs stored in cookies. Many production apps do this — combining the stateless nature of JWT with the automatic and secure transport of cookies.

❌ "Sessions are outdated"

Sessions are still widely used in production. They're excellent for server-rendered apps and scenarios where you need instant session revocation.

Let's Practice: Hands-On Assignment

Part 1: Session-Based Auth

const express = require("express");
const session = require("express-session");

const app = express();
app.use(express.json());
app.use(session({ secret: "secret", resave: false, saveUninitialized: false }));

const users = [{ id: 1, email: "pratham@dev.in", password: "pass123", name: "Pratham" }];

app.post("/login", (req, res) => {
  const user = users.find(
    (u) => u.email === req.body.email && u.password === req.body.password,
  );
  if (!user) return res.status(401).json({ error: "Invalid credentials" });

  req.session.user = { id: user.id, name: user.name };
  res.json({ message: `Welcome, ${user.name}!` });
});

app.get("/profile", (req, res) => {
  if (!req.session.user) return res.status(401).json({ error: "Not logged in" });
  res.json(req.session.user);
});

app.post("/logout", (req, res) => {
  req.session.destroy();
  res.json({ message: "Logged out" });
});

app.listen(3000);

Part 2: JWT-Based Auth

const express = require("express");
const jwt = require("jsonwebtoken");

const app = express();
app.use(express.json());

const SECRET = "jwt-secret";

app.post("/login", (req, res) => {
  // Same user validation...
  const token = jwt.sign({ id: 1, name: "Pratham" }, SECRET, { expiresIn: "1h" });
  res.json({ token });
});

app.get("/profile", (req, res) => {
  const auth = req.headers.authorization;
  if (!auth) return res.status(401).json({ error: "No token" });

  try {
    const user = jwt.verify(auth.split(" ")[1], SECRET);
    res.json(user);
  } catch (e) {
    res.status(403).json({ error: "Invalid token" });
  }
});

app.listen(3000);

Part 3: Compare Both

Build both versions for the same app and test:

Login with both approaches
Access a protected route
Try accessing without auth
Log out (session: destroy session; JWT: delete token on client)
Notice: after "logout," the JWT is still valid if you save it somewhere. The session is truly gone.

Key Takeaways

Cookies are a transport mechanism — they carry data (session IDs or JWTs) between client and server automatically. They are not an authentication method by themselves.
Sessions are stateful — the server stores user data and looks it up via a session ID. Easy to revoke, harder to scale across multiple servers.
JWTs are stateless — the token contains the user data. Easy to scale, harder to revoke before expiry.
Use sessions for server-rendered apps, when you need instant logout, or when running on a single server. Use JWTs for REST APIs, mobile apps, microservices, and cross-server authentication.
They're not mutually exclusive — JWT in a cookie is a common, practical pattern that combines the benefits of both approaches.

Wrapping Up

Sessions, cookies, and JWTs aren't competing technologies — they're different tools that sometimes work together. Cookies carry things. Sessions remember things on the server. JWTs carry things that prove who you are without the server needing to remember. Which one you use depends on what you're building, how you're scaling, and what kind of control you need over user sessions.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. Authentication was the topic where theory and practice collided — understanding why you'd choose sessions over JWT (or vice versa) is just as important as knowing how to implement them.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

REST API Design Made Simple with Express.js

Pratham — Sun, 10 May 2026 12:55:33 +0000

How to design clean, predictable APIs that any developer can understand in 5 seconds.

Before I understood REST, my API routes looked like this:

GET  /getUsers
POST /createNewUser
GET  /fetchSingleUser?id=5
POST /deleteUser
GET  /updateUserName

They worked. But they were inconsistent, confusing, and every route had its own naming convention. If another developer looked at my API, they'd have to read every single route to figure out what was going on.

Then I learned REST — a set of principles that tell you exactly how to name routes, which HTTP methods to use, and how to structure your API so it's predictable, clean, and standard. The same routes above became:

GET    /users
POST   /users
GET    /users/5
DELETE /users/5
PUT    /users/5

No verbs in URLs. Consistent patterns. Any developer who knows REST can look at these routes and immediately understand every one of them — without reading a single line of documentation.

That transformation happened for me in the ChaiCode Web Dev Cohort 2026. Let me show you how REST works.

What Does REST API Mean?

Let's break the term down:

API — Application Programming Interface. It's a way for two programs to communicate. Your frontend (React, a mobile app, or even another server) sends a request to the backend, and the backend sends a response.

┌──────────┐    HTTP Request     ┌──────────┐
│          │ ──────────────────→ │          │
│  Client  │                     │  Server  │
│ (React,  │ ←────────────────── │ (Express │
│  mobile) │    HTTP Response    │   API)   │
└──────────┘                     └──────────┘

REST — Representational State Transfer. It's a set of design principles for how APIs should be structured. It's not a technology or framework — it's a style guide.

A REST API is an API that follows REST principles: using standard HTTP methods, organizing data around resources, and communicating with standard status codes.

Resources in REST Architecture

The core idea of REST is simple: everything is a resource.

A resource is any entity your application manages — users, products, orders, comments, posts. Each resource has a URL (endpoint) that represents it.

Resources in a typical app:

  /users        → The collection of all users
  /users/42     → A specific user (ID: 42)
  /products     → The collection of all products
  /products/7   → A specific product (ID: 7)
  /orders       → The collection of all orders
  /orders/101   → A specific order (ID: 101)

REST Naming Conventions

✅ DO:
  /users          ← plural nouns
  /products       ← describes WHAT, not what to DO
  /orders/101     ← specific resource by ID

❌ DON'T:
  /getUsers       ← verb in URL (the HTTP method IS the verb)
  /createProduct  ← action in URL
  /deleteOrder    ← action in URL
  /user           ← singular (use plural for collections)

The golden rule: URLs are nouns, HTTP methods are verbs. The URL tells you what resource. The method tells you what action to perform on it.

HTTP Methods — The Verbs of REST

REST uses standard HTTP methods to perform actions on resources. Each method maps to a CRUD (Create, Read, Update, Delete) operation:

CRUD vs HTTP Methods Mapping

CRUD Operation	HTTP Method	Express	URL	What It Does
Create	`POST`	`app.post()`	`/users`	Create a new user
Read	`GET`	`app.get()`	`/users`	Get all users
Read	`GET`	`app.get()`	`/users/42`	Get a specific user
Update	`PUT`	`app.put()`	`/users/42`	Replace/update a user completely
Delete	`DELETE`	`app.delete()`	`/users/42`	Delete a specific user

The Pattern

Resource: users

  GET    /users       → Get ALL users         (Read — collection)
  GET    /users/:id   → Get ONE user          (Read — single)
  POST   /users       → Create a NEW user     (Create)
  PUT    /users/:id   → Update an EXISTING user (Update)
  DELETE /users/:id   → Delete a user         (Delete)

Same URL pattern, different HTTP methods = different actions.

GET — Reading Data

GET requests retrieve data. They should never modify anything on the server.

// Get all users
app.get("/api/users", (req, res) => {
  res.json(users);
});

// Get a single user
app.get("/api/users/:id", (req, res) => {
  const user = users.find((u) => u.id === parseInt(req.params.id));
  if (!user) return res.status(404).json({ error: "User not found" });
  res.json(user);
});

POST — Creating Data

POST requests create new resources. The data comes in the request body.

app.post("/api/users", (req, res) => {
  const { name, email, role } = req.body;

  if (!name || !email) {
    return res.status(400).json({ error: "Name and email are required" });
  }

  const newUser = {
    id: users.length + 1,
    name,
    email,
    role: role || "member",
  };

  users.push(newUser);
  res.status(201).json(newUser);
});

PUT — Updating Data

PUT requests replace an existing resource with new data.

app.put("/api/users/:id", (req, res) => {
  const user = users.find((u) => u.id === parseInt(req.params.id));
  if (!user) return res.status(404).json({ error: "User not found" });

  const { name, email, role } = req.body;
  user.name = name || user.name;
  user.email = email || user.email;
  user.role = role || user.role;

  res.json(user);
});

DELETE — Removing Data

DELETE requests remove a resource.

app.delete("/api/users/:id", (req, res) => {
  const index = users.findIndex((u) => u.id === parseInt(req.params.id));
  if (index === -1) return res.status(404).json({ error: "User not found" });

  users.splice(index, 1);
  res.status(204).send(); // 204 = No Content (successfully deleted, nothing to return)
});

Status Codes Basics

HTTP status codes tell the client what happened. They're numbers grouped by category:

1xx — Informational (rarely used directly)
2xx — Success ✅
3xx — Redirection ↗️
4xx — Client Error ❌ (the client did something wrong)
5xx — Server Error 💥 (the server did something wrong)

Status Codes You'll Use Daily

Code	Name	When to Use	Express Example
200	OK	Successful GET, PUT	`res.status(200).json(data)`
201	Created	Successful POST — new resource created	`res.status(201).json(user)`
204	No Content	Successful DELETE — nothing to return	`res.status(204).send()`
400	Bad Request	Client sent invalid data	`res.status(400).json(err)`
401	Unauthorized	No authentication provided	`res.status(401).json(err)`
403	Forbidden	Authenticated but not authorized	`res.status(403).json(err)`
404	Not Found	Resource doesn't exist	`res.status(404).json(err)`
500	Internal Server Error	Something broke on the server	`res.status(500).json(err)`

Matching Status Codes to Operations

GET    /users      → 200 (here's your data)
GET    /users/999  → 404 (that user doesn't exist)
POST   /users      → 201 (user created!)
POST   /users      → 400 (invalid data — name missing)
PUT    /users/42   → 200 (user updated)
DELETE /users/42   → 204 (deleted, nothing to show)
DELETE /users/999  → 404 (can't delete what doesn't exist)

REST Request-Response Lifecycle

Here's the complete picture of how a REST API request flows through Express:

Client: POST /api/users  { "name": "Pratham", "email": "p@dev.in" }
                │
                ↓
┌──────────────────────────────────────────────────────┐
│                 EXPRESS SERVER                         │
│                                                      │
│  1. Middleware:                                       │
│     express.json() → parses body into req.body       │
│     logger → logs "POST /api/users"                  │
│                                                      │
│  2. Router matches:                                   │
│     app.post("/api/users") ← MATCH ✅                │
│                                                      │
│  3. Route handler runs:                               │
│     → Validates req.body (name and email present?)   │
│     → Creates new user object                        │
│     → Adds to database / array                       │
│     → Sends response                                 │
│                                                      │
│  4. Response:                                         │
│     Status: 201 Created                              │
│     Body: { "id": 4, "name": "Pratham", ... }        │
│                                                      │
└──────────────────────────────────────────────────────┘
                │
                ↓
Client receives: 201 { "id": 4, "name": "Pratham", "email": "p@dev.in" }

Complete Example: Users REST API

Let's build a complete, RESTful Users API from scratch:

const express = require("express");
const app = express();

app.use(express.json());

// In-memory "database"
let users = [
  { id: 1, name: "Pratham", email: "pratham@dev.in", role: "developer" },
  { id: 2, name: "Arjun", email: "arjun@dev.in", role: "designer" },
  { id: 3, name: "Priya", email: "priya@dev.in", role: "manager" },
];

let nextId = 4;

// ── GET /api/users — Get all users ──
app.get("/api/users", (req, res) => {
  // Optional filtering with query params
  let result = [...users];

  if (req.query.role) {
    result = result.filter((u) => u.role === req.query.role);
  }

  res.json({
    count: result.length,
    users: result,
  });
});

// ── GET /api/users/:id — Get single user ──
app.get("/api/users/:id", (req, res) => {
  const user = users.find((u) => u.id === parseInt(req.params.id));

  if (!user) {
    return res.status(404).json({ error: "User not found" });
  }

  res.json(user);
});

// ── POST /api/users — Create new user ──
app.post("/api/users", (req, res) => {
  const { name, email, role } = req.body;

  // Validation
  if (!name || !email) {
    return res.status(400).json({
      error: "Validation failed",
      details: {
        name: !name ? "Name is required" : undefined,
        email: !email ? "Email is required" : undefined,
      },
    });
  }

  // Check for duplicate email
  if (users.find((u) => u.email === email)) {
    return res.status(400).json({ error: "Email already exists" });
  }

  const newUser = {
    id: nextId++,
    name,
    email,
    role: role || "member",
  };

  users.push(newUser);
  res.status(201).json(newUser);
});

// ── PUT /api/users/:id — Update user ──
app.put("/api/users/:id", (req, res) => {
  const user = users.find((u) => u.id === parseInt(req.params.id));

  if (!user) {
    return res.status(404).json({ error: "User not found" });
  }

  const { name, email, role } = req.body;
  user.name = name || user.name;
  user.email = email || user.email;
  user.role = role || user.role;

  res.json(user);
});

// ── DELETE /api/users/:id — Delete user ──
app.delete("/api/users/:id", (req, res) => {
  const index = users.findIndex((u) => u.id === parseInt(req.params.id));

  if (index === -1) {
    return res.status(404).json({ error: "User not found" });
  }

  const deleted = users.splice(index, 1)[0];
  res.json({ message: "User deleted", user: deleted });
});

// ── 404 handler — route not found ──
app.use((req, res) => {
  res.status(404).json({ error: `Route ${req.method} ${req.url} not found` });
});

const PORT = 3000;
app.listen(PORT, () => {
  console.log(`REST API running at http://localhost:${PORT}/api/users`);
});

Testing the API

# Get all users
curl http://localhost:3000/api/users

# Get all developers
curl http://localhost:3000/api/users?role=developer

# Get user by ID
curl http://localhost:3000/api/users/1

# Create a new user
curl -X POST http://localhost:3000/api/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Neha", "email": "neha@dev.in", "role": "tester"}'

# Update a user
curl -X PUT http://localhost:3000/api/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name": "Pratham Bhardwaj", "role": "senior developer"}'

# Delete a user
curl -X DELETE http://localhost:3000/api/users/2

Route Summary

Method	Endpoint	Body	Response	Status
GET	`/api/users`	—	All users	200
GET	`/api/users/1`	—	Single user	200
GET	`/api/users/999`	—	Error	404
POST	`/api/users`	`{ name, email, role }`	Created user	201
POST	`/api/users`	`{ }` (missing fields)	Validation error	400
PUT	`/api/users/1`	`{ name, role }`	Updated user	200
DELETE	`/api/users/2`	—	Deleted user	200

REST Design Principles — Quick Reference

Principle	What It Means
Use nouns in URLs	`/users`, not `/getUsers` or `/createUser`
Use plural nouns	`/users`, not `/user`
HTTP methods = actions	GET reads, POST creates, PUT updates, DELETE removes
Use proper status codes	201 for creation, 404 for not found, etc.
Nest related resources	`/users/42/orders` — orders belonging to user 42
Use query for filtering	`/users?role=admin&sort=name`, not `/users/role/admin`
Be consistent	Same patterns across all resources
Stateless	Each request contains all info needed — no server memory

Let's Practice: Hands-On Assignment

Part 1: Design REST Routes

Before writing any code, design the routes for a blog API with two resources: posts and comments.

Posts:
  GET    /api/posts          → All posts
  GET    /api/posts/:id      → Single post
  POST   /api/posts          → Create post
  PUT    /api/posts/:id      → Update post
  DELETE /api/posts/:id      → Delete post

Comments (nested under posts):
  GET    /api/posts/:id/comments      → All comments on a post
  POST   /api/posts/:id/comments      → Add comment to a post
  DELETE /api/posts/:postId/comments/:commentId → Delete a comment

Part 2: Build the Posts API

Implement the 5 post routes with validation (title and content required for POST).

Part 3: Add Nested Comments

Add the comment routes. Each comment should reference its parent post's ID.

Key Takeaways

REST is a design style, not a technology. It uses standard HTTP methods as verbs and resource URLs as nouns to create predictable, consistent APIs.
CRUD maps to HTTP methods: Create → POST, Read → GET, Update → PUT, Delete → DELETE. Each action has a specific method — don't use GET for everything.
URLs should be nouns (/users, /products), never verbs (/getUsers). The HTTP method already tells you the action.
Status codes communicate outcomes: 200 for success, 201 for created, 400 for bad input, 404 for not found, 500 for server errors.
Design your routes for one resource at a time (users, then orders, then products). The pattern is always the same — once you've built one RESTful resource, you can build them all.

Wrapping Up

REST isn't complicated — it's a set of conventions that make APIs predictable. Once you know the pattern (nouns for URLs, HTTP methods for actions, status codes for results), you can design any API. And the beauty is that every developer who knows REST can understand your API instantly, without documentation.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. Building my first proper REST API was the moment backend development stopped being "writing server code" and started being "designing systems." It's a mindset shift, and once it clicks, every API you build will be clean, consistent, and professional.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

What Is Middleware in Express and How It Works

Pratham — Sun, 10 May 2026 12:45:10 +0000

The checkpoint system between request and response — where logging, authentication, and validation live.

When I first saw this code in Express, I had no idea what it was doing:

app.use((req, res, next) => {
  console.log(`${req.method} ${req.url}`);
  next();
});

It's not a route. It doesn't send a response. And what's next()? Why do we need to call it? What happens if we don't?

This, I learned, is middleware — and it's the most powerful concept in Express. Every request that hits your server passes through middleware before it reaches your route handler. It's where you log requests, check authentication, validate data, parse bodies, and handle errors — all without cluttering your route logic.

Understanding middleware was the moment Express went from "a routing library" to "a complete application framework" in my mind. Let me break it down the way it clicked for me in the ChaiCode Web Dev Cohort 2026.

What Is Middleware?

Middleware is a function that runs between the incoming request and the final response. It has access to the request object (req), the response object (res), and a function called next() that passes control to the next middleware or route handler.

The Checkpoint Analogy

Think of your Express app as an airport. A request is a passenger trying to board a plane (get a response). Between arriving at the airport and boarding, the passenger goes through multiple checkpoints:

Passenger (Request) arrives at the airport
        │
        ↓
┌──────────────────────┐
│  Checkpoint 1:       │
│  Ticket Check        │  ← "Do you have a valid request?"
│  (Logging middleware) │
└──────────┬───────────┘
           │ ✅ Pass → next()
           ↓
┌──────────────────────┐
│  Checkpoint 2:       │
│  Security Scan       │  ← "Are you authorized?"
│  (Auth middleware)   │
└──────────┬───────────┘
           │ ✅ Pass → next()
           ↓
┌──────────────────────┐
│  Checkpoint 3:       │
│  Baggage Check       │  ← "Is your data valid?"
│  (Validation)        │
└──────────┬───────────┘
           │ ✅ Pass → next()
           ↓
┌──────────────────────┐
│  Gate (Route Handler)│
│  Board the plane!    │  ← Response sent ✈️
└──────────────────────┘

If ANY checkpoint fails → passenger is stopped (error response).
If ALL checkpoints pass → passenger boards (route handler runs).

Each checkpoint can:

Inspect the request (read headers, body, URL)
Modify the request (add properties, transform data)
End the request (send a response early — like a 401 Unauthorized)
Pass control to the next checkpoint (next())

Middleware Function Signature

Every middleware function has the same signature:

function myMiddleware(req, res, next) {
  // Do something with req or res
  next(); // Pass control to the next middleware
}

Three parameters:

req — the request object (incoming data)
res — the response object (what you send back)
next — a function that calls the next middleware in the chain

Using Middleware

// Register middleware with app.use()
app.use(myMiddleware);

Where Middleware Sits in the Request Lifecycle

Client sends HTTP request
        │
        ↓
┌──────────────────────────────────────────┐
│            EXPRESS APPLICATION             │
│                                          │
│   Middleware 1 (logging)                 │
│       │ next()                           │
│       ↓                                  │
│   Middleware 2 (body parser)             │
│       │ next()                           │
│       ↓                                  │
│   Middleware 3 (authentication)          │
│       │ next()                           │
│       ↓                                  │
│   Route Handler (app.get, app.post...)   │
│       │ res.json() / res.send()          │
│       ↓                                  │
│   Response sent to client                │
│                                          │
└──────────────────────────────────────────┘

Middleware runs in the order it's defined. The request flows through each middleware, one by one, until a response is sent or an error occurs.

The `next()` Function — The Key to Everything

next() is what makes the middleware chain work. Without it, the request gets stuck.

With `next()` — Chain Continues

app.use((req, res, next) => {
  console.log("Middleware 1: I ran!");
  next(); // ← Pass to the next middleware/route
});

app.use((req, res, next) => {
  console.log("Middleware 2: I ran too!");
  next(); // ← Pass to the route handler
});

app.get("/", (req, res) => {
  res.send("Response sent!");
});

// Output for GET /:
// Middleware 1: I ran!
// Middleware 2: I ran too!
// Response: "Response sent!"

Without `next()` — Chain Stops

app.use((req, res, next) => {
  console.log("Middleware 1: I ran!");
  // next() NOT called — request is STUCK here
});

app.get("/", (req, res) => {
  res.send("You'll never see this!"); // ← Never executes
});

// Output for GET /:
// Middleware 1: I ran!
// (request hangs... browser shows loading spinner forever)

Ending Early — Sending a Response Instead of `next()`

Sometimes middleware should stop the chain. For example, authentication:

app.use((req, res, next) => {
  if (!req.headers.authorization) {
    return res.status(401).json({ error: "Unauthorized — no token provided" });
    // No next() — request ends here!
  }
  next(); // Token exists, continue to route handler
});

The rule is simple: every middleware must either call next() or send a response. Never do neither, never do both.

Execution Order of Middleware

Middleware runs in the order you define it in your code. This order matters:

const express = require("express");
const app = express();

// Middleware 1 — runs FIRST
app.use((req, res, next) => {
  console.log("1. Logging");
  req.requestTime = new Date().toISOString();
  next();
});

// Middleware 2 — runs SECOND
app.use((req, res, next) => {
  console.log("2. Auth check");
  next();
});

// Middleware 3 — runs THIRD
app.use(express.json()); // built-in body parser

// Route handler — runs LAST
app.get("/", (req, res) => {
  console.log("4. Route handler");
  res.json({ time: req.requestTime });
});

app.listen(3000);

Request: GET /
  → 1. Logging
  → 2. Auth check
  → 3. Body parser (silent)
  → 4. Route handler → response sent

Multiple Middleware Execution Chain

Request arrives
    │
    ↓
┌───────────┐  next()  ┌───────────┐  next()  ┌───────────┐  next()  ┌──────────┐
│ Logger    │ ──────→ │ Auth      │ ──────→ │ Parser   │ ──────→ │ Route    │
│           │         │ Check     │         │ (JSON)   │         │ Handler  │
└───────────┘         └───────────┘         └───────────┘         └────┬─────┘
                                                                       │
                                                                  res.json()
                                                                       │
                                                                       ↓
                                                                  Response sent
                                                                  to client

If you define the auth middleware after the route, the route runs without authentication. Order is everything.

Types of Middleware

1. Application-Level Middleware

Middleware that applies to the entire app — every request goes through it.

// Applies to ALL routes
app.use((req, res, next) => {
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
  next();
});

You can also limit it to specific paths:

// Only applies to routes starting with /api
app.use("/api", (req, res, next) => {
  console.log("API request detected");
  next();
});

2. Router-Level Middleware

Middleware that applies to a specific group of routes using express.Router():

const express = require("express");
const router = express.Router();

// This middleware only applies to routes in this router
router.use((req, res, next) => {
  console.log("Admin route accessed");
  next();
});

router.get("/dashboard", (req, res) => {
  res.json({ page: "Admin Dashboard" });
});

router.get("/settings", (req, res) => {
  res.json({ page: "Admin Settings" });
});

// Mount the router at /admin
app.use("/admin", router);

// GET /admin/dashboard → middleware runs, then route handler
// GET /users → middleware does NOT run (different path)

3. Built-In Middleware

Express comes with a few middleware functions out of the box:

// Parse JSON request bodies
app.use(express.json());

// Parse URL-encoded form data
app.use(express.urlencoded({ extended: true }));

// Serve static files (CSS, images, JS)
app.use(express.static("public"));

Built-In Middleware	What It Does
`express.json()`	Parses JSON request bodies → `req.body`
`express.urlencoded()`	Parses form submissions → `req.body`
`express.static("dir")`	Serves files from a directory (HTML, CSS, images)

4. Third-Party Middleware

Middleware from npm packages:

const cors = require("cors");
const helmet = require("helmet");
const morgan = require("morgan");

app.use(cors()); // Enable Cross-Origin requests
app.use(helmet()); // Set security headers
app.use(morgan("dev")); // HTTP request logging

5. Error-Handling Middleware

Special middleware with four parameters — (err, req, res, next):

app.use((err, req, res, next) => {
  console.error("Error:", err.message);
  res.status(500).json({ error: "Something went wrong!" });
});

Express recognizes this as error-handling middleware because of the four-parameter signature. It only runs when an error is thrown or passed via next(err).

Real-World Examples

Example 1: Request Logger

function logger(req, res, next) {
  const start = Date.now();

  // This runs AFTER the response is sent
  res.on("finish", () => {
    const duration = Date.now() - start;
    console.log(
      `${req.method} ${req.url} → ${res.statusCode} (${duration}ms)`,
    );
  });

  next();
}

app.use(logger);

// Output:
// GET /api/users → 200 (12ms)
// POST /api/users → 201 (45ms)
// GET /api/missing → 404 (3ms)

Example 2: Authentication

function authenticate(req, res, next) {
  const token = req.headers.authorization;

  if (!token) {
    return res.status(401).json({ error: "No token provided" });
  }

  if (token !== "Bearer my-secret-token") {
    return res.status(403).json({ error: "Invalid token" });
  }

  // Token is valid — attach user info to request
  req.user = { id: 1, name: "Pratham", role: "admin" };
  next();
}

// Public route — no auth needed
app.get("/", (req, res) => {
  res.json({ message: "Welcome! This is public." });
});

// Protected routes — auth required
app.get("/api/profile", authenticate, (req, res) => {
  res.json({ user: req.user });
});

app.get("/api/dashboard", authenticate, (req, res) => {
  res.json({ message: `Welcome back, ${req.user.name}!` });
});

Notice: authenticate is passed as an argument to the route, not via app.use(). This makes it apply to only specific routes — not everything.

Example 3: Request Validation

function validateUser(req, res, next) {
  const { name, email } = req.body;
  const errors = [];

  if (!name || name.trim().length === 0) {
    errors.push("Name is required");
  }

  if (!email || !email.includes("@")) {
    errors.push("Valid email is required");
  }

  if (errors.length > 0) {
    return res.status(400).json({ errors });
  }

  next();
}

app.post("/api/users", validateUser, (req, res) => {
  // If we reach here, validation passed!
  const user = { id: Date.now(), ...req.body };
  res.status(201).json({ message: "User created!", user });
});

The route handler only runs if validation passes. Clean separation of concerns.

Middleware Patterns — Practical Combinations

Here's how middleware typically looks in a real Express app:

const express = require("express");
const app = express();

// ── Global Middleware (runs on EVERY request) ──
app.use(express.json());
app.use(express.urlencoded({ extended: true }));

app.use((req, res, next) => {
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
  next();
});

// ── Public Routes (no auth needed) ──
app.get("/", (req, res) => {
  res.json({ message: "Public home page" });
});

app.post("/login", (req, res) => {
  // Login logic...
  res.json({ token: "abc123" });
});

// ── Auth Middleware (applies to everything below) ──
app.use((req, res, next) => {
  const token = req.headers.authorization;
  if (!token) return res.status(401).json({ error: "Unauthorized" });
  req.user = { name: "Pratham" }; // Decoded from token
  next();
});

// ── Protected Routes (auth required) ──
app.get("/api/profile", (req, res) => {
  res.json({ user: req.user });
});

app.get("/api/settings", (req, res) => {
  res.json({ settings: { theme: "dark" } });
});

// ── Error Handler (must be LAST) ──
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: "Internal server error" });
});

app.listen(3000);

Flow for GET /api/profile:

  1. express.json()        → parses body (global)
  2. Logger                → logs "GET /api/profile" (global)
  3. Auth middleware        → checks token, attaches req.user
  4. Route handler         → sends { user: req.user }

Flow for GET / (public):

  1. express.json()        → parses body (global)
  2. Logger                → logs "GET /" (global)
  3. Route handler         → sends { message: "Public home page" }
  (Auth middleware is defined AFTER this route — never runs!)

Let's Practice: Hands-On Assignment

Part 1: Build a Logger Middleware

const express = require("express");
const app = express();

// Your logger middleware
app.use((req, res, next) => {
  const timestamp = new Date().toISOString();
  console.log(`[${timestamp}] ${req.method} ${req.url}`);
  next();
});

app.get("/", (req, res) => res.send("Home"));
app.get("/about", (req, res) => res.send("About"));
app.get("/api/data", (req, res) => res.json({ data: [1, 2, 3] }));

app.listen(3000);
// Visit each route — see the logs appear in your terminal

Part 2: Add Authentication Middleware

function auth(req, res, next) {
  const apiKey = req.headers["x-api-key"];
  if (apiKey !== "secret123") {
    return res.status(401).json({ error: "Invalid API key" });
  }
  next();
}

// Public
app.get("/", (req, res) => res.send("Public — no key needed"));

// Protected
app.get("/api/secret", auth, (req, res) => {
  res.json({ message: "You have access!" });
});

// Test without key: curl http://localhost:3000/api/secret
// Test with key: curl -H "x-api-key: secret123" http://localhost:3000/api/secret

Part 3: Build a Request Timing Middleware

app.use((req, res, next) => {
  req.startTime = Date.now();

  res.on("finish", () => {
    const duration = Date.now() - req.startTime;
    console.log(`${req.method} ${req.url} → ${res.statusCode} [${duration}ms]`);
  });

  next();
});

Key Takeaways

Middleware is a function that runs between request and response. It can inspect, modify, or end the request. Every middleware must either call next() or send a response.
next() passes control to the next middleware in the chain. Without it, the request hangs. Middleware executes in the order it's defined — order matters.
Types: Application-level (global), router-level (grouped), built-in (express.json()), third-party (cors, helmet), and error-handling (4 parameters).
Route-specific middleware is passed as an argument to the route: app.get("/path", authMiddleware, handler). This keeps public routes public and protected routes protected.
Middleware enables separation of concerns — logging, auth, validation, and error handling each live in their own function, not tangled inside route handlers.

Wrapping Up

Middleware is what makes Express more than a router — it's the backbone of the entire request pipeline. Logging? Middleware. Authentication? Middleware. Body parsing? Middleware. Error handling? Middleware. Once you understand the req → middleware → middleware → route → res flow, you can build any feature by plugging in the right middleware at the right place.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. Middleware was the concept that turned my Express apps from "routes that do everything" into "clean, organized, production-ready code." It's the architectural pattern that makes everything else possible.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

URL Parameters vs Query Strings in Express.js

Pratham — Sun, 10 May 2026 12:38:30 +0000

Two ways to pass data through URLs — and knowing when to use each one.

When I first started building APIs with Express, I kept confusing two things: when should the data go in the URL, and when should it go after the URL? Like, what's the difference between these two requests?

/users/42
/users?id=42

Both pass the number 42 to the server. Both work. But they mean fundamentally different things, and using the wrong one leads to messy, confusing APIs that other developers (and your future self) will hate.

The answer came down to a simple mental model I picked up in the ChaiCode Web Dev Cohort 2026: URL parameters identify what you want. Query strings modify how you want it. Once that clicked, I never confused them again.

Let me show you.

URL Structure Breakdown

Before diving into the differences, let's understand what a URL actually looks like:

https://api.example.com/users/42/orders?status=shipped&page=2
└─┬──┘  └──────┬──────┘└────┬────┘└─┬─┘ └──────────┬──────────┘
scheme      host        path     params    query string

Let's zoom in on the parts we care about:

/users/42/orders?status=shipped&page=2
│      │   │      │               │
│      │   │      └── query       └── query
│      │   │          parameter       parameter
│      │   │          key=value       key=value
│      │   │
│      │   └── path segment
│      │
│      └── URL parameter (dynamic — changes per request)
│
└── path segment (static — always "users")

Two different mechanisms in the same URL. Let me explain each one.

What Are URL Parameters?

URL parameters (also called route parameters or path parameters) are dynamic segments inside the URL path. They're placeholders for specific values — typically identifiers.

In Express, you define them with a colon (:):

app.get("/users/:id", (req, res) => {
  console.log(req.params.id); // whatever value is in that position
});

Examples

Route definition: /users/:id

  /users/1      → req.params.id = "1"
  /users/42     → req.params.id = "42"
  /users/abc    → req.params.id = "abc"

Route definition: /products/:category/:productId

  /products/electronics/500
    → req.params.category = "electronics"
    → req.params.productId = "500"

  /products/books/101
    → req.params.category = "books"
    → req.params.productId = "101"

Key Characteristics

Part of the URL path (before the ?)
Defined with :name in the route definition
Accessed via req.params
Represent what resource you're requesting
Usually required — the route won't match without them

Real-World URL Parameters

GET /users/42                    → Get user with ID 42
GET /posts/15                    → Get post with ID 15
GET /users/42/orders             → Get all orders for user 42
GET /products/electronics/500    → Get product 500 in electronics
DELETE /comments/789             → Delete comment with ID 789

Notice the pattern: every URL parameter is an identifier — it points to a specific resource.

What Are Query Parameters?

Query parameters (also called query strings) are key-value pairs that come after the ? in a URL. They're used for filtering, sorting, searching, and modifying how the server processes the request.

In Express, you access them via req.query:

app.get("/users", (req, res) => {
  console.log(req.query); // { role: "admin", page: "2" }
});

Examples

URL: /users?role=admin

  req.query.role = "admin"

URL: /products?category=electronics&minPrice=100&maxPrice=500&sort=price

  req.query.category = "electronics"
  req.query.minPrice = "100"
  req.query.maxPrice = "500"
  req.query.sort = "price"

Key Characteristics

Come after the ? in the URL
Format: key=value, separated by &
Accessed via req.query
Represent how to filter, sort, or modify the response
Always optional — the route works without them

Real-World Query Parameters

GET /users?role=admin&active=true       → Get active admin users
GET /products?sort=price&order=asc      → Get products sorted by price
GET /search?q=nodejs&page=3&limit=20    → Search "nodejs", page 3, 20 results
GET /orders?status=shipped&from=2026-01 → Get shipped orders from January
GET /posts?tag=javascript               → Get posts tagged "javascript"

Notice the pattern: every query parameter modifies the response — it doesn't change what resource you're requesting, it changes how that resource is filtered or presented.

Params vs Query — Comparison Diagram

┌───────────────────────────────────────────────────────────┐
│                                                           │
│  URL PARAMETERS                  QUERY PARAMETERS         │
│  (identifiers)                   (modifiers)              │
│                                                           │
│  /users/42                       /users?role=admin        │
│        ↑                               ↑                 │
│    "WHICH user?"                 "WHICH KIND of users?"   │
│    → A specific one              → A filtered list        │
│                                                           │
│  In the PATH                     After the ?              │
│  req.params                      req.query                │
│  Required                        Optional                 │
│  Identifies a resource           Modifies the response    │
│                                                           │
│  Think: NOUN                     Think: ADJECTIVE         │
│  "Give me user 42"               "Give me admin users"    │
│                                                           │
└───────────────────────────────────────────────────────────┘

Accessing Params in Express

Single Parameter

// Route: /users/:id
app.get("/users/:id", (req, res) => {
  const userId = req.params.id;

  // Find user (simulated)
  const user = users.find((u) => u.id === parseInt(userId));

  if (!user) {
    return res.status(404).json({ error: "User not found" });
  }

  res.json(user);
});

// GET /users/1   → { id: 1, name: "Pratham", role: "developer" }
// GET /users/999 → { error: "User not found" }

Multiple Parameters

// Route: /users/:userId/posts/:postId
app.get("/users/:userId/posts/:postId", (req, res) => {
  const { userId, postId } = req.params;

  res.json({
    message: `Fetching post ${postId} by user ${userId}`,
  });
});

// GET /users/5/posts/12
// → { message: "Fetching post 12 by user 5" }

Important: Params Are Always Strings

app.get("/users/:id", (req, res) => {
  console.log(typeof req.params.id); // "string" — always!

  // Convert to number when needed
  const id = parseInt(req.params.id);

  // Or check if it's a valid number
  if (isNaN(id)) {
    return res.status(400).json({ error: "Invalid user ID" });
  }

  // Now use the numeric id
});

Accessing Query Strings in Express

Basic Query

app.get("/search", (req, res) => {
  const searchTerm = req.query.q;
  const page = parseInt(req.query.page) || 1;
  const limit = parseInt(req.query.limit) || 10;

  res.json({
    searching: searchTerm,
    page,
    limit,
    message: `Showing ${limit} results for "${searchTerm}" (page ${page})`,
  });
});

// GET /search?q=express&page=2&limit=5
// → { searching: "express", page: 2, limit: 5, message: "..." }

// GET /search?q=nodejs
// → { searching: "nodejs", page: 1, limit: 10, message: "..." }
// (page and limit use defaults when not provided)

Filtering a Collection

const products = [
  { id: 1, name: "Laptop", category: "electronics", price: 75000 },
  { id: 2, name: "Shirt", category: "clothing", price: 1500 },
  { id: 3, name: "Phone", category: "electronics", price: 25000 },
  { id: 4, name: "Jeans", category: "clothing", price: 2500 },
  { id: 5, name: "Headphones", category: "electronics", price: 3000 },
];

app.get("/api/products", (req, res) => {
  let result = [...products];

  // Filter by category (optional)
  if (req.query.category) {
    result = result.filter((p) => p.category === req.query.category);
  }

  // Filter by max price (optional)
  if (req.query.maxPrice) {
    result = result.filter((p) => p.price <= parseInt(req.query.maxPrice));
  }

  // Sort by field (optional)
  if (req.query.sort) {
    result.sort((a, b) => {
      if (req.query.order === "desc") return b[req.query.sort] - a[req.query.sort];
      return a[req.query.sort] - b[req.query.sort];
    });
  }

  res.json(result);
});

// GET /api/products
// → All 5 products

// GET /api/products?category=electronics
// → Laptop, Phone, Headphones

// GET /api/products?category=electronics&maxPrice=10000
// → Phone, Headphones

// GET /api/products?sort=price&order=desc
// → Sorted by price, highest first

Every query parameter is optional. The route works without any of them and returns all products. Add query parameters to narrow down the results.

Important: Query Values Are Always Strings

app.get("/example", (req, res) => {
  // GET /example?count=5&active=true

  console.log(typeof req.query.count); // "string"
  console.log(typeof req.query.active); // "string"

  // Convert as needed:
  const count = parseInt(req.query.count); // 5 (number)
  const active = req.query.active === "true"; // true (boolean)
});

When to Use Params vs Query — Decision Guide

Scenario	Use	Example
Get a specific user	URL Param	`GET /users/42`
Get all users filtered by role	Query String	`GET /users?role=admin`
Get a specific product	URL Param	`GET /products/101`
Search products by keyword	Query String	`GET /products?search=laptop`
Get a specific order	URL Param	`GET /orders/555`
Get orders filtered by status	Query String	`GET /orders?status=shipped`
Get a user's specific post	URL Params	`GET /users/42/posts/7`
Get a user's posts sorted by date	Both	`GET /users/42/posts?sort=date`
Paginate a list	Query String	`GET /posts?page=3&limit=20`
Delete a specific comment	URL Param	`DELETE /comments/89`

The Simple Rule

Ask yourself: "Am I identifying a SPECIFIC resource?"
  → YES → URL Parameter (/users/42)
  → NO  → Query String (/users?role=admin)

Or even simpler:
  → REQUIRED identifier → URL Param
  → OPTIONAL modifier   → Query String

Both Together — Common Pattern

Most real APIs use both in the same request:

// URL param identifies WHICH user
// Query string modifies WHICH posts to return
app.get("/users/:id/posts", (req, res) => {
  const userId = req.params.id; // which user
  const { tag, sort, page } = req.query; // how to filter posts

  res.json({
    user: userId,
    filters: { tag, sort, page },
    message: `Posts by user ${userId}, filtered by tag="${tag}", sorted by ${sort}, page ${page}`,
  });
});

// GET /users/42/posts?tag=javascript&sort=newest&page=2
// → Posts by user 42, tagged "javascript", newest first, page 2

URL params tell you what. Query strings tell you how.

Common Mistakes

❌ Using Query Strings for Resource Identification

BAD:  GET /users?id=42        ← id is required, should be a param
GOOD: GET /users/42            ← clean, RESTful

❌ Using URL Params for Optional Filters

BAD:  GET /users/role/admin    ← what if no filter is needed?
GOOD: GET /users?role=admin    ← optional, clean

❌ Putting Everything in Query Strings

BAD:  GET /api?resource=users&id=42&action=posts&postId=7
GOOD: GET /api/users/42/posts/7

❌ Forgetting to Parse Types

// Query values are always strings!
// GET /products?minPrice=100

// ❌ This comparison fails (string vs number)
if (product.price > req.query.minPrice) { ... }

// ✅ Parse the string to a number first
if (product.price > parseInt(req.query.minPrice)) { ... }

Let's Practice: Hands-On Assignment

Part 1: URL Parameters

const express = require("express");
const app = express();

const users = [
  { id: 1, name: "Pratham", role: "developer" },
  { id: 2, name: "Arjun", role: "designer" },
  { id: 3, name: "Priya", role: "manager" },
];

// Get user by ID
app.get("/users/:id", (req, res) => {
  const user = users.find((u) => u.id === parseInt(req.params.id));
  if (!user) return res.status(404).json({ error: "User not found" });
  res.json(user);
});

app.listen(3000);

// Test: /users/1, /users/2, /users/99

Part 2: Query Strings

// Get users with optional filtering
app.get("/users", (req, res) => {
  let result = [...users];

  if (req.query.role) {
    result = result.filter((u) => u.role === req.query.role);
  }

  if (req.query.search) {
    result = result.filter((u) =>
      u.name.toLowerCase().includes(req.query.search.toLowerCase()),
    );
  }

  res.json({ count: result.length, users: result });
});

// Test: /users, /users?role=developer, /users?search=ar

Part 3: Combine Both

const posts = [
  { id: 1, userId: 1, title: "Learning Node.js", tag: "backend" },
  { id: 2, userId: 1, title: "Express Routing", tag: "backend" },
  { id: 3, userId: 2, title: "UI Design Tips", tag: "design" },
  { id: 4, userId: 1, title: "Async Patterns", tag: "backend" },
];

app.get("/users/:id/posts", (req, res) => {
  const userId = parseInt(req.params.id);
  let userPosts = posts.filter((p) => p.userId === userId);

  if (req.query.tag) {
    userPosts = userPosts.filter((p) => p.tag === req.query.tag);
  }

  res.json({
    userId,
    totalPosts: userPosts.length,
    posts: userPosts,
  });
});

// Test: /users/1/posts
//       /users/1/posts?tag=backend
//       /users/2/posts

Key Takeaways

URL parameters (:id) are dynamic segments in the URL path. They identify which specific resource you want. Accessed via req.params.
Query parameters (?key=value) come after the ? in the URL. They filter, sort, or modify the response. Accessed via req.query.
Params = identifiers, Query = modifiers. "Give me user 42" vs "Give me admin users."
Both values are always strings. Parse to numbers or booleans as needed with parseInt() or === "true".
Use params for required resource identification. Use query strings for optional filtering, sorting, pagination, and search.

Wrapping Up

The difference between URL parameters and query strings is one of those things that seems minor but shapes how clean and intuitive your API is. Using the right one in the right situation makes your routes readable, your API RESTful, and your code easy to maintain. Use params to identify. Use queries to modify. Combine them for powerful, flexible endpoints.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. Getting routing right early — especially the param vs query distinction — saves you from massive refactors later. It's a small detail with big impact.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Creating Routes and Handling Requests with Express

Pratham — Sun, 10 May 2026 12:32:36 +0000

How Express turns Node.js from "I can build a server" to "I can build a server in 5 minutes."

In the last article, we built an HTTP server with raw Node.js. It worked. But let me be honest — it was painful. Manually parsing URLs, setting headers, checking req.url with if-else chains, handling different HTTP methods... for a simple 3-page site, it was already getting messy.

Now imagine building an API with 20 routes, request body parsing, error handling, and middleware. With raw Node.js? That's weeks of boilerplate code.

This is why Express.js exists. It takes everything tedious about raw Node.js HTTP handling and gives you a clean, minimal API to do the same thing in a fraction of the code. Express is to Node.js what a power drill is to a screwdriver — same job, dramatically faster.

Let me show you how it works. This was one of those "why didn't I learn this sooner" moments in the ChaiCode Web Dev Cohort 2026.

What Is Express.js?

Express.js is a lightweight web framework for Node.js. It sits on top of Node's built-in http module and adds:

Routing — map URLs to handler functions cleanly
Middleware — plug in reusable logic (logging, parsing, auth)
Request/Response helpers — req.params, req.body, res.json(), res.status()
Simpler syntax — less boilerplate, more focus on your logic

Node.js (raw):
  const http = require("http");
  http.createServer((req, res) => {
    if (req.url === "/users" && req.method === "GET") { ... }
    if (req.url === "/users" && req.method === "POST") { ... }
    // manual parsing, manual headers, manual everything
  });

Express:
  const app = express();
  app.get("/users", handler);
  app.post("/users", handler);
  // done. Express handles the rest.

Express is the most popular Node.js framework by far — used by companies like Uber, IBM, and Accenture. It's minimal enough to learn quickly but powerful enough for production apps.

Why Express Simplifies Node.js Development

Let me prove it. Here's the same server — raw Node.js vs Express — doing the exact same thing.

Raw Node.js

const http = require("http");

const server = http.createServer((req, res) => {
  if (req.url === "/" && req.method === "GET") {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ message: "Welcome to the API" }));
  } else if (req.url === "/users" && req.method === "GET") {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify([{ name: "Pratham" }, { name: "Arjun" }]));
  } else if (req.url === "/users" && req.method === "POST") {
    let body = "";
    req.on("data", (chunk) => (body += chunk));
    req.on("end", () => {
      const user = JSON.parse(body);
      res.writeHead(201, { "Content-Type": "application/json" });
      res.end(JSON.stringify({ created: user }));
    });
  } else {
    res.writeHead(404, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ error: "Not found" }));
  }
});

server.listen(3000);

27 lines. Manual URL checking, manual method checking, manual body parsing, manual headers everywhere.

Express

const express = require("express");
const app = express();

app.use(express.json()); // Parse JSON bodies automatically

app.get("/", (req, res) => {
  res.json({ message: "Welcome to the API" });
});

app.get("/users", (req, res) => {
  res.json([{ name: "Pratham" }, { name: "Arjun" }]);
});

app.post("/users", (req, res) => {
  res.status(201).json({ created: req.body });
});

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

18 lines. Clean routing, automatic JSON parsing, built-in response helpers. Same functionality, half the code, ten times more readable.

Setting Up Express

Initialize a Project

mkdir express-app
cd express-app
npm init -y

Install Express

npm install express

This adds Express to your node_modules folder and records it in package.json under dependencies.

Verify Installation

Your package.json should include:

{
  "dependencies": {
    "express": "^4.18.2"
  }
}

Creating Your First Express Server

// server.js

const express = require("express");
const app = express();
const PORT = 3000;

app.get("/", (req, res) => {
  res.send("Hello from Express! 🚀");
});

app.listen(PORT, () => {
  console.log(`Server running at http://localhost:${PORT}`);
});

Run it:

node server.js

Visit http://localhost:3000 in your browser. You'll see: Hello from Express! 🚀

What Each Line Does

const express = require("express");  // Import Express
const app = express();               // Create an Express application
const PORT = 3000;                   // Define the port

app.get("/", (req, res) => {         // When someone visits "/"...
  res.send("Hello from Express!");   // ...send this response
});

app.listen(PORT, () => {             // Start listening for requests
  console.log(`Server running...`);
});

Express Routing — The Core Concept

Routing means connecting a URL path + HTTP method to a handler function. When a request matches a route, the handler runs.

Route Structure

app.METHOD(PATH, HANDLER);

METHOD — get, post, put, patch, delete
PATH — the URL pattern (/, /users, /products/:id)
HANDLER — the function that runs when the route matches

Express Routing Structure

Incoming Request: GET /users
        │
        ↓
┌──────────────────────────────────────────┐
│              EXPRESS APP                  │
│                                          │
│  app.get("/")          ← doesn't match   │
│  app.get("/users")     ← MATCH! ✅       │
│  app.post("/users")    ← wrong method    │
│  app.get("/products")  ← doesn't match   │
│                                          │
└──────────────────┬───────────────────────┘
                   │
                   ↓
┌──────────────────────────────────────────┐
│           ROUTE HANDLER                   │
│                                          │
│  (req, res) => {                         │
│    res.json([...users]);                 │
│  }                                       │
│                                          │
└──────────────────┬───────────────────────┘
                   │
                   ↓
┌──────────────────────────────────────────┐
│          RESPONSE TO CLIENT              │
│                                          │
│  Status: 200                             │
│  Body: [{ "name": "Pratham" }, ...]      │
│                                          │
└──────────────────────────────────────────┘

Express checks routes in the order they're defined and runs the first one that matches.

Handling GET Requests

GET requests are for reading data. They're what happens when you visit a URL in your browser, click a link, or call an API to fetch information.

Basic GET Routes

const express = require("express");
const app = express();

// Home page
app.get("/", (req, res) => {
  res.send("Welcome to the Home Page!");
});

// About page
app.get("/about", (req, res) => {
  res.send("This is the About Page.");
});

// API endpoint — return JSON
app.get("/api/users", (req, res) => {
  const users = [
    { id: 1, name: "Pratham", role: "developer" },
    { id: 2, name: "Arjun", role: "designer" },
    { id: 3, name: "Priya", role: "manager" },
  ];
  res.json(users);
});

app.listen(3000, () => console.log("Server on http://localhost:3000"));

Route Parameters — Dynamic URLs

What if you need /users/1, /users/2, /users/3? You can't create a separate route for each user. Use route parameters:

app.get("/users/:id", (req, res) => {
  const userId = req.params.id;
  res.json({ message: `You requested user with ID: ${userId}` });
});

// GET /users/5    → { message: "You requested user with ID: 5" }
// GET /users/42   → { message: "You requested user with ID: 42" }

:id is a placeholder. Whatever value is in that position gets stored in req.params.id.

Multiple Parameters

app.get("/users/:userId/orders/:orderId", (req, res) => {
  const { userId, orderId } = req.params;
  res.json({
    message: `Order ${orderId} for user ${userId}`,
  });
});

// GET /users/3/orders/101 → { message: "Order 101 for user 3" }

Query Parameters

Query parameters are the ?key=value pairs after the URL:

app.get("/search", (req, res) => {
  const { q, page, limit } = req.query;
  res.json({
    searchTerm: q,
    page: page || 1,
    limit: limit || 10,
  });
});

// GET /search?q=nodejs&page=2&limit=5
// → { searchTerm: "nodejs", page: "2", limit: "5" }

Handling POST Requests

POST requests are for sending data to the server — creating new resources, submitting forms, sending login credentials.

Setup: Parse Request Bodies

Express doesn't parse request bodies by default. Add this middleware:

app.use(express.json()); // Parse JSON bodies
app.use(express.urlencoded({ extended: true })); // Parse form data

Basic POST Route

const express = require("express");
const app = express();

app.use(express.json());

const users = [];

app.post("/api/users", (req, res) => {
  const { name, email } = req.body;

  if (!name || !email) {
    return res.status(400).json({ error: "Name and email are required" });
  }

  const newUser = {
    id: users.length + 1,
    name,
    email,
    createdAt: new Date().toISOString(),
  };

  users.push(newUser);
  res.status(201).json({ message: "User created!", user: newUser });
});

app.listen(3000, () => console.log("Server running"));

Testing POST Requests

You can't test POST requests in a browser address bar (that only sends GET). Use one of these:

Using curl in terminal:

curl -X POST http://localhost:3000/api/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Pratham", "email": "pratham@prathamdev.in"}'

Using the fetch API in browser console:

fetch("http://localhost:3000/api/users", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "Pratham", email: "pratham@prathamdev.in" }),
})
  .then((res) => res.json())
  .then((data) => console.log(data));

Sending Responses

Express gives you several ways to send responses back to the client:

`res.send()` — Send Any Content

app.get("/text", (req, res) => {
  res.send("Plain text response");
});

app.get("/html", (req, res) => {
  res.send("<h1>HTML response</h1><p>This is rendered by the browser.</p>");
});

`res.json()` — Send JSON (Most Common for APIs)

app.get("/api/data", (req, res) => {
  res.json({
    success: true,
    data: { name: "Pratham", role: "developer" },
  });
});

res.json() automatically sets the Content-Type header to application/json.

`res.status()` — Set Status Code

app.post("/api/users", (req, res) => {
  // 201 = Created
  res.status(201).json({ message: "User created!" });
});

app.get("/api/missing", (req, res) => {
  // 404 = Not Found
  res.status(404).json({ error: "Resource not found" });
});

app.get("/api/error", (req, res) => {
  // 500 = Server Error
  res.status(500).json({ error: "Something went wrong" });
});

Common HTTP Status Codes

Code	Meaning	When to Use
200	OK	Successful GET, PUT, PATCH
201	Created	Successful POST (new resource)
204	No Content	Successful DELETE
400	Bad Request	Invalid input from client
401	Unauthorized	Missing or invalid authentication
404	Not Found	Resource doesn't exist
500	Internal Server Error	Something broke on the server

`res.redirect()` — Redirect to Another URL

app.get("/old-page", (req, res) => {
  res.redirect("/new-page");
});

Request → Route Handler → Response Flow

Here's the complete picture of how a request flows through Express:

Client sends: POST /api/users  { "name": "Pratham" }
                    │
                    ↓
┌──────────────────────────────────────────────┐
│               EXPRESS APP                     │
│                                              │
│  1. Middleware runs first:                   │
│     express.json() → parses request body     │
│                                              │
│  2. Router matches the route:                │
│     app.post("/api/users") ← MATCH! ✅       │
│                                              │
│  3. Handler runs:                            │
│     (req, res) => {                          │
│       const { name } = req.body;             │
│       // create user...                      │
│       res.status(201).json({ user });        │
│     }                                        │
│                                              │
│  4. Response sent to client:                 │
│     Status: 201                              │
│     Body: { "user": { "name": "Pratham" } }  │
│                                              │
└──────────────────────────────────────────────┘

Putting It All Together — A Mini CRUD API

Let's build a complete example with GET, POST, and route parameters:

const express = require("express");
const app = express();

app.use(express.json());

// In-memory "database"
let todos = [
  { id: 1, title: "Learn Node.js", completed: false },
  { id: 2, title: "Build Express API", completed: false },
  { id: 3, title: "Deploy to production", completed: false },
];

// GET all todos
app.get("/api/todos", (req, res) => {
  res.json(todos);
});

// GET single todo by ID
app.get("/api/todos/:id", (req, res) => {
  const todo = todos.find((t) => t.id === parseInt(req.params.id));
  if (!todo) {
    return res.status(404).json({ error: "Todo not found" });
  }
  res.json(todo);
});

// POST — create new todo
app.post("/api/todos", (req, res) => {
  const { title } = req.body;
  if (!title) {
    return res.status(400).json({ error: "Title is required" });
  }

  const newTodo = {
    id: todos.length + 1,
    title,
    completed: false,
  };

  todos.push(newTodo);
  res.status(201).json(newTodo);
});

// PUT — update todo
app.put("/api/todos/:id", (req, res) => {
  const todo = todos.find((t) => t.id === parseInt(req.params.id));
  if (!todo) {
    return res.status(404).json({ error: "Todo not found" });
  }

  todo.title = req.body.title || todo.title;
  todo.completed = req.body.completed ?? todo.completed;
  res.json(todo);
});

// DELETE — remove todo
app.delete("/api/todos/:id", (req, res) => {
  const index = todos.findIndex((t) => t.id === parseInt(req.params.id));
  if (index === -1) {
    return res.status(404).json({ error: "Todo not found" });
  }

  todos.splice(index, 1);
  res.status(204).send();
});

app.listen(3000, () => {
  console.log("Todo API running at http://localhost:3000/api/todos");
});

A fully functional REST API with create, read, update, and delete — in under 60 lines.

Let's Practice: Hands-On Assignment

Part 1: Create a Basic Express Server

Set up a new project, install Express, and create a server with three routes:

GET / — returns "Welcome to my Express app!"
GET /about — returns "About page"
GET /api/status — returns JSON { status: "running", uptime: process.uptime() }

Part 2: Build a User API

Create these endpoints:

GET /api/users — returns all users
GET /api/users/:id — returns a single user by ID (or 404)
POST /api/users — creates a new user from req.body (validate name and email)

Part 3: Add Search Functionality

Add a route that accepts query parameters:

// GET /api/users/search?name=Pratham&role=developer
app.get("/api/users/search", (req, res) => {
  const { name, role } = req.query;
  // Filter users based on query parameters
  // Return matching users
});

Key Takeaways

Express.js is a minimal web framework that simplifies Node.js development — routing, request parsing, and response handling become clean and readable.
Routing maps URL paths + HTTP methods to handler functions: app.get("/path", handler).
GET requests read data. Use req.params for URL parameters (:id) and req.query for query strings (?key=value).
POST requests send data. Use express.json() middleware to parse request bodies, then access data via req.body.
Response methods — res.json() for APIs, res.send() for text/HTML, res.status() for HTTP codes, res.redirect() for redirections.

Wrapping Up

Express takes the raw power of Node.js and wraps it in a developer-friendly API. The same server that took 27 lines with raw http takes 18 lines with Express — and it's more readable, more maintainable, and more extensible. That's why Express is the default starting point for nearly every Node.js backend project.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. Express was the moment backend development went from "I can do this" to "I actually enjoy doing this." Routes, request handling, JSON APIs — it all feels natural with Express.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way as the backend journey continues.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Setting Up Your First Node.js Application Step-by-Step

Pratham — Sun, 10 May 2026 12:27:27 +0000

From zero to "Hello World" server — no frameworks, no magic, just pure Node.js.

There's a special kind of excitement the first time you run node app.js and see your own server respond in the browser. No HTML file opened locally. No browser extension. An actual server, running on your machine, responding to HTTP requests — and you built it.

That moment happened for me early in the ChaiCode Web Dev Cohort 2026, and it's when Node.js stopped being a concept and became something real. The entire setup takes about 10 minutes, and by the end of this article, you'll have a working Node.js application running on your machine.

Let's go from zero to server, step by step.

Step 1: Installing Node.js

Node.js doesn't come pre-installed on most systems. You need to download and install it.

Download

Go to the official website: https://nodejs.org

You'll see two versions:

Version	What It Means	Choose This If...
LTS	Long Term Support — stable, tested	✅ You're learning or building
Current	Latest features, may have bugs	Experimenting with new APIs

Pick LTS. It's the safe, reliable choice. The installer works on Windows, macOS, and Linux.

Installation

Windows/macOS: Download the installer, run it, click "Next" a few times. Done.
Linux (Ubuntu/Debian):

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs

When you install Node.js, you also get npm (Node Package Manager) automatically — it's how you install packages later.

Step 2: Checking Installation Using Terminal

Open your terminal (Command Prompt on Windows, Terminal on macOS/Linux) and run these commands:

Check Node.js Version

node -v

Output (something like):

v20.12.2

Check npm Version

npm -v

Output (something like):

10.5.0

If both commands show version numbers, you're good to go. Node.js is installed and ready.

What If It Says "Command Not Found"?

Restart your terminal — the installer may need a fresh terminal session
Restart your computer — some systems need a reboot to update the PATH
Re-run the installer and make sure "Add to PATH" is checked

Step 3: Understanding the Node REPL

Before creating files, let's meet the REPL — an interactive playground where you can type JavaScript and see results instantly.

What Is REPL?

REPL stands for:

R — Read      (reads your input)
E — Evaluate  (runs your code)
P — Print     (shows the result)
L — Loop      (waits for more input)

It's like a JavaScript calculator that runs in your terminal. You type code, press Enter, and see the output immediately. No file creation needed.

Starting the REPL

node

That's it. Just type node with no arguments. You'll see a > prompt:

Welcome to Node.js v20.12.2.
Type ".help" for more information.
>

Try Some Code

> 2 + 2
4

> "Hello" + " " + "World"
'Hello World'

> Math.random()
0.7234567891234

> const name = "Pratham"
undefined

> `Welcome, ${name}!`
'Welcome, Pratham!'

> [1, 2, 3].map(n => n * 10)
[ 10, 20, 30 ]

Node.js-Specific Things in REPL

> process.version
'v20.12.2'

> process.platform
'win32'   (or 'darwin' for macOS, 'linux' for Linux)

> __dirname
// (works in files, not REPL — we'll see this soon)

Exiting the REPL

> .exit

Or press Ctrl + C twice, or Ctrl + D once.

REPL Cheat Sheet

Command	What It Does
`.help`	Shows all REPL commands
`.exit`	Exits the REPL
`.break`	Exits a multi-line expression
`.clear`	Resets the REPL context
`Ctrl + C`	Cancel current input / exit
`↑` arrow key	Cycle through command history

The REPL is great for quick experiments and testing small snippets. But for real code, you'll write files.

Step 4: Creating Your First JS File

Time to write real code in a file.

Create a Project Folder

mkdir my-first-node-app
cd my-first-node-app

Create Your First File

Create a file called app.js in your favorite code editor (VS Code, for example) and write:

// app.js

const name = "Pratham";
const course = "Web Dev Cohort 2026";

console.log(`Hello! I'm ${name}.`);
console.log(`I'm learning Node.js in the ${course}.`);
console.log(`Running on Node.js ${process.version}`);
console.log(`Platform: ${process.platform}`);
console.log(`Current directory: ${process.cwd()}`);

This is a regular JavaScript file — the same syntax you'd write for the browser. The difference is that it uses process, which is a Node.js global object (not available in browsers).

Step 5: Running a Script Using the `node` Command

Run Your File

node app.js

Output:

Hello! I'm Pratham.
I'm learning Node.js in the Web Dev Cohort 2026.
Running on Node.js v20.12.2
Platform: win32
Current directory: C:\Users\pratham\my-first-node-app

That's it. Your JavaScript file ran outside the browser, powered by Node.js.

Script → Runtime → Output Flow

┌──────────────────┐
│    app.js         │  ← Your JavaScript file
│                  │
│  console.log()   │
│  process.version │
│  etc.            │
└────────┬─────────┘
         │
         │  node app.js  (you run this command)
         ↓
┌──────────────────┐
│   Node.js        │  ← The runtime
│   (V8 Engine)    │
│                  │
│  Reads app.js    │
│  Compiles JS     │
│  Executes code   │
└────────┬─────────┘
         │
         ↓
┌──────────────────┐
│   Terminal        │  ← Output appears here
│                  │
│  "Hello! I'm..." │
│  "Running on..." │
│  "Platform: ..." │
└──────────────────┘

What Node.js Globals Are Available?

In the browser, you have window, document, alert(). In Node.js, you have different globals:

Node.js Global	What It Does
`process`	Info about the current Node.js process
`__dirname`	Absolute path of the current file's directory
`__filename`	Absolute path of the current file
`console`	Same as browser — `log`, `error`, `warn`, `table`
`setTimeout`	Same as browser — schedule delayed execution
`setInterval`	Same as browser — repeat at intervals
`require()`	Import modules (built-in or npm packages)
`module`	Info about the current module
`exports`	Shortcut for `module.exports`

Try adding these to your app.js:

console.log("File:", __filename);
console.log("Directory:", __dirname);
console.log("Process ID:", process.pid);
console.log("Memory usage:", Math.round(process.memoryUsage().heapUsed / 1024 / 1024), "MB");

Step 6: Writing a Hello World Server

This is the exciting part — your first HTTP server. No Express. No frameworks. Just Node.js.

Create `server.js`

// server.js

const http = require("http");

const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("Hello, World! This is my first Node.js server. 🚀");
});

const PORT = 3000;

server.listen(PORT, () => {
  console.log(`Server is running at http://localhost:${PORT}`);
});

Run It

node server.js

Output in terminal:

Server is running at http://localhost:3000

Open Your Browser

Go to http://localhost:3000. You'll see:

Hello, World! This is my first Node.js server. 🚀

You just built a web server. With JavaScript. In 10 lines of code.

How This Works — Line by Line

// 1. Import Node's built-in HTTP module
const http = require("http");

// 2. Create a server that handles every incoming request
const server = http.createServer((req, res) => {
  // req = information about the incoming request
  // res = the response we send back

  // 3. Set the status code (200 = OK) and content type
  res.writeHead(200, { "Content-Type": "text/plain" });

  // 4. Send the response body and close the connection
  res.end("Hello, World! This is my first Node.js server. 🚀");
});

// 5. Tell the server to listen on port 3000
server.listen(3000, () => {
  console.log("Server is running at http://localhost:3000");
});

Node Execution Flow — Server

node server.js
      │
      ↓
┌────────────────────────────┐
│  Node.js loads server.js   │
│                            │
│  1. require("http")        │
│  2. createServer(handler)  │
│  3. server.listen(3000)    │
│                            │
│  Server is now LISTENING   │
│  for incoming connections  │
└────────────┬───────────────┘
             │
             │  (waiting for requests...)
             │
    Browser visits localhost:3000
             │
             ↓
┌────────────────────────────┐
│  Request arrives!          │
│                            │
│  handler(req, res) runs:   │
│  → Sets status 200         │
│  → Sends "Hello, World!"   │
│  → Connection closed       │
└────────────────────────────┘
             │
             │  (back to waiting for more requests...)
             │  Server stays running until you stop it.

Stopping the Server

Press Ctrl + C in the terminal. The server shuts down and the terminal returns to the regular prompt.

Making the Server More Interesting

Let's upgrade from plain text to something that handles different routes:

// server.js — upgraded version

const http = require("http");

const server = http.createServer((req, res) => {
  // Set response headers
  res.writeHead(200, { "Content-Type": "text/html" });

  // Simple routing based on URL
  if (req.url === "/") {
    res.end(`
      <h1>🏠 Home Page</h1>
      <p>Welcome to my first Node.js server!</p>
      <a href="/about">About</a> | <a href="/contact">Contact</a>
    `);
  } else if (req.url === "/about") {
    res.end(`
      <h1>👤 About</h1>
      <p>I'm Pratham, a Web Dev Cohort 2026 student learning Node.js.</p>
      <a href="/">Home</a>
    `);
  } else if (req.url === "/contact") {
    res.end(`
      <h1>📧 Contact</h1>
      <p>Find me on LinkedIn or at PrathamDEV.in</p>
      <a href="/">Home</a>
    `);
  } else {
    res.writeHead(404);
    res.end(`
      <h1>404 — Page Not Found</h1>
      <p>The page "${req.url}" doesn't exist.</p>
      <a href="/">Go Home</a>
    `);
  }
});

server.listen(3000, () => {
  console.log("Server running at http://localhost:3000");
});

Run it and visit:

http://localhost:3000/ — Home page
http://localhost:3000/about — About page
http://localhost:3000/contact — Contact page
http://localhost:3000/anything-else — 404 page

A multi-page web server. No framework. Just http, req.url, and res.end.

Initializing a Node.js Project with `npm init`

For real projects, you'll want a package.json file — it tracks your project's name, version, dependencies, and scripts.

npm init -y

This creates a package.json:

{
  "name": "my-first-node-app",
  "version": "1.0.0",
  "main": "app.js",
  "scripts": {
    "start": "node server.js"
  }
}

Now you can run your server with:

npm start

This is how professional Node.js projects are structured — package.json is the backbone.

Let's Practice: Hands-On Assignment

Part 1: Explore the REPL

Open the REPL (node) and try:

> process.version
> process.platform
> process.uptime()
> os = require("os")
> os.hostname()
> os.cpus().length
> os.totalmem() / 1024 / 1024 / 1024

Part 2: Create a Script That Reads System Info

// sysinfo.js
const os = require("os");

console.log("=== System Information ===");
console.log(`Hostname: ${os.hostname()}`);
console.log(`Platform: ${os.platform()}`);
console.log(`Architecture: ${os.arch()}`);
console.log(`CPUs: ${os.cpus().length} cores`);
console.log(`Total Memory: ${(os.totalmem() / 1024 / 1024 / 1024).toFixed(2)} GB`);
console.log(`Free Memory: ${(os.freemem() / 1024 / 1024 / 1024).toFixed(2)} GB`);
console.log(`Uptime: ${(os.uptime() / 3600).toFixed(1)} hours`);
console.log(`Node.js: ${process.version}`);

Run: node sysinfo.js

Part 3: Build a JSON API Server

// api.js
const http = require("http");

const users = [
  { id: 1, name: "Pratham", role: "developer" },
  { id: 2, name: "Arjun", role: "designer" },
  { id: 3, name: "Priya", role: "manager" },
];

const server = http.createServer((req, res) => {
  if (req.url === "/api/users") {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify(users, null, 2));
  } else {
    res.writeHead(404, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ error: "Route not found" }));
  }
});

server.listen(3000, () => {
  console.log("API running at http://localhost:3000/api/users");
});

Visit http://localhost:3000/api/users in your browser — you'll see JSON data. That's an API.

Key Takeaways

Install Node.js from nodejs.org (pick LTS). Verify with node -v and npm -v.
The REPL (node with no arguments) is an interactive playground for testing JavaScript snippets in the terminal.
Run scripts with node filename.js. Your JavaScript file is read, compiled, and executed by the V8 engine — no browser required.
http.createServer() creates a server that listens for HTTP requests and sends responses — your first real backend code.
Use npm init -y to create a package.json for tracking project metadata, scripts, and dependencies.

Wrapping Up

You've just gone from zero to running server in one article. Node.js installed, REPL explored, scripts executed, and a multi-route HTTP server built — all without a single framework. This is the raw foundation that everything else (Express, APIs, databases) is built on top of.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. This setup was the gateway to everything else — once you can run JavaScript outside the browser and create a server, the entire backend world opens up.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way as the Node.js journey continues.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Async Code in Node.js: Callbacks and Promises

Pratham — Sun, 10 May 2026 12:12:07 +0000

The two patterns that make Node.js non-blocking — and how one evolved from the other.

Every Node.js developer faces this moment: you write what looks like perfectly logical code, and the output comes in the wrong order.

const fs = require("fs");

console.log("Before reading file");
fs.readFile("data.txt", "utf8", (err, content) => {
  console.log("File content:", content);
});
console.log("After reading file");

Output:

Before reading file
After reading file
File content: Hello from data.txt!

Wait — "After reading file" printed before the file content? The file read is in the middle of the code, but its result came last?

Welcome to async Node.js. This isn't a bug. This is exactly how Node.js is designed to work — and understanding why is the key to writing effective server-side JavaScript.

Let me walk you through the two async patterns that Node.js is built on: callbacks and Promises.

Why Async Code Exists in Node.js

Node.js runs on a single thread. That one thread has to handle every incoming request, every file read, every database query. If it waited for each slow operation to finish before moving on, one user reading a large file would freeze the server for everyone.

So Node.js uses a different approach: start the operation, move on, handle the result when it arrives.

The File Reading Scenario

Let's compare what happens with sync vs async when three users hit your server:

SYNCHRONOUS (blocking):
────────────────────────────────────────────────────
User A → Read file [████████ 100ms ████████] → Response
                                                User B → Read file [████████] → Response
                                                                                 User C → ...
Each user waits for the previous one. Total: 300ms for all three.

ASYNCHRONOUS (non-blocking):
────────────────────────────────────────────────────
User A → Start read → move on
User B → Start read → move on    (all three reads happen simultaneously)
User C → Start read → move on

  ...100ms later...
  All three file reads complete → Send all three responses

Total: ~100ms for all three. Same work, 3x faster.

This is why async code exists. Node.js can't afford to wait.

Callback-Based Async Execution

A callback is a function you pass to an async operation, saying: "Run this function when you're done." It's the original async pattern in Node.js, and you'll see it everywhere in the built-in modules.

Basic File Read with Callback

const fs = require("fs");

fs.readFile("users.json", "utf8", (error, data) => {
  if (error) {
    console.log("Failed to read file:", error.message);
    return;
  }
  console.log("File data:", data);
});

Let's trace the execution step by step:

Callback Execution Flow:
────────────────────────────────────────────────────

  1. fs.readFile() is called
     → Node.js tells the OS: "Read this file"
     → Node.js registers the callback: (error, data) => { ... }
     → Node.js DOES NOT WAIT. Returns immediately.

  2. Main thread continues with the next line of code
     → Other requests can be handled
     → Other callbacks can run

  3. File read completes (OS signals Node.js)
     → Callback is placed in the task queue

  4. Event loop checks: "Is the call stack empty?"
     → YES → Move callback from queue to stack
     → Callback runs: console.log("File data:", data)

Node.js Error-First Convention

Every callback in Node.js core follows the same pattern: the first argument is always the error.

// The pattern:
someAsyncOperation((error, result) => {
  if (error) {
    // Handle error
    return;
  }
  // Use result
});

This convention is so universal in Node.js that it has a name: error-first callbacks.

// File read
fs.readFile("file.txt", "utf8", (err, data) => { /* ... */ });

// Directory read
fs.readdir("./src", (err, files) => { /* ... */ });

// File write
fs.writeFile("output.txt", content, (err) => { /* ... */ });

// File stats
fs.stat("file.txt", (err, stats) => { /* ... */ });

Always check the error first. Always.

Callback Execution Chain

When async operations depend on each other — each step needing the result of the previous step — callbacks get chained:

const fs = require("fs");

// Step 1: Read the config file
fs.readFile("config.json", "utf8", (err, configData) => {
  if (err) return console.log("Config error:", err.message);

  const config = JSON.parse(configData);
  console.log("1. Config loaded:", config.dbPath);

  // Step 2: Use config to read the database file
  fs.readFile(config.dbPath, "utf8", (err, dbData) => {
    if (err) return console.log("DB error:", err.message);

    const users = JSON.parse(dbData);
    console.log("2. Users loaded:", users.length);

    // Step 3: Write a report based on the data
    const report = `Total users: ${users.length}`;
    fs.writeFile("report.txt", report, (err) => {
      if (err) return console.log("Write error:", err.message);

      console.log("3. Report written successfully!");
    });
  });
});

Callback Chain Visualization:

  readFile("config.json")
      │
      └──→ callback fires with config data
              │
              └──→ readFile(config.dbPath)
                      │
                      └──→ callback fires with db data
                              │
                              └──→ writeFile("report.txt")
                                      │
                                      └──→ callback: "Done!"

Each step depends on the previous step's result.
Each step is indented one level deeper.

Problems with Nested Callbacks

That chain above? It's only 3 levels deep and it's already hard to follow. Now imagine 5, 6, or 7 levels. This is the infamous Callback Hell — also called the Pyramid of Doom.

A Real-World Nightmare

Imagine building an API endpoint that needs to:

Authenticate the user
Fetch their profile
Get their order history
Look up shipping details for the latest order
Send the response

authenticate(token, (err, userId) => {
  if (err) return res.status(401).json({ error: "Unauthorized" });

  getProfile(userId, (err, profile) => {
    if (err) return res.status(500).json({ error: "Profile not found" });

    getOrders(userId, (err, orders) => {
      if (err) return res.status(500).json({ error: "Orders not found" });

      getShipping(orders[0].id, (err, shipping) => {
        if (err) return res.status(500).json({ error: "Shipping not found" });

        logActivity(userId, "viewed-order", (err) => {
          if (err) console.log("Log failed:", err.message);

          res.json({
            user: profile.name,
            latestOrder: orders[0],
            shipping: shipping.address,
          });
        });
      });
    });
  });
});

Why This Is a Problem

1. READABILITY
   → Code moves RIGHT instead of DOWN
   → 5 levels of indentation — hard to scan

2. ERROR HANDLING
   → Every single level has its own if (err) check
   → Duplicated error patterns — easy to forget one

3. MAINTAINABILITY
   → Adding a step means wrapping everything in another level
   → Removing a step means restructuring the entire chain

4. DEBUGGING
   → Stack traces are confusing with deep nesting
   → Finding which level caused an error is painful

Visual — The Pyramid of Doom:

authenticate(token, (err, userId) => {
  ·getProfile(userId, (err, profile) => {
  ··getOrders(userId, (err, orders) => {
  ···getShipping(orders[0].id, (err, shipping) => {
  ····logActivity(userId, "viewed", (err) => {
  ·····res.json({ ... });  // 5 levels deep 😵
  ····});
  ···});
  ··});
  ·});
});

The code forms a pyramid shape →→→→→

This is the fundamental problem that Promises were invented to solve.

Promise-Based Async Handling

A Promise is an object that represents the eventual result of an async operation — it will either succeed with a value or fail with an error.

The Promise Lifecycle

┌──────────────────────────────────────────────┐
│                                              │
│        new Promise((resolve, reject) => {    │
│          // async work                       │
│        })                                    │
│                                              │
│                  ┌─────────┐                 │
│                  │ PENDING  │                │
│                  └────┬────┘                 │
│                       │                      │
│            ┌──────────┴──────────┐           │
│            ↓                     ↓           │
│     ┌────────────┐        ┌───────────┐      │
│     │ FULFILLED  │        │ REJECTED  │      │
│     │ resolve()  │        │ reject()  │      │
│     └─────┬──────┘        └─────┬─────┘      │
│           ↓                     ↓            │
│       .then(value)          .catch(error)    │
│                                              │
│              .finally() — runs either way    │
│                                              │
└──────────────────────────────────────────────┘

Converting Node.js Callbacks to Promises

Node.js's fs.promises API provides Promise-based versions of all file system operations:

const fs = require("fs").promises;

// Callback version
// fs.readFile("data.txt", "utf8", (err, data) => { ... });

// Promise version
fs.readFile("data.txt", "utf8")
  .then((data) => {
    console.log("File content:", data);
  })
  .catch((error) => {
    console.log("Error:", error.message);
  });

You Can Also Wrap Callbacks Manually

If a library doesn't provide Promises, you can create your own:

function readFilePromise(path) {
  return new Promise((resolve, reject) => {
    require("fs").readFile(path, "utf8", (err, data) => {
      if (err) reject(err);
      else resolve(data);
    });
  });
}

// Now it works with .then()
readFilePromise("data.txt")
  .then((data) => console.log(data))
  .catch((err) => console.log(err.message));

Node.js also provides a built-in utility for this: util.promisify():

const { promisify } = require("util");
const fs = require("fs");

const readFile = promisify(fs.readFile);

readFile("data.txt", "utf8")
  .then((data) => console.log(data))
  .catch((err) => console.log(err.message));

The Same Chain — Callbacks vs Promises

Remember the 3-step config → database → report chain? Here's how it looks with Promises:

Callback Version (nested)

fs.readFile("config.json", "utf8", (err, configData) => {
  if (err) return console.log(err);
  const config = JSON.parse(configData);

  fs.readFile(config.dbPath, "utf8", (err, dbData) => {
    if (err) return console.log(err);
    const users = JSON.parse(dbData);

    fs.writeFile("report.txt", `Users: ${users.length}`, (err) => {
      if (err) return console.log(err);
      console.log("Done!");
    });
  });
});

Promise Version (flat)

const fs = require("fs").promises;

fs.readFile("config.json", "utf8")
  .then((configData) => {
    const config = JSON.parse(configData);
    return fs.readFile(config.dbPath, "utf8");
  })
  .then((dbData) => {
    const users = JSON.parse(dbData);
    return fs.writeFile("report.txt", `Users: ${users.length}`);
  })
  .then(() => {
    console.log("Done!");
  })
  .catch((error) => {
    console.log("Something failed:", error.message);
  });

Async/Await Version (cleanest)

const fs = require("fs").promises;

async function generateReport() {
  try {
    const configData = await fs.readFile("config.json", "utf8");
    const config = JSON.parse(configData);

    const dbData = await fs.readFile(config.dbPath, "utf8");
    const users = JSON.parse(dbData);

    await fs.writeFile("report.txt", `Users: ${users.length}`);
    console.log("Done!");
  } catch (error) {
    console.log("Something failed:", error.message);
  }
}

generateReport();

Side-by-Side Comparison

CALLBACKS:                        PROMISES:
─────────                         ─────────
readFile(cb1)                     readFile()
  ·readFile(cb2)                    .then(data => readFile())
  ··writeFile(cb3)                  .then(data => writeFile())
  ···console.log("Done")           .then(() => console.log("Done"))
                                    .catch(err => ...)

Nested → RIGHT                    Flat → DOWN
Error at every level              One catch for all
Hard to add/remove steps          Easy to modify

Benefits of Promises

Benefit	Callbacks	Promises
Readability	Nested, rightward drift	Flat, top-to-bottom
Error handling	Repeated `if (err)` at every level	One `.catch()` for the entire chain
Composability	Hard to combine operations	`Promise.all()`, `Promise.race()`
Adding steps	Wrap in another nesting level	Add another `.then()`
Return values	Must use callbacks to pass data	Each `.then()` returns a new Promise
Debugging	Confusing stack traces	Clearer trace through the chain
Modern support	Legacy pattern	Built into Node.js, `fs.promises`

Concurrent Operations with `Promise.all()`

This is something callbacks can't do cleanly — running independent operations in parallel:

const fs = require("fs").promises;

async function loadAllData() {
  // All three reads start simultaneously
  const [users, products, settings] = await Promise.all([
    fs.readFile("users.json", "utf8"),
    fs.readFile("products.json", "utf8"),
    fs.readFile("settings.json", "utf8"),
  ]);

  console.log("Users:", JSON.parse(users).length);
  console.log("Products:", JSON.parse(products).length);
  console.log("Settings loaded:", JSON.parse(settings).theme);
}

loadAllData();

With callbacks, you'd need manual counters to track when all three are done. With Promise.all(), it's one line.

The 5-Level API — Rewritten with Promises

Remember the 5-level callback nightmare? Here it is, flattened:

// Callback Hell version — 5 levels of nesting
authenticate(token, (err, userId) => {
  getProfile(userId, (err, profile) => {
    getOrders(userId, (err, orders) => {
      getShipping(orders[0].id, (err, shipping) => {
        logActivity(userId, "viewed-order", (err) => {
          res.json({ user: profile.name, shipping: shipping.address });
        });
      });
    });
  });
});

// Promise version — completely flat
async function handleRequest(token, res) {
  try {
    const userId = await authenticate(token);
    const profile = await getProfile(userId);
    const orders = await getOrders(userId);
    const shipping = await getShipping(orders[0].id);
    await logActivity(userId, "viewed-order");

    res.json({
      user: profile.name,
      latestOrder: orders[0],
      shipping: shipping.address,
    });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
}

Five levels of nesting → zero. Five error checks → one. Same logic, dramatically better code.

Let's Practice: Hands-On Assignment

Part 1: Callback-Based File Operations

const fs = require("fs");

// Write a file, then read it back
fs.writeFile("greeting.txt", "Hello from Node.js!", (err) => {
  if (err) return console.log("Write error:", err.message);
  console.log("File written!");

  fs.readFile("greeting.txt", "utf8", (err, data) => {
    if (err) return console.log("Read error:", err.message);
    console.log("File says:", data);
  });
});

Part 2: Convert to Promises

const fs = require("fs").promises;

async function greetingFile() {
  try {
    await fs.writeFile("greeting.txt", "Hello from Promises!");
    console.log("File written!");

    const data = await fs.readFile("greeting.txt", "utf8");
    console.log("File says:", data);
  } catch (error) {
    console.log("Error:", error.message);
  }
}

greetingFile();

Part 3: Concurrent Reads with Promise.all()

const fs = require("fs").promises;

async function setup() {
  // Create test files
  await fs.writeFile("file1.txt", "Data from file 1");
  await fs.writeFile("file2.txt", "Data from file 2");
  await fs.writeFile("file3.txt", "Data from file 3");

  // Read all three concurrently
  console.time("Concurrent read");
  const [f1, f2, f3] = await Promise.all([
    fs.readFile("file1.txt", "utf8"),
    fs.readFile("file2.txt", "utf8"),
    fs.readFile("file3.txt", "utf8"),
  ]);
  console.timeEnd("Concurrent read");

  console.log(f1, "|", f2, "|", f3);
}

setup();

Key Takeaways

Async code exists in Node.js because the single thread can't afford to wait. Starting operations and handling results later keeps the server responsive.
Callbacks are the original async pattern: pass a function, it gets called when the operation finishes. Node.js uses error-first callbacks (err as the first argument).
Nested callbacks create the Pyramid of Doom — deep indentation, repeated error handling, and unmaintainable code.
Promises flatten the nesting with .then() chains. Async/await makes it even cleaner with synchronous-looking syntax.
Promises add real capabilities callbacks lack: Promise.all() for concurrent operations, one .catch() for all errors, and composable chains that are easy to modify.

Wrapping Up

Callbacks and Promises aren't competing patterns — they're an evolution. Callbacks came first and they work. But as applications grew more complex and async chains got deeper, the need for something more readable and maintainable became clear. Promises — and the async/await sugar on top — were the answer.

In Node.js, you'll encounter both patterns daily. Legacy code and some npm packages still use callbacks. Modern Node.js APIs (like fs.promises) and new codebases use Promises and async/await. Understanding both means you can work with any codebase.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. Seeing the callback → Promise → async/await evolution play out with real Node.js file operations made the patterns tangible in a way that abstract examples never could.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

Blocking vs Non-Blocking Code in Node.js Blocking vs Non-Blocking Code in Node.js

Pratham — Sun, 10 May 2026 12:08:27 +0000

The difference between a server that freezes under load and one that handles thousands of users effortlessly.

Let me show you two versions of the same server. Both read a file and send it to the client. Both produce the correct result. But one can handle 10,000 users and the other chokes at 50.

// Version A — blocking
const data = fs.readFileSync("large-file.txt", "utf8");
res.send(data);

// Version B — non-blocking
fs.readFile("large-file.txt", "utf8", (err, data) => {
  res.send(data);
});

The only difference? readFileSync vs readFile. One letter — Sync — and your server's ability to handle concurrent users goes from thousands to barely any.

Understanding why this matters is one of the most important things I've learned about Node.js in the ChaiCode Web Dev Cohort 2026. Let me break it down.

What Does Blocking Code Mean?

Blocking code means the program stops and waits for an operation to finish before moving to the next line. Nothing else can run during the wait.

The Waiting Analogy

Imagine you're at a coffee shop. You order a latte. In the blocking model, you stand at the counter, staring at the barista, doing absolutely nothing until your coffee is in your hand. The person behind you? They can't even order. They wait until you walk away.

YOU → Order → STAND AND WAIT → Get coffee → Leave
                    ↑
              3 minutes of doing NOTHING
              Next person CAN'T ORDER until you're done

Blocking in Node.js

const fs = require("fs");

console.log("1. Starting...");

// BLOCKING — Node.js STOPS here until the file is fully read
const data = fs.readFileSync("bigfile.txt", "utf8");

console.log("2. File read complete. Size:", data.length);
console.log("3. Now I can continue...");

Output:

1. Starting...
(... frozen for however long the file read takes ...)
2. File read complete. Size: 1048576
3. Now I can continue...

Between line 1 and line 2, the entire Node.js process is frozen. No other code runs. No other requests are processed. No events are handled. The single thread is stuck waiting for the hard drive.

Blocking Execution Timeline

Main Thread:
────────────────────────────────────────────────────

  0ms                                          200ms
  │                                             │
  ▼                                             ▼
  [log "Starting"]  [██████ BLOCKED ██████]  [log "File read"]  [log "Continue"]
                     ↑                   ↑
                     File read starts     File read ends

  NOTHING else can run during this entire block.
  If 100 requests arrive during these 200ms, they ALL wait.

What Does Non-Blocking Code Mean?

Non-blocking code means the program starts an operation, moves on immediately, and handles the result later when it's ready. The thread stays free for other work.

The Continuing Analogy

Same coffee shop, but this time: you order your latte, the barista gives you a buzzer, and you go sit down, check your phone, chat with a friend. When the buzzer goes off, you pick up your coffee. Meanwhile, the person behind you ordered right after you — no waiting.

YOU → Order → Get buzzer → SIT DOWN (do other things)
                              ↓
                         Buzzer goes off!
                              ↓
                         Pick up coffee

NEXT PERSON → Order → Get buzzer → sit down (immediately)

Non-Blocking in Node.js

const fs = require("fs");

console.log("1. Starting...");

// NON-BLOCKING — Node.js starts the read and MOVES ON immediately
fs.readFile("bigfile.txt", "utf8", (err, data) => {
  console.log("3. File read complete. Size:", data.length);
});

console.log("2. Not waiting — doing other work!");

Output:

1. Starting...
2. Not waiting — doing other work!
3. File read complete. Size: 1048576

Notice the order: 1, 2, 3 — not 1, 3, 2. Line 2 runs immediately after the file read is started. Node.js didn't wait. When the file is ready, the callback fires and handles the result.

Non-Blocking Execution Timeline

Main Thread:
────────────────────────────────────────────────────

  0ms    1ms                                  200ms
  │      │                                     │
  ▼      ▼                                     ▼
  [log]  [log "Not waiting"]  ...FREE...  [callback: "File read complete"]

  Background:
  [████████████████ File being read ████████████████]
  0ms                                           200ms

  Main thread was FREE from 1ms to 200ms.
  It could handle hundreds of other requests during that time!

Why Blocking Slows Servers

This is where the difference becomes critical. In a standalone script, blocking is annoying but survivable. In a server, blocking is catastrophic.

Scenario: 3 Users Request a File

Blocking Server

const http = require("http");
const fs = require("fs");

const server = http.createServer((req, res) => {
  // BLOCKING — each request freezes the server
  const data = fs.readFileSync("page.html", "utf8");
  res.end(data);
});

server.listen(3000);

User A requests → Server reads file (BLOCKS 100ms) → Response sent
                  (Users B and C are WAITING)

User B requests → Server reads file (BLOCKS 100ms) → Response sent
                  (User C is still WAITING)

User C requests → Server reads file (BLOCKS 100ms) → Response sent

Timeline:
─────────────────────────────────────────────────────────
  0ms        100ms       200ms       300ms
  │           │           │           │
  User A ████████████                           → response at 100ms
              User B ████████████                → response at 200ms
                          User C ████████████    → response at 300ms

Total: User C waited 300ms for a 100ms operation.
       Each user's wait = their position × file read time.

Non-Blocking Server

const http = require("http");
const fs = require("fs");

const server = http.createServer((req, res) => {
  // NON-BLOCKING — server stays free between reads
  fs.readFile("page.html", "utf8", (err, data) => {
    res.end(data);
  });
});

server.listen(3000);

User A requests → Start file read → move on
User B requests → Start file read → move on
User C requests → Start file read → move on

  ...all three file reads happen concurrently...

File A ready → Send response to User A
File B ready → Send response to User B
File C ready → Send response to User C

Timeline:
─────────────────────────────────────────────────────────
  0ms  1ms  2ms                                    ~100ms
  │    │    │                                        │
  A    B    C                                      A✓ B✓ C✓
  start all three                              all respond ~100ms

Total: ALL users got responses in ~100ms.
       No one waited for anyone else.

The Impact at Scale

Concurrent Users	Blocking Server	Non-Blocking Server
1	100ms	100ms
10	1,000ms (last user)	~100ms (all users)
100	10,000ms = 10 seconds 💀	~100ms (all users)
1,000	100 seconds 💀💀	~100ms (all users)

The blocking server gets linearly slower with each user. The non-blocking server stays consistently fast.

Async Operations in Node.js

Node.js provides non-blocking versions of most operations. Here are the most common patterns:

File System — Blocking vs Non-Blocking

const fs = require("fs");

// ❌ BLOCKING
const data = fs.readFileSync("config.json", "utf8");
const stats = fs.statSync("config.json");
fs.writeFileSync("output.txt", "Hello");
fs.mkdirSync("new-folder");

// ✅ NON-BLOCKING (callback)
fs.readFile("config.json", "utf8", (err, data) => { /* ... */ });
fs.stat("config.json", (err, stats) => { /* ... */ });
fs.writeFile("output.txt", "Hello", (err) => { /* ... */ });
fs.mkdir("new-folder", (err) => { /* ... */ });

// ✅ NON-BLOCKING (promises — modern)
const fsPromises = require("fs").promises;
const data2 = await fsPromises.readFile("config.json", "utf8");
const stats2 = await fsPromises.stat("config.json");
await fsPromises.writeFile("output.txt", "Hello");
await fsPromises.mkdir("new-folder");

The Pattern

Every blocking fs method ends with Sync. The non-blocking versions either:

Accept a callback as the last argument
Return a Promise via fs.promises

Blocking:     fs.readFileSync()    — returns data directly, blocks thread
Non-blocking: fs.readFile()        — returns immediately, data comes in callback
Promise:      fs.promises.readFile() — returns Promise, use with await

Database Calls — Always Non-Blocking

Database drivers in Node.js are inherently non-blocking:

// MongoDB — non-blocking
const user = await db.collection("users").findOne({ name: "Pratham" });

// PostgreSQL — non-blocking
const result = await pool.query("SELECT * FROM users WHERE id = $1", [1]);

// These use await, but they DON'T block the thread.
// Other requests continue being processed while the DB query runs.

HTTP Requests — Always Non-Blocking

// fetch — non-blocking
const response = await fetch("https://api.example.com/data");
const data = await response.json();

// The thread is FREE while waiting for the API response.

Timers — Non-Blocking by Design

// setTimeout — non-blocking
setTimeout(() => {
  console.log("This runs later");
}, 2000);
console.log("This runs NOW");

// Output: "This runs NOW" → (2 seconds) → "This runs later"

Real-World Example: API Server

Let's build a realistic example that shows blocking vs non-blocking in a server handling multiple operations:

Blocking Version — Everything Sequential

const http = require("http");
const fs = require("fs");

const server = http.createServer((req, res) => {
  // Step 1: Read user data (BLOCKS 50ms)
  const userData = fs.readFileSync("users.json", "utf8");
  const users = JSON.parse(userData);

  // Step 2: Read config (BLOCKS 30ms)
  const configData = fs.readFileSync("config.json", "utf8");
  const config = JSON.parse(configData);

  // Step 3: Read template (BLOCKS 20ms)
  const template = fs.readFileSync("template.html", "utf8");

  // Total: 100ms BLOCKED per request
  res.end(template.replace("{{users}}", JSON.stringify(users)));
});

server.listen(3000);

Per-request timeline:
[██ users 50ms ██][██ config 30ms ██][██ template 20ms ██] → Response

Total: 100ms blocked. Thread frozen the entire time.
10 concurrent requests = 1 second for the last user.

Non-Blocking Version — Everything Concurrent

const http = require("http");
const fs = require("fs").promises;

const server = http.createServer(async (req, res) => {
  try {
    // All three reads start at the SAME TIME
    const [userData, configData, template] = await Promise.all([
      fs.readFile("users.json", "utf8"),
      fs.readFile("config.json", "utf8"),
      fs.readFile("template.html", "utf8"),
    ]);

    const users = JSON.parse(userData);
    const config = JSON.parse(configData);

    res.end(template.replace("{{users}}", JSON.stringify(users)));
  } catch (error) {
    res.writeHead(500);
    res.end("Server error");
  }
});

server.listen(3000);

Per-request timeline:
[██ users 50ms ████████████████████]
[██ config 30ms ██████████]          ← all three run concurrently
[██ template 20ms ████]
                                     → Response at ~50ms (slowest read)

Total: ~50ms instead of 100ms. Thread free during I/O.
10 concurrent requests ≈ still ~50ms for everyone.

By using Promise.all(), all three file reads happen concurrently. The total time is the slowest operation (50ms), not the sum of all operations (100ms).

When Is Blocking Code Acceptable?

Blocking isn't always bad. There are specific situations where it's fine:

✅ OK to Block

// 1. Application startup — before the server starts listening
const config = fs.readFileSync("config.json", "utf8");
const settings = JSON.parse(config);
// No users are waiting yet — blocking is fine here.

app.listen(3000); // NOW the server starts accepting requests

// 2. CLI scripts that run once and exit
const data = fs.readFileSync(process.argv[2], "utf8");
console.log(data.length, "characters");
// Single-user, single-run — no concurrency needed

❌ Never Block

// Inside request handlers — NEVER use Sync methods
app.get("/data", (req, res) => {
  const data = fs.readFileSync("data.json", "utf8"); // ❌ BLOCKS ALL USERS
  res.json(JSON.parse(data));
});

// Inside event handlers
socket.on("message", (msg) => {
  const log = fs.readFileSync("log.txt", "utf8"); // ❌ BLOCKS EVENT LOOP
  // ...
});

The Simple Rule

During startup → Blocking is fine (no users yet)
During runtime → NEVER block (users are waiting)

Let's Practice: Hands-On Assignment

Part 1: Measure the Difference

const fs = require("fs");

// Create a test file first
fs.writeFileSync("testfile.txt", "x".repeat(10_000_000));

// BLOCKING
console.time("Blocking");
for (let i = 0; i < 5; i++) {
  fs.readFileSync("testfile.txt", "utf8");
}
console.timeEnd("Blocking");

// NON-BLOCKING
console.time("Non-blocking");
let completed = 0;
for (let i = 0; i < 5; i++) {
  fs.readFile("testfile.txt", "utf8", () => {
    completed++;
    if (completed === 5) console.timeEnd("Non-blocking");
  });
}

Run this and compare the times. Non-blocking will be faster because the reads happen concurrently.

Part 2: See Server Impact

const http = require("http");
const fs = require("fs");

// Create a large file
fs.writeFileSync("large.txt", "data\n".repeat(1_000_000));

const server = http.createServer((req, res) => {
  if (req.url === "/blocking") {
    const data = fs.readFileSync("large.txt", "utf8");
    res.end(`Blocking: ${data.length} chars\n`);
  }

  if (req.url === "/non-blocking") {
    fs.readFile("large.txt", "utf8", (err, data) => {
      res.end(`Non-blocking: ${data.length} chars\n`);
    });
  }
});

server.listen(3000, () => {
  console.log("Test: open /blocking in one tab, then /non-blocking quickly");
  console.log("Notice how /blocking makes /non-blocking wait!");
});

Part 3: Convert Blocking to Non-Blocking

Take this blocking code and convert it:

// ❌ Blocking version
const users = JSON.parse(fs.readFileSync("users.json", "utf8"));
const posts = JSON.parse(fs.readFileSync("posts.json", "utf8"));
console.log(`${users.length} users, ${posts.length} posts`);

// ✅ Your task: rewrite using async/await and Promise.all()
// Hint: use fs.promises.readFile

Key Takeaways

Blocking code stops the thread and waits for the operation to finish. Nothing else can run during the wait — including handling other user requests.
Non-blocking code starts the operation, moves on immediately, and handles the result via callbacks, Promises, or async/await when it's ready.
In a server context, blocking is catastrophic — one slow operation freezes every user. Non-blocking lets the server handle thousands of concurrent requests by staying free during I/O.
Every Sync method in Node.js is blocking. Use the callback or Promise version inside request handlers. Only use Sync during application startup.
Use Promise.all() for independent operations that can run concurrently — the total time is the slowest operation, not the sum of all.

Wrapping Up

The difference between blocking and non-blocking is the difference between a server that handles 50 users and one that handles 50,000. It's not about writing different logic — it's about choosing the right version of the same operation. readFileSync vs readFile. Waiting vs continuing. Frozen vs free.

I'm learning all of this through the ChaiCode Web Dev Cohort 2026 under Hitesh Chaudhary and Piyush Garg. Once you internalize this pattern — start operation, move on, handle result later — you'll write non-blocking code naturally. And your servers will thank you.

Connect with me on LinkedIn or visit PrathamDEV.in. More articles on the way as the backend journey continues.

Happy coding! 🚀

Written by Pratham Bhardwaj | Web Dev Cohort 2026, ChaiCode

DEV Community: Pratham

Linux File System Hunting: What I Found When I Stopped Running Commands and Started Reading the OS

Finding 1: /etc/hostname — Your Machine's Identity in One Line

Finding 2: /etc/hosts — The Original Internet Directory

Finding 3: /etc/resolv.conf — Where Your DNS Requests Actually Go

Finding 4: /etc/nsswitch.conf — The Decision Engine for Name Resolution

Finding 5: /proc/net/route — Your Machine's Routing Table as a File

Finding 6: /proc/[pid]/ — Every Process Exposes Itself as a Folder

Finding 7: /etc/passwd and /etc/shadow — The Split Permission Model

Finding 8: /etc/systemd/system/ — Every Service is a File

Finding 9: /var/log/ — The Server's Diary

Finding 10: /proc/net/tcp — Open Sockets as a File

The Pattern Behind Everything

Wrapping Up

Storing Uploaded Files and Serving Them in Express

Where Are Uploaded Files Stored?

Local Storage (The Default)

External Storage (Cloud)

The Upload Storage Folder Structure

Multer Storage Configuration

Serving Static Files in Express

The express.static Middleware

Virtual Path Prefix (The Better Way)

Static File Serving Flow

Accessing Uploaded Files via URL

Saving the Path to the Database

Displaying on the Frontend

Security Considerations for Uploads

1. Never Trust the Extension

2. Never Trust the Filename

3. Limit File Size

4. Prevent Execution

Let's Practice: Hands-On Assignment

Part 1: Build the Storage Architecture

Part 2: Serve the Files

Part 3: Secure the Endpoint

Key Takeaways

Wrapping Up

Handling File Uploads in Express with Multer

Why File Uploads Need Middleware

What Is Multer?

Install

What Multer Does

Handling Single File Upload

Basic Setup

Key Points

The req.file Object

Testing with curl

Testing with an HTML Form

Client → Server → Storage Upload Flow

Handling Multiple File Uploads

Multiple Files — Same Field

Multiple Files — Different Fields

HTML Form for Multiple Files

Upload Methods Summary

Storage Configuration

Custom Storage

Adding File Validation

Handling Upload Errors

Serving Uploaded Files

Complete Upload + Serve Example

Multer Middleware Execution Flow

Let's Practice: Hands-On Assignment

Part 1: Single File Upload

Part 2: Multiple File Upload

Part 3: Add Validation

Part 4: Serve and Display

Key Takeaways

Wrapping Up

JWT Authentication in Node.js Explained Simply

What Does Authentication Mean?

What Is JWT?

Why "Self-Contained"?

Structure of a JWT

Part 1: Header

Part 2: Payload

Part 3: Signature

Login Flow Using JWT

JWT Login Authentication Flow

Step-by-Step Implementation

Finding 1: `/etc/hostname` — Your Machine's Identity in One Line

Finding 2: `/etc/hosts` — The Original Internet Directory

Finding 3: `/etc/resolv.conf` — Where Your DNS Requests Actually Go

Finding 4: `/etc/nsswitch.conf` — The Decision Engine for Name Resolution

Finding 5: `/proc/net/route` — Your Machine's Routing Table as a File

Finding 6: `/proc/[pid]/` — Every Process Exposes Itself as a Folder

Finding 7: `/etc/passwd` and `/etc/shadow` — The Split Permission Model

Finding 8: `/etc/systemd/system/` — Every Service is a File

Finding 9: `/var/log/` — The Server's Diary

Finding 10: `/proc/net/tcp` — Open Sockets as a File

The `express.static` Middleware

The `req.file` Object