Every Linux user knows /proc. But almost nobody knows what it actually is. It's not a filesystem. There are no files on any disk. Everything inside it is generated on the fly by the kernel the moment you read it. It's theater a stage where the kernel performs its internal state for you, formatted as files.

This matters because it means reading /proc/meminfo is not like reading a log file. It is the act of asking the kernel a live question. The answer is constructed at the exact moment your cat command touches the file descriptor.

Imagine you walk into a library. You see thousands of books on the shelves. Normally, you’d pick one up, and the words inside would be printed in ink, unchanging since the day the book was made. That is a Standard Filesystem (like your hard drive).

But Linux has a ghost library called /proc. When you open a book in /proc, the pages are blank until your eyes touch the paper. The moment you look, a librarian (the Kernel) sprints behind the page and scribbles down exactly what is happening in the building at that microsecond. When you close the book, the ink vanishes.

Notice the sizes: every file is 0 bytes. That's the tell. Real files have sizes. These are kernel function pointers dressed as files. /proc/self is particularly mind-bending it's a symlink that points to the PID of whoever reads it. Every process that reads /proc/self sees itself. It's a mirror.

Your Process Is a Directory

Every running process gets its own directory in /proc/[PID]/. Inside that directory is a complete portrait of the process its open files, its memory map, its environment variables, its current working directory, what executable it is. This is not metadata. This is the process, seen from the outside.

What we found in PID 1

PID 1 is the init process the ancestor of all other processes. In a traditional Linux system, this is systemd or init. Here, it revealed something different:

Command

• /proc/1/: This is the directory for the Init process, the mother of all processes. It is the first thing the kernel starts after booting.

• cmdline: This "file" contains the exact command used to start that process.

• tr '\0' ' ': Kernel files in /proc often use "null bytes" (\0) to separate arguments. This part of your command simply replaces those invisible separators with spaces so you can read them.

The output /usr/lib/systemd/systemd tells us that our system is managed by systemd.

In the illusion of the filesystem, this file exists to tell you exactly how the system was brought to life. The --deserialize=79 flag is a piece of internal state a memory systemd kept of its previous self if it was re-executed without a full reboot.

Network Knobs Hidden in /proc/sys/net

Sysadmins tune Linux networking by writing numbers to files. Security hardening, performance tuning, DDoS mitigation all of it lives in /proc/sys/net/ipv4/ and friends. Most documentation tells you what to set. Almost none explains what you can read to understand the system's current posture.

Everything is a File in Linux

You're running a Node.js or Python server and under load it crashes with EMFILE: too many open files. This is one of the most common errors developers hit and one of the least understood. Here's the full picture.

Every open file, socket, pipe, or database connection consumes a file descriptor (FD). Linux enforces limits on how many a process can hold at once. There are two limits stacked on top of each other:

The default soft limit of 1,024. A modern web server handling 500 concurrent connections is already using half its budget just for sockets, before counting open config files, logs, and library handles.

Address Already in Use

You start your dev server and get EADDRINUSE: address already in use :::3000. Something is already listening on that port. Here's how to find and handle it.

Sometimes there's no process on the port but you still can't bind. This happens because the port is in TIME_WAIT state the kernel is holding it for 60 seconds after a recent connection closed, to ensure stale packets don't confuse a new connection.

Zombie Processes

A zombie process is not a running process. It's a dead process whose exit code hasn't been collected yet. The kernel keeps a tiny tombstone entry in the process table until the parent calls wait() to read the exit status. Until then: zombie.

/etc/hosts

/etc/hosts is checked before DNS. This is defined in /etc/nsswitch.conf as hosts: files dns "files" (hosts) first, "dns" second. This makes /etc/hosts an instant, zero-latency DNS override with no servers involved.

Quick Reference Cheatsheet

Imagine you walk into a private club. The bouncer doesn't just let you in because you look nice you need a membership card. In the digital world, Authentication is that process it’s how a server verifies that you are who you say you are.

Without it, anyone could edit your profile, delete your data, or post on your behalf. We need a way to prove identity once, then stay "logged in" without having to type a password for every single button click.

What is a JWT (JSON Web Token)?

In the old days, servers kept a list of every logged-in user in their memory (Sessions). It was like a bouncer memorizing every face in the club. But if the club gets too big, the bouncer’s head explodes.

JWT (JSON Web Token) is the modern, "stateless" solution. Instead of the server remembering you, it gives you a digital, tamper-proof ID card. You carry it, you show it, and the server just checks if the signature is valid. It doesn't need to check a database every single time.

The Secret Handshake: Why Your App Needs Authentication

Imagine you walk into a private club. The bouncer doesn't just let you in because you look nice; you need a membership card. In the digital world, Authentication is that process—it’s how a server verifies that you are who you say you are.

Without it, anyone could edit your profile, delete your data, or post on your behalf. We need a way to prove identity once, then stay "logged in" without having to type a password for every single button click.

What is a JWT (JSON Web Token)?

In the old days, servers kept a list of every logged-in user in their memory (Sessions). It was like a bouncer memorizing every face in the club. But if the club gets too big, the bouncer’s head explodes.

JWT (JSON Web Token) is the modern, "stateless" solution. Instead of the server remembering you, it gives you a digital, tamper-proof ID card. You carry it, you show it, and the server just checks if the signature is valid. It doesn't need to check a database every single time.

The Anatomy of a JWT

A JWT looks like a long, messy string of gibberish separated by two dots. It has three distinct parts:

1. Header: Tells the server what kind of token this is and which hashing algorithm was used (usually HS256).

2. Payload: The important part of the token. It contains user data like userId or username.
   Don’t put passwords or secrets here; anyone can decode this part easily!

3. Signature: This is the secret sauce. The server takes the Header and Payload, mixes them with a Secret Key known only to the server, and creates a unique hash. If even one character in the payload changes, the signature won't match anymore.

JWT Lifecycle

The Login Flow

When a user logs in, the magic happens in these steps:

1. Request: The user sends their username and password to the server.

2. Validation: The server checks the database. If the credentials are correct, the server creates a JWT using its private SECRET_KEY.

3. Delivery: The server sends that JWT back to the browser.

Sending the Token

Once the browser has the token, it doesn't just sit there.

1. For every "protected" request (like fetching your private messages), the browser sends the token in the Authorization Header: Authorization: Bearer <your_token_here>

2. Protecting Routes On the Node.js side, we use Middleware to protect specific routes.

3. The server intercepts the request.

4. It grabs the token from the header.

5. It verifies the signature using the SECRET_KEY.

6. If valid: The request proceeds to the controller.

7. If invalid: The server sends back a "401 Unauthorized" error.

Things as dev we should know

• JWTs are not "Encrypted": They are Encoded. Anyone can paste a JWT into jwt.io and read your payload. Never put sensitive data like credit card numbers or passwords inside a JWT.

• The "Stateless" Trap: Since the server doesn't "track" the token, you can't easily revoke it. If a user’s token is stolen, they are logged in until it expires. This is why Expiration Times (exp) are mandatory.

• Local Storage vs. Cookies: Storing tokens in localStorage makes you vulnerable to XSS (Cross-Site Scripting). For better security, many pros use HttpOnly Cookies, which JavaScript cannot touch.

• Secret Key Safety: If your SECRET_KEY leaks, your entire security system is compromised. Use environment variables and never, ever hardcode it into your GitHub repo.

Where Uploaded Files Actually Live

When Multer processes a file, it writes it to a location on your server's filesystem. Exactly where depends on how you configured your storage. With the simple dest option, all files go into one flat folder. With diskStorage, you control every part of the path.

By default, that folder is relative to wherever your node process is started usually the project root. So dest: 'uploads/' means the files end up at your-project/uploads/. They live on disk like any other files, readable by any process with access to that directory.

Use subfolders within uploads/ to separate different file types — avatars, documents, product images. It keeps the directory manageable and makes it easier to apply different policies (expiry, access control) per category.

Local Storage vs. External Storage

When you first build file upload functionality, storing files on the same server your application runs on local disk storage is the natural choice. It's simple, fast, and requires no third-party services. For development and low-traffic applications, it works perfectly well.

At scale, though, local disk has a few fundamental problems: disk space is finite, files don't survive server replacements or container restarts, and if you run multiple instances of your server behind a load balancer, only the instance that received the upload has the file. External storage services like S3, Cloudinary, or Google Cloud Storage exists to solve these problems.

This article focuses on local disk — the right place to start. External storage integrations (AWS S3, etc.) follow the same conceptual model but involve additional SDK configuration. Once you understand local storage, the leap to cloud storage is mostly configuration, not new concepts.

Serving Static Files in Express

Express ships with a built-in middleware called express.static(). When you mount it, Express looks in the specified folder for a matching file whenever a GET request comes in. If a file is found, Express serves it directly without touching any of your route handlers. If it isn't found, the request falls through to whatever comes next in your middleware chain.

const express = require('express');
const path    = require('path');
const app     = express();

// Serve files from the uploads/ directory
// under the URL prefix /uploads
app.use(
  '/uploads',
  express.static(path.join(__dirname, 'uploads'))
);

// Now a file at: uploads/avatars/user-001.jpg
// Is served at:  GET /uploads/avatars/user-001.jpg

Using path.join(__dirname, 'uploads') instead of a relative string is worth noting. Relative paths are resolved from wherever the node process was launched, which can cause confusing "file not found" errors if you start your server from a different directory. __dirname is always the directory of the current file reliable regardless of where you invoke node.

express.static() is essentially a tiny file server baked into your Express app. It handles caching headers, ETags, range requests, and content-type detection things you'd spend hours implementing yourself.

Controlling the URL prefix

The first argument to app.use() sets the URL prefix. You can use any path you like it doesn't have to match the folder name. A user never needs to know your server's folder structure:

// Folder: uploads/
// Public URL prefix: /media
app.use('/media', express.static('uploads'));

// File on disk: uploads/photo.jpg
// Accessed via: GET /media/photo.jpg  

Accessing Uploaded Files via URL

The most common pattern is to return the file's URL immediately after upload, so the client can display or link to it right away. Your route handler should construct the URL from the saved filename:

app.post('/upload/avatar', upload.single('avatar'), (req, res) => {
  if (!req.file) {
    return res.status(400).json({ error: 'No file received' });
  }

  // Build a public-facing URL from the saved filename
  const fileUrl = `\({req.protocol}://\){req.get('host')}/uploads/${req.file.filename}`;

  // Typically you'd save fileUrl to a database here
  res.status(201).json({
    message: 'Upload successful',
    url:     fileUrl,
  });
});

Security Considerations for Uploads

File uploads are one of the most common attack vectors in web applications. A form that accepts files is essentially an invitation for users to send whatever they want to your server. The defaults are not safe you have to explicitly lock things down.

The non-negotiables

• Always set a file size limit. Without limits.fileSize, a user can upload a multi-gigabyte file and crash your server.

• Validate the file type server-side. Checking file.mimetype is a minimum. For sensitive use cases, inspect magic bytes with a library like file-type.

• Never use the original filename. A user could send ../../../etc/passwd as a filename. Always generate your own — Multer's random hash or your own UUID.

• Store uploads outside the web root. If your uploads folder is outside public/, it can't be served accidentally. Only expose files you explicitly serve via static middleware.

• Never execute uploaded files. Even if you're expecting a script file, never run it. Uploaded files should be treated as data — read, stored, downloaded. Never executed.

• Consider image resizing/re-encoding. A malicious PNG can embed harmful data in metadata or exploit decoder vulnerabilities. Re-encoding images with a library like sharp strips unknown data.

Error handling for rejected uploads

When Multer rejects a file due to file size, bad type, or too many files — it passes an error to the next middleware. You need to catch this explicitly, otherwise Express will respond with a generic 500:

app.post('/upload', (req, res, next) => {
  upload.single('image')(req, res, (err) => {
    if (err instanceof multer.MulterError) {
      // Multer-specific errors (LIMIT_FILE_SIZE, etc.)
      if (err.code === 'LIMIT_FILE_SIZE') {
        return res.status(413).json({ error: 'File too large. Max 5 MB.' });
      }
      return res.status(400).json({ error: err.message });
    }
    if (err) {
      // fileFilter or other custom errors
      return res.status(400).json({ error: err.message });
    }

    // No error — proceed normally
    handleUpload(req, res);
  });
});

function handleUpload(req, res) {
  if (!req.file) return res.status(400).json({ error: 'No file' });
  res.json({ url: `/uploads/${req.file.filename}` });
}

Complete Example: Upload, Store, Serve

Here is a fully working minimal server that combines storage configuration, static file serving, file type filtering, size limits, and proper error handling:

const express = require('express');
const multer  = require('multer');
const path    = require('path');
const fs      = require('fs');

const app        = express();
const UPLOAD_DIR = path.join(__dirname, 'uploads');

// Ensure the uploads folder exists
fs.mkdirSync(UPLOAD_DIR, { recursive: true });

// Storage 
const storage = multer.diskStorage({
  destination: (req, file, cb) => cb(null, UPLOAD_DIR),
  filename:    (req, file, cb) => {
    const ext    = path.extname(file.originalname).toLowerCase();
    const unique = `${Date.now()}-` + Math.random().toString(36).slice(2);
    cb(null, unique + ext);
  },
});

// Multer instance 
const upload = multer({
  storage,
  limits:     { fileSize: 5_000_000 },
  fileFilter: (req, file, cb) => {
    const ok = ['image/jpeg', 'image/png', 'image/webp'];
    cb(ok.includes(file.mimetype) ? null : new Error('Images only'), ok.includes(file.mimetype));
  },
});

// Static serving 
app.use('/uploads', express.static(UPLOAD_DIR));

// Upload route (with error handling) 
app.post('/upload', (req, res) => {
  upload.single('image')(req, res, (err) => {
    if (err) {
      const status = err.code === 'LIMIT_FILE_SIZE' ? 413 : 400;
      return res.status(status).json({ error: err.message });
    }
    if (!req.file) {
      return res.status(400).json({ error: 'No file provided' });
    }

    const fileUrl = `/uploads/${req.file.filename}`;
    res.status(201).json({ url: fileUrl });
  });
});

app.listen(3000, () => console.log('Server on :3000'));

When you submit a plain HTML form name, email, that sort of thing the browser encodes everything as application/x-www-form-urlencoded. It's a simple key=value string, and Express's built-in body parser handles it without complaint.

But the moment a <input type="file"> enters the picture, the rules change. The browser switches to a completely different encoding: multipart/form-data. Instead of a flat string, it sends a binary stream divided into labeled sections called "parts" one for each field, one for each file. Each part has headers, a boundary marker, and its own raw content.

Think of multipart/form-data like a series of envelopes inside one package. Each envelope is a separate field — some contain plain text, others contain binary file data.

Express's default body parsers don't know how to open those envelopes. They'll parse JSON, they'll parse URL-encoded text, but multipart? They leave it alone. That's why you need dedicated middleware something that can read the binary stream, separate the parts, and hand them to your route handler in a usable shape.

Why not use body-parser?
The popular body-parser package explicitly does not support multipart bodies. Its README says so. This is by design multipart parsing is complex enough to warrant its own focused library.

What Multer Is

Multer is a Node.js middleware built specifically for handling multipart/form-data. It sits between the incoming request and your route handler, reads the binary stream, separates files from text fields, and attaches everything neatly to req.file or req.files.

Multer is built on top of busboy, a fast streaming multipart parser. It's the most widely used file upload middleware in the Express ecosystem, and for good reason it handles the messy parts so you don't have to.

Install it alongside Express:

npm install express multer

Multer's job is straightforward: intercept the request before your route handler runs, extract all the file and field data, save files to wherever you've configured, and populate req.body (for text fields) and req.file / req.files (for uploaded files).

The Upload Lifecycle

Before writing any code, it helps to see the full picture of what happens when a file travels from a browser to your server:

Three steps, every time: the browser sends the multipart stream, Multer intercepts and processes it, and your handler receives clean, ready-to-use file data.

Handling a Single File Upload

Let's start with the most common case a user uploading one file. The HTML side is just a standard form with enctype="multipart/form-data". Without that attribute, the file never makes it to the server.

Create a UI

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

On the server, Multer's .single(fieldName) method returns middleware that looks for one file in the named field:

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

const app    = express();
const upload = multer({ dest: 'uploads/' });

// .single('avatar') → look for a field named "avatar"
app.post('/upload', upload.single('avatar'), (req, res) => {

  // req.file contains the uploaded file metadata
  // req.body contains any other text fields
  if (!req.file) {
    return res.status(400).json({ error: 'No file uploaded' });
  }

  res.json({
    message:      'Upload successful',
    filename:     req.file.filename,
    originalName: req.file.originalname,
    size:         req.file.size,
    mimetype:     req.file.mimetype,
  });
});

app.listen(3000);

After Multer runs, req.file is an object with everything you need to know about the uploaded file. The most useful properties: req.file

{
  fieldname:   'avatar',         // HTML field name
  originalname:'profile-pic.jpg',  // filename from user's machine
  encoding:    '7bit',
  mimetype:    'image/jpeg',       // detected content type
  destination: 'uploads/',         // folder where file was saved
  filename:    'a3f9c1b2d4e8...',  // generated unique name (no ext)
  path:        'uploads/a3f9c1...',// full path on disk
  size:        82034               // bytes
}

When using dest shorthand, Multer saves files without their original extension. The filename is a random hash. You'll need to rename it or use diskStorage if you want to preserve extensions — covered in the Storage section below.

Handling Multiple File Uploads

Two situations arise with multiple files. Either the user uploads several files through one input field, or you have multiple fields each accepting their own files. Multer has a method for each.

Multiple files from a single field

Use .array(fieldName, maxCount). The second argument is optional but highly recommended it caps how many files can arrive in one request:

app.post('/upload-many', upload.array('photos', 10), (req, res) => {

  // req.files is an array of file objects
  const filenames = req.files.map(f => f.filename);
  res.json({ uploaded: filenames });

});

Files from multiple fields

Use .fields() when each field has a distinct name. Pass an array of field descriptors:

const cpUpload = upload.fields([
  { name: 'avatar',   maxCount: 1  },
  { name: 'portfolio', maxCount: 5  },
]);

app.post('/profile', cpUpload, (req, res) => {

  // req.files is now an object, keyed by field name
  const avatar    = req.files['avatar'][0];    // one file
  const portfolio = req.files['portfolio'];    // array of files

  res.json({ avatarName: avatar.filename });
});

Storage Configuration Basics

The dest shorthand is fine for quick experiments, but production code usually needs more control. Multer's diskStorage engine gives you two configuration hooks: where to put the file, and what to name it.

const path   = require('path');
const multer = require('multer');

const storage = multer.diskStorage({

  // 1. Where should the file be saved?
  destination(req, file, cb) {
    cb(null, 'uploads/');  // first arg is error (null = no error)
  },

  // 2. What should the file be called?
  filename(req, file, cb) {
    const ext      = path.extname(file.originalname);
    const uniqueSuffix = Date.now() + '-' + Math.round(Math.random() * 1e9);
    cb(null, file.fieldname + '-' + uniqueSuffix + ext);
    // Result: "avatar-1718023456789-382910483.jpg"
  },

});

const upload = multer({ storage });

Both destination and filename follow the same node-style callback pattern: the first argument to cb is an error (pass null to proceed), and the second is your value. This pattern lets you run async logic like checking a database before deciding where a file should land.

File Type Filtering

You don't want users uploading executable files when you're expecting images. Multer lets you filter incoming files with a fileFilter function. If the filter rejects a file, the request continues without it — or you can throw an error:

function imageFilter(req, file, cb) {
  const allowed = ['image/jpeg', 'image/png', 'image/webp'];

  if (allowed.includes(file.mimetype)) {
    cb(null, true);   // accept the file
  } else {
    cb(new Error('Only JPEG, PNG, and WebP images are allowed'));
  }
}

const upload = multer({
  storage,
  fileFilter: imageFilter,
  limits: { fileSize: 5 * 1024 * 1024 }  // 5 MB cap
});

Serving Uploaded Files

Saving files is half the job. Once they're on disk, you need users to be able to retrieve them. Express's built-in express.static() middleware makes this trivially easy:

// Serve everything in the uploads/ folder under the /uploads URL path
app.use('/uploads', express.static('uploads'));

// A file saved at uploads/avatar-1718023456.jpg
// is now available at: http://localhost:3000/uploads/avatar-1718023456.jpg

That one line turns your upload folder into a file server. Any file sitting in uploads/ becomes publicly accessible via its filename in the URL.

Key Takeaways

1. HTML forms must useenctype="multipart/form-data"— without it, no file data is sent.

2. Multer interposes itself in the middleware chain, reading the stream before your handler runs.

3. Use.single(),.array(), or.fields()depending on your form shape.

4. diskStoragegives full control over folder and filename; use it in production.

5. Always limit file size and filter by type to prevent abuse.

6. express.static()

But then you actually build auth and a weird bug shows up. A logged-out user still gets in. Your JWT is 8 kilobytes. Your "stateless" microservices are calling a central database on every request. Something is off.

This article is about those moments. The things tutorials skip. Let's go from the foundations up, but stop at the places where the real decisions live.

Cookies: Just a Box in the Truck

Here's the misconception that causes the most confusion: a cookie is not an authentication strategy. It's a storage mechanism a key-value pair the browser saves and automatically sends back with every request to the same domain.

That's it. The browser does the sending for you. You don't write any fetch logic to attach cookies to requests. This is both a convenience and the source of CSRF attacks.

Cookies predate modern JavaScript. They were designed for a world without fetch(). The browser's automatic attachment behavior is a legacy of that era — and it's exactly what makes them dangerous if you don't set the right flags.

The Three flags you must set

Every developer knows cookies exist. Few consistently set all three of these on production auth cookies:

• HttpOnlyPrevents JavaScript from reading the cookie. This is the single most effective mitigation against XSS stealing your session token. If you can access your auth cookie via document.cookie, you've already lost.

• SecureOnly sends the cookie over HTTPS. Without this, your token travels in cleartext. You'd be surprised how many staging environments skip this and then wonder why tokens leak.

• SameSite=Strict or LaxControls cross-site sending. Strict is safest — the cookie won't go with any cross-origin request. Lax allows top-level navigations (clicking a link). The default used to be None, which is a CSRF nightmare. Modern browsers default to Lax now, but don't rely on that.

Storing a JWT inside localStorage gives it zero of the protections above. Any XSS vulnerability on your page can read it, send it anywhere, and impersonate your user indefinitely — because JWTs don't expire until their exp claim says so.

Sessions: The Server Remembers You

Session-based authentication is the original approach. It works like a coat check at a restaurant. You hand over your coat (credentials), they give you a numbered ticket (session ID), and later you return the ticket to get the coat back.

The server stores the actual session data user ID, roles, cart contents, whatever in memory or a database. The client only holds the ticket. The ticket itself is meaningless without the server's ledger.

The critical thing to understand: the session ID that lives in the cookie is opaque. It's a random string. It carries zero information on its own. All the meaning lives server-side.

The "sessions don't scale" myth. You'll hear that sessions are stateful and therefore don't scale horizontally. This was true when sessions lived in server memory. Move session storage to Redis and suddenly you have a distributed, in-memory session store that handles hundreds of thousands of concurrent users. The real cost is the round-trip to Redis — about 0.5–2ms on a co-located instance. That's a completely acceptable trade-off for most applications.

JWT: The Server Trusts Your ID Card

JSON Web Tokens take a different philosophy. Instead of storing state on the server, you encode state into a token and send it to the client. The server signs the token cryptographically, so when the client sends it back, the server can verify the signature without looking anything up.

A JWT has three parts separated by dots: header.payload.signature. Base64URL-encoded. The payload is where your user data lives.

The most common JWT misconception: JWT is signed, not encrypted. Anyone can decode the payload — just paste it into jwt.io. Never put sensitive data (passwords, PII, API keys) in the payload. The signature only proves it wasn't tampered with; it doesn't hide the contents.

This "no database lookup" property is genuinely useful in microservice architectures where many services need to know who the user is. Pass the JWT and every service can independently verify it using the same public key.

What "stateless" actually costs you

Here's where most tutorials stop — but you shouldn't.

• You can't revoke a JWT. If a user logs out, changes their password, or you ban them — the JWT is still valid until it expires. The server has no record of it to invalidate. Your options: short expiry times (5–15 minutes) with refresh tokens, or maintain a token blocklist — which is just a session store under a different name.

• Refresh tokens bring back state. The standard pattern is a short-lived access token + a long-lived refresh token. The refresh token lives in the database. So you now have server-side state again. You've solved one problem (DB lookup per request) while creating another (periodic DB calls to refresh). Know the trade-off you're making.

• Token size hits your header limits. A typical JWT with a few claims is 500–700 bytes. Add roles, permissions, and org context and you can easily hit 2–4KB. Some proxies and CDNs have header size limits. Every request carries this overhead. Compare that to a 32-byte session ID.

• Clock skew can expire tokens prematurely. JWTs use Unix timestamps for iat, nbf, and exp. If your servers aren't NTP-synced, a token signed on Server A might be rejected as expired or "not yet valid" by Server B. Most libraries include a small leeway (60s), but this bites teams with containerized environments that don't sync clocks properly.

• Algorithm confusion attacks are real. The JWT header specifies which algorithm was used to sign the token. An early class of vulnerabilities involved setting the algorithm to none and removing the signature — some libraries would accept this. Always explicitly specify which algorithms your library should accept. Never trust the header's algorithm claim blindly.

When to Use Each

"The best auth system is the one your team understands well enough to avoid shooting themselves in the foot."

Reach for Sessions when

• You need instant account revocation (banking, enterprise SaaS)

• Your app is a single domain — no cross-subdomain auth needed

• You change user roles frequently

• You're a small team and want simple, proven auth

• You have access to a shared cache (Redis) for your servers

Reach for JWT when

• Multiple services need to verify identity independently

• You have mobile clients or third-party API consumers

• You're building an auth server (OAuth / OIDC)

• Cross-domain or cross-subdomain auth is required

• You can tolerate short windows of stale token data

Best Practices to follow while build Auth System

JWT in a cookie is usually better than JWT in localStorage

The instinct when using JWTs is to store them in localStorage it's JavaScript-accessible, simple to use, and feels "modern." But localStorage is readable by any script on your page. One XSS vulnerability and your token is gone. Store JWT in a HttpOnly cookie and you get the best of both worlds: stateless verification on the server, and XSS-resistant storage on the client.

The trade-off is that cookies bring CSRF exposure back. Handle it with SameSite=Strict and you've solved that too. This combination JWT + HttpOnly cookie + SameSite is what most security-conscious teams actually use in production.

The "sub" claim should be an opaque ID, not an email

The sub (subject) claim in JWT is supposed to identify who the token is for. Beginners often put the user's email address here. The problem: emails change. If a user changes their email and you're using it as a key, you've got a mismatch. Use an internal UUID or integer ID that never changes.

Don't put sensitive data in the JWT payload

Again, because this cannot be said enough: eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjQyLCJzc246IjEyMy00NS02Nzg5In0 is not encrypted. The middle section decodes to plain JSON. Never put SSNs, passwords, credit card tokens, or any PII in the payload. The signature proves authenticity; it doesn't provide confidentiality. If you need confidentiality, use JWE (JSON Web Encryption) but that's a separate spec and significantly more complex.

Set a sane expiry on sessions too

Developers obsess over JWT expiry but forget to set expiry on sessions. A session with no TTL in Redis (or no timeout in your session library) lives forever. A user who logged in three years ago and never explicitly logged out still has a valid session. Set both absolute expiry and idle timeout. Absolute: "this session is invalid after 30 days regardless." Idle: "this session is invalid if unused for 2 hours."

Authentication is one of those topics where the basics are well-documented, and the hard parts are learned through painful production incidents. The goal isn't to pick the "right" answer it's to pick the approach whose trade-offs your team understands completely.

Sessions give you control and simplicity. JWTs give you distribution and flexibility. Cookies give both a transport mechanism. None of them are magic. All of them have sharp edges. Now you know where to watch your fingers.

The Simplest Definition

Middleware is a function that runs between the incoming request and the final route handler.

That's it. Any function in Express that receives req, res, and next is middleware.

function myMiddleware(req, res, next) {
  // do something with the request or response
  next(); // pass control to the next function
}

Three parameters. That's the signature. The next function is what makes it middleware rather than a route handler calling next() says "I'm done, pass this request to whoever is registered next."

Middleware in the Request Lifecycle

Think of every Express request as going through a pipeline — a series of checkpoints before it reaches the final destination. Each checkpoint can inspect the request, modify it, add data to it, block it entirely, or pass it through.

Incoming request
      ↓
  [Middleware 1]   ← logging: log method + URL, call next()
      ↓
  [Middleware 2]   ← auth: check token, call next() or return 401
      ↓
  [Middleware 3]   ← body parser: parse JSON into req.body, call next()
      ↓
  [Route handler]  ← do the actual work, send the response
      ↓
Outgoing response

Every function in that chain gets the same req and res objects. If middleware attaches something to req say, req.user = decodedToken every function after it in the chain can access req.user. This is how authentication middleware passes the authenticated user to a route handler.

The next() Function

next() is what keeps the chain alive. When middleware calls next(), Express moves to the next registered function. When middleware doesn't call next() (and doesn't send a response either), the request just hangs. The client waits forever. This is one of the most common Express bugs a middleware that silently swallows requests.

// Correct — always either call next() or send a response
function checkHeader(req, res, next) {
  if (!req.headers['x-api-key']) {
    return res.status(401).json({ error: 'API key required' });
    // we're done — no next() needed, response is sent
  }
  next(); // key exists — move on
}

Two exits: send a response (and stop), or call next() (and continue). Every middleware must do one of the two.

What most tutorials don't explain about next(): you can pass an argument to next(). Passing anything (by convention, an error object) skips all remaining regular middleware and jumps directly to an error-handling middleware:

function riskyOperation(req, res, next) {
  try {
    const result = doSomethingDangerous();
    next();
  } catch (err) {
    next(err); // skip to error handler
  }
}

// Error-handling middleware: 4 parameters, always (err, req, res, next)
app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ error: 'Something went wrong' });
});

The four-parameter signature is Express's convention for error handlers. Express identifies them specifically by the number of parameters not by name, not by position, just by arity. If you write (err, req, res, next), Express treats it as an error handler and only calls it when next(err) is called somewhere upstream.

Types of Middleware

Application-level middleware

Registered on the app object with app.use(). Runs for every matching request.

// Runs for every request, every path
app.use((req, res, next) => {
  console.log(`\({req.method} \){req.url}`);
  next();
});

// Runs only for requests to /api/*
app.use('/api', (req, res, next) => {
  console.log('API request received');
  next();
});

Router-level middleware

The same concept, but attached to an express.Router() instance instead of the app. This is how you apply middleware only to a subset of routes:

const router = express.Router();

// Applies to all routes in this router
router.use((req, res, next) => {
  console.log('Router-level middleware');
  next();
});

router.get('/profile', (req, res) => {
  res.json({ user: req.user });
});

app.use('/users', router);

If you mount this router at /users, the middleware only runs for requests to /users/*.

Built-in middleware

Express ships with a few middleware functions out of the box — no extra packages needed:

express.json() — parses request bodies with Content-Type: application/json. Makes them available as req.body.

app.use(express.json());

express.urlencoded({ extended: true }) — parses URL-encoded form data (the kind HTML forms submit). Makes it available as req.body.

app.use(express.urlencoded({ extended: true }));

express.static(directory) — serves static files (HTML, CSS, images, JS) from a folder.

app.use(express.static('public')); // serves files from ./public

These are the ones you'll register on almost every Express app. There's also express.raw() and express.text() for other content types, but they're less commonly needed.

Execution Order:

Middleware runs in the exact order it's registered. There are no priorities, no weights just top to bottom.

app.use(loggerMiddleware);      // 1 — runs first
app.use(express.json());        // 2 — then body parsing
app.use(authMiddleware);        // 3 — then authentication

app.get('/dashboard', (req, res) => {
  // 4 — route handler (only if all middleware called next())
  res.json({ page: 'dashboard', user: req.user });
});

A request to GET /dashboard runs through all four in sequence. If authMiddleware returns a 401, the route handler never runs.

What happens with multiple route handlers matching the same path? They run in order too. This is less obvious but occasionally useful:

app.get('/users/:id', loadUser);     // attaches user to req
app.get('/users/:id', checkAccess);  // verifies req.user can see this user
app.get('/users/:id', sendResponse); // sends the response

Three separate handler registrations for the same route. Each calls next() to pass to the next. This is called "route chaining" and it's a valid (if uncommon) pattern for decomposing complex route logic.

Real-World Examples

Logging middleware

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

  // Intercept res.end to know when the response was sent
  const originalEnd = res.end.bind(res);
  res.end = function (...args) {
    const duration = Date.now() - start;
    console.log(`\({req.method} \){req.url} \({res.statusCode} — \){duration}ms`);
    return originalEnd(...args);
  };

  next();
}

app.use(logger);

Middleware is a conveyor belt. Each station on the belt can inspect the item, stamp it, reject it, or pass it along. The req and res objects are the item they get passed from station to station. next() is the button that moves the belt forward.

Some stations are always running (global middleware). Some only activate for certain routes. Some are fail-safes at the end (error handlers). Together, they turn a raw HTTP request into a handled, validated, authenticated, logged transaction.

Once you see Express this way, the whole framework clicks.

Anatomy of a URL

Before distinguishing between the two, let's look at a URL in full:

https://api.example.com/users/42/posts?status=published&sort=desc&page=2

Breaking it apart:

https://              ← protocol
api.example.com       ← host
/users/42/posts       ← path (contains a URL parameter: 42)
?                     ← query string delimiter
status=published      ← query parameter 1
&sort=desc            ← query parameter 2
&page=2               ← query parameter 3

The path is everything before the ?. The query string is everything after it. URL parameters live in the path. Query parameters live after the ?.

What URL Parameters Are

A URL parameter (also called a route parameter or path parameter) is a named placeholder inside the URL path that captures a dynamic value.

In Express, you mark a parameter with a colon:

app.get('/users/:id', (req, res) => {
  console.log(req.params.id); // "42" (always a string)
});

When a request arrives for /users/42, Express extracts 42 from that position in the path and puts it in req.params.id.

You can have multiple parameters:

app.get('/users/:userId/posts/:postId', (req, res) => {
  console.log(req.params.userId); // "7"
  console.log(req.params.postId); // "103"
});

A request to /users/7/posts/103 populates both. The parameter name in :paramName is the key in req.params.

The defining characteristic of URL parameters: they identify which resource you're talking about. Remove the parameter and the URL refers to a completely different resource — or nothing at all.

/users/42    → user with id 42
/users/99    → user with id 99 (different resource)
/users       → the users collection (entirely different resource)

The parameter is structural. It's load-bearing. The URL doesn't make sense without it.

What Query Strings Are

A query string is a set of key-value pairs appended to the URL after a ?. They're optional the URL is still valid and meaningful without them.

In Express, query parameters live in req.query:

app.get('/users', (req, res) => {
  console.log(req.query.role);   // "admin"
  console.log(req.query.sort);   // "created_at"
  console.log(req.query.order);  // "desc"
});

A request to /users?role=admin&sort=created_at&order=desc produces that output. If none of those query params were sent, the route still matches /users req.query would just be an empty object {}.

The defining characteristic of query parameters: they modify or filter a request. Remove a query param and you get more results, different ordering, or a different page but you're still talking about the same resource.

/users                               → all users, default order
/users?sort=name                     → all users, sorted by name
/users?role=admin                    → only admins
/users?role=admin&sort=name&page=2   → second page of admins, sorted by name

The resource (/users) is the same. The query params shape how that resource is returned.

Accessing Params in Express: req.params

req.params is an object containing all named URL parameters defined in your route.

app.get('/posts/:postId/comments/:commentId', (req, res) => {
  const { postId, commentId } = req.params;

  // Always strings — always parseInt or Number() them
  const post    = parseInt(postId);
  const comment = parseInt(commentId);

  res.json({ post, comment });
});

Request: GET /posts/5/comments/88 Response: { "post": 5, "comment": 88 }

The string trap: req.params values are always strings, even if they look like numbers. req.params.id === 42 will always be false because you're comparing "42" (string) to 42 (number). Always convert before comparing or using in arithmetic.

const id = parseInt(req.params.id);
// or
const id = Number(req.params.id);

If the parameter might not be a number (like a username or slug), keep it as a string and use it directly.

Optional parameters: Express supports optional segments with ?:

app.get('/users/:id?', (req, res) => {
  if (req.params.id) {
    res.json({ user: req.params.id });
  } else {
    res.json({ users: 'all' });
  }
});

A single route handles both /users and /users/42. Useful, but in practice it's usually cleaner to keep these as separate routes. Combining them adds complexity for little gain.

Express allows you to define pre-processing logic for a named parameter using app.param():

app.param('id', (req, res, next, id) => {
  const parsed = parseInt(id);
  if (isNaN(parsed)) {
    return res.status(400).json({ error: 'ID must be a number' });
  }
  req.params.id = parsed; // replace the string with the number
  next();
});

// Now every route using :id gets a pre-validated integer
app.get('/users/:id', (req, res) => {
  // req.params.id is already a number here — no parseInt needed
  res.json({ id: req.params.id });
});

This runs before any route handler that includes :id. You validate and transform once, and every handler benefits. This is one of Express's more underused features.

Accessing Query Strings in Express: req.query

req.query is an object containing all query parameters. Express parses the query string automatically — no setup required.

app.get('/products', (req, res) => {
  const {
    category,           // string or undefined
    minPrice,           // string or undefined
    maxPrice,           // string or undefined
    sort = 'name',      // default to 'name' if not provided
    page = '1',         // default to '1'
    limit = '20',
  } = req.query;

  // Parse numeric values
  const min  = minPrice ? parseFloat(minPrice) : 0;
  const max  = maxPrice ? parseFloat(maxPrice) : Infinity;
  const pg   = parseInt(page);
  const lim  = parseInt(limit);

  res.json({ category, min, max, sort, pg, lim });
});

Request: GET /products?category=electronics&minPrice=50&sort=price

Response:

{
  "category": "electronics",
  "min": 50,
  "max": null,
  "sort": "price",
  "pg": 1,
  "lim": 20
}

Always default your query params. A request to /products with no query string should still work — req.query will be {} and destructuring gives you undefined for everything. Default values in destructuring handle this cleanly.

The string trap again: same issue as URL parameters. req.query values are always strings. req.query.page === 1 is always false. Parse numbers explicitly.

Arrays in query strings: Express handles repeated keys as arrays automatically:

GET /products?tag=javascript&tag=nodejs&tag=backend

app.get('/products', (req, res) => {
  console.log(req.query.tag); // ['javascript', 'nodejs', 'backend']
});

But if only one value is sent, req.query.tag is a string, not an array. To always get an array:

const tags = [].concat(req.query.tag || []);
// or
const tags = Array.isArray(req.query.tag)
  ? req.query.tag
  : req.query.tag ? [req.query.tag] : [];

This is a common bug in Express APIs code that works fine with multiple tags silently breaks when only one is sent.

Here's a clean mental model:

Use a URL parameter when:

• It identifies a specific resource

• The URL is meaningless or broken without it

• There's only one logical value for that position

Use a query string when:

• It modifies how a resource (or collection) is returned

• It's optional — the endpoint works without it

• Multiple key-value pairs might apply simultaneously

Real-World Scenarios

User profile: /users/:id

The id is a URL parameter — it identifies the user. Without it, the URL refers to the collection of all users, not this specific person.

User search: /users?q=alice&role=admin

The q and role are query strings — they filter the collection. Without them, you still get users (just all of them).

Blog post: /posts/:slug

The slug is a URL parameter — it identifies this specific article. /posts is the list; /posts/building-rest-apis-with-express is the specific post.

Blog post list: /posts?tag=nodejs&author=john&page=2

All query strings — they modify the list, not the resource identity.

E-commerce product: /products/:productId

URL parameter — identifies the product.

Product reviews: /products/:productId/reviews?sort=rating&page=1

Mixed. :productId is a parameter — which product's reviews. sort and page are query strings — how to return those reviews.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

What Express.js Actually Is

Express is a minimal web framework for Node.js. That word minimal is important it doesn't come with an ORM, a templating engine, a validation library, or an authentication system built in. It comes with routing, middleware support, and a cleaner interface around Node's http module.

This is intentional. Express is a foundation, not a full solution. The developer community built the ecosystem around it hundreds of middleware packages that plug in cleanly so you compose exactly what you need, rather than inheriting what a framework decided you should have.

Raw Node.js vs Express: The Problem It Solves

Let's see the gap side by side.

Handling two routes in raw Node.js:

const http = require('http');

const server = http.createServer((req, res) => {
  if (req.method === 'GET' && req.url === '/') {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ message: 'Home' }));
  } else if (req.method === 'GET' && req.url === '/users') {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ users: [] }));
  } else if (req.method === 'POST' && req.url === '/users') {
    let body = '';
    req.on('data', chunk => { body += chunk.toString(); });
    req.on('end', () => {
      const data = JSON.parse(body);
      res.writeHead(201, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify(data));
    });
  } else {
    res.writeHead(404);
    res.end('Not found');
  }
});

server.listen(3000);

This works. But notice what you're dealing with:

• Manual if/else routing on every request

• Checking method and URL manually every time

• Manually reading the request body stream in chunks

• Manually setting Content-Type headers on every response

• No URL parameters (try matching /users/42 — you'd need a regex or a URL parser)

The same routes in Express:

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

app.get('/', (req, res) => {
  res.json({ message: 'Home' });
});

app.get('/users', (req, res) => {
  res.json({ users: [] });
});

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

app.listen(3000);

Express removes all the boilerplate. The routing is declarative. Body parsing is handled by middleware. res.json() sets Content-Type automatically. The intent of every route is immediately obvious.

Installing Express

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

Create index.js and you're ready.

Your First Express Server

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

app.use(express.json());

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

Three things happening here:

require('express') — imports the Express module. Express exports a function; calling it creates an application instance.

app.use(express.json()) — registers middleware. This specific middleware reads the incoming request body and parses it as JSON, making it available as req.body. Without this line, req.body is undefined for POST requests. It only parses requests with Content-Type: application/json — it doesn't touch form submissions or plain text.

app.listen(3000, callback) — binds the server to port 3000. The callback fires once when the server is ready. This is exactly equivalent to creating an http.Server and calling .listen() on it.

Express does that for you internally.

How Routing Works in Express

A route is the combination of an HTTP method and a URL path. When a request arrives, Express walks through your registered routes in the order you defined them and calls the first one that matches both the method and the path.

The basic signature is:

js

app.METHOD(PATH, HANDLER)

Where METHOD is get, post, put, delete, patch, or others. PATH is a string (or a regex, or an array). HANDLER is a function that receives req and res.

app.get('/hello', (req, res) => {
  res.send('Hello, world');
});

If a GET request arrives for /hello, this handler runs. If the method is POST, it won't match. If the path is /hello/world, it won't match either (unless you use wildcards).

What most tutorials don't explain: the order of route definitions matters. Express matches routes top to bottom, first match wins. If you define a broad route before a specific one, the broad one catches the request and the specific one never runs.

// Broad route defined first — always wins
app.get('/users/*', (req, res) => {
  res.send('wildcard'); // this matches /users/admin too
});

// This never runs — the route above caught it first
app.get('/users/admin', (req, res) => {
  res.send('admin panel');
});

Always define specific routes before general ones.

Handling GET Requests

GET is the most common HTTP method fetch data, list resources, retrieve a single item.

// Simple static route
app.get('/', (req, res) => {
  res.json({ status: 'ok', version: '1.0' });
});

// List resource
app.get('/products', (req, res) => {
  const products = [
    { id: 1, name: 'Keyboard', price: 79 },
    { id: 2, name: 'Mouse',    price: 39 },
  ];
  res.status(200).json(products);
});

// Single resource with URL parameter
app.get('/products/:id', (req, res) => {
  const id = parseInt(req.params.id);
  const product = products.find(p => p.id === id);

  if (!product) {
    return res.status(404).json({ error: 'Product not found' });
  }

  res.status(200).json(product);
});

:id in the path is a named URL parameter. Express captures whatever is in that position in the URL and puts it in req.params.id. More on parameters in the next article for now, know they exist and look like :name.

Handling POST Requests

POST is used to create new resources. Data comes in the request body, not the URL.

app.post('/products', (req, res) => {
  const { name, price } = req.body;

  // Validate
  if (!name || price === undefined) {
    return res.status(400).json({ error: 'name and price are required' });
  }

  if (typeof price !== 'number' || price < 0) {
    return res.status(400).json({ error: 'price must be a non-negative number' });
  }

  // Create
  const newProduct = {
    id: Date.now(), // simple ID for demo
    name,
    price,
  };

  res.status(201).json(newProduct);
});

req.body works because express.json() middleware ran first and parsed the request body. If the client sends Content-Type: application/json and valid JSON in the body, req.body will be a JavaScript object.

The return before each error response is critical. Without it, Express attempts to send a second response after the first res.json() call, which throws a "Cannot set headers after they are sent" error. The return exits the handler function immediately.

What happens when the client sends invalid JSON? If the body is malformed, express.json() will respond with a 400 error automatically before your handler even runs. You don't need to handle JSON parse errors yourself — the middleware does it. But if you want to customize that error response (to match your API's error format), you can add an error-handling middleware:

app.use((err, req, res, next) => {
  if (err.type === 'entity.parse.failed') {
    return res.status(400).json({ error: 'Invalid JSON in request body' });
  }
  next(err);
});

The four-parameter signature (err, req, res, next) is Express's convention for error-handling middleware. It only runs when an error is passed or thrown.

Sending Responses

Express's res object extends Node's built-in response, adding helper methods that handle headers automatically.

res.json(data) — sends a JSON response. Sets Content-Type: application/json and status 200 automatically. Calls JSON.stringify internally.

res.json({ id: 1, name: 'Alice' });

res.status(code) — sets the HTTP status code. It returns res so you can chain it:

res.status(201).json({ id: 1, name: 'Alice' }); // 201 Created
res.status(404).json({ error: 'Not found' });    // 404 Not Found

res.send(body) — sends a response. If you pass a string, Content-Type is text/html. If you pass an object, it behaves like res.json(). Prefer res.json() for APIs — it's explicit about the content type.

res.status(204).send() — sends an empty response. Required for DELETE endpoints where there's no body to return.

res.set(header, value) — sets a custom response header:

res.set('X-Request-Id', 'abc123').json({ data: '...' });

What most developers don't know about res.json(): it runs JSON.stringify with the json spaces app setting. You can configure pretty-printing for development:

app.set('json spaces', 2); // pretty-print JSON in development

This makes responses human-readable in development without changing your code. Set it conditionally:

if (process.env.NODE_ENV !== 'production') {
  app.set('json spaces', 2);
}

A Complete Working Server

Here's everything put together — a small but complete server covering multiple routes and both methods:

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

app.use(express.json());

// In-memory store
let books = [
  { id: 1, title: 'The Pragmatic Programmer', author: 'Hunt & Thomas' },
  { id: 2, title: 'Clean Code',               author: 'Robert Martin'  },
];
let nextId = 3;

// GET all books
app.get('/books', (req, res) => {
  res.status(200).json(books);
});

// GET one book
app.get('/books/:id', (req, res) => {
  const book = books.find(b => b.id === parseInt(req.params.id));
  if (!book) return res.status(404).json({ error: 'Book not found' });
  res.status(200).json(book);
});

// POST create a book
app.post('/books', (req, res) => {
  const { title, author } = req.body;

  if (!title || !author) {
    return res.status(400).json({ error: 'title and author are required' });
  }

  const book = { id: nextId++, title, author };
  books.push(book);
  res.status(201).json(book);
});

// 404 fallback — must be last
app.use((req, res) => {
  res.status(404).json({ error: `Cannot \({req.method} \){req.url}` });
});

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

Express Router: Splitting Routes Across Files

As an application grows, keeping every route in index.js becomes unmanageable. Express's Router is a mini-app — it has its own .get(), .post(), .use(), etc. — that you can mount on a path.

// routes/books.js
const express = require('express');
const router = express.Router();

router.get('/', (req, res) => {
  res.json(books);
});

router.post('/', (req, res) => {
  // create book
});

router.get('/:id', (req, res) => {
  // get one book
});

module.exports = router;

// index.js
const booksRouter = require('./routes/books');
app.use('/books', booksRouter);

Routers are also just middleware. You can stack multiple routers, nest them, add middleware that only applies to a specific router, and reuse them across different mount points. The same booksRouter mounted at /api/v1/books and /api/v2/books would serve both paths from the same code.

Understand what Express does under the hood (it's mostly Node's http module with a layer on top) and you'll never be confused by its behavior. Understand how route matching works (top-down, first match wins) and you'll never write a route that silently never runs.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

API stands for Application Programming Interface. Ignore the formal definition for a moment and think about what's actually happening.

You have a client a browser, a mobile app, a CLI tool, another server and you have a server that knows things or can do things the client needs. The API is the agreed upon language they use to talk.

When a user logs into an app, the frontend doesn't just magically know their data.

It sends a request to the server:
"Hey, here's a username and password — does this check out? If so, give me this user's profile."

The server checks, and responds:
"Yes, here it is."

That exchange, the format of the request, the format of the response is the API.

REST is a specific way of designing that exchange. It uses HTTP (the same protocol your browser uses to load web pages) and a set of conventions that make APIs predictable and consistent.

The Core Idea

REST stands for Representational State Transfer. The jargon doesn't help much. What does help is understanding the concept of a resource.

In REST, everything you expose through your API is a resource — a noun, a thing. Users are a resource. Posts are a resource. Orders, products, comments — all resources.

Each resource has a URL that identifies it. That URL is called an endpoint. The naming convention is clean: always use plural nouns, always lowercase, no verbs.

Good:
  /users
  /users/42
  /posts
  /posts/7/comments

Bad:
  /getUsers
  /deleteUser?id=42
  /createNewPost

The bad examples describe actions, not resources. The action is communicated via the HTTP method, not the URL. The URL should only tell you what you're operating on the HTTP method tells you how.

HTTP Methods: The Verbs of REST

HTTP ships with a set of methods sometimes called verbs that describe the intended operation on a resource. REST maps these directly to the four classic database operations known as CRUD: Create, Read, Update, Delete.

GET — Retrieve a resource. Read-only. Should never modify anything. Safe to call multiple times.

POST — Create a new resource. Sends data in the request body. Used when the server generates the ID.

PUT — Replace an existing resource entirely. You send the full updated version, the server stores it as-is.

DELETE — Remove a resource.

There's also PATCH, which is worth knowing even though it's less universal: it partially updates a resource. Where PUT replaces everything, PATCH just changes the fields you send. For a user profile, PUT would require sending name + email + age + every other field even if you're only changing the email. PATCH lets you send just { "email": "new@email.com" }.

Status Codes: The Server's Reply

When your server responds, it includes a status code a three-digit number that tells the client whether things went well, and if not, why not. Most developers know 404. There are many more.

The codes are grouped by their first digit:

2xx — Success

• 200 OK — generic success. Used for successful GET, PUT, PATCH responses.

• 201 Created — resource was successfully created (POST responses).

• 204 No Content — success, but nothing to return (DELETE responses).

4xx — Client errors (the request was wrong)

• 400 Bad Request — the client sent malformed data.

• 401 Unauthorized — no authentication was provided.

• 403 Forbidden — authenticated but not allowed.

• 404 Not Found — the resource doesn't exist.

• 409 Conflict — the request conflicts with current state (e.g. duplicate email).

• 422 Unprocessable Entity — data was well-formed but failed validation.

5xx — Server errors (something broke on your end)

• 500 Internal Server Error — generic catch-all server failure.

• 503 Service Unavailable — server is down or overloaded.

401 vs 403 is a distinction almost every junior API makes incorrectly. 401 means "who are you? I don't know you." 403 means "I know who you are, but you can't do this." If a user is logged in and tries to access another user's private data, that's a 403, not a 401. If there's no token at all, it's a 401.

Also: 404 vs 403 for private resources is a deliberate security decision. If a user asks for /users/99 and that user exists but belongs to someone else, should you return 404 (pretend it doesn't exist) or 403 (admit it exists but deny access)? Returning 404 is often the more secure choice it doesn't reveal which IDs exist.

Designing the Users Resource

Let's build a complete CRUD API for a users resource. In a real app you'd use a database here we'll use an in-memory array to keep the focus on the API design.

GET /users — List all users

GET /users/:id — Get one user

POST /users — Create a new user

PUT /users/:id — Replace a user

DELETE /users/:id — Remove a user

Route Naming: The Conventions That Actually Matter

These conventions aren't enforced by any framework. They're just what every experienced developer expects, which is exactly why they matter:

Use nouns, not verbs in URLs.

• /users not /getUsers, /createUser, /deleteUser

Use plural nouns for collections.

• /users not /user

• /posts not /post

Use URL parameters for specific resources.

• /users/42 not /users?id=42

Use query strings for filtering, sorting, pagination.

• /users?role=admin — filter by role

• /users?sort=created_at&order=desc — sorted list

• /users?page=2&limit=20 — pagination

Nested resources for relationships.

• /users/42/posts — all posts by user 42

• /users/42/posts/7 — a specific post by user 42

What most developers don't think about: versioning. When your API is public or consumed by mobile apps you don't control, you'll eventually need to change it in a breaking way. The standard solution is URL versioning: /api/v1/users, /api/v2/users. It's something you should add from the start, not retrofit later.

Error Consistency:

One thing that separates a professional API from a tutorial API: consistent error responses. Your errors should all look the same.

REST API design is largely a discipline of making decisions before you start coding and sticking to them. The decisions aren't hard: plural nouns, HTTP methods as verbs, correct status codes, consistent error shapes. None of these require advanced knowledge they just require intention.

Express.js gives you the minimum to implement all of this. No magic, no opinions just a router, middleware support, and req/res. The REST conventions layer on top cleanly.

Master one resource, get all the conventions right, and every other resource you add will look exactly the same. That's the whole point of REST: uniformity. Once a developer learns how one endpoint works, they understand how all of them work.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

Callbacks

A callback is the simplest possible async mechanism: pass a function as an argument, and Node.js will call it when the async work is done.

Here's the pattern, using fs.readFile as the canonical example

const fs = require('fs');

fs.readFile('./config.json', 'utf8', function(err, data) {
  if (err) {
    console.error('Failed to read file:', err);
    return;
  }
  console.log(data);
});

console.log('This runs immediately — before the file is read');

Notice two things about this pattern:

1. Error-first convention. Node.js callbacks always receive the error as the first argument. If there's no error, it's null. If there is an error, the data argument will be undefined. This is called the "error-first" or "Node.js callback style." It's a convention, not enforced by the language but almost every Node.js built-in and npm package follows it. Always check err before using data.

2. Execution order. The console.log at the bottom runs before the file contents print. The readFile call registers the callback and returns immediately. The callback fires later, when the OS finishes reading. This is the async reordering you saw in the event loop article and it's always the behavior with callbacks.

Callbacks in Practice: A Real Scenario

Say you need to:

1. Read a user's config file

2. Parse it as JSON

3. Use the userId from the config to fetch user data from a database

4. Log the user's name

const fs = require('fs');

fs.readFile('./config.json', 'utf8', function(err, data) {
  if (err) {
    console.error('Could not read config:', err);
    return;
  }

  let config;
  try {
    config = JSON.parse(data);
  } catch (parseErr) {
    console.error('Config is not valid JSON:', parseErr);
    return;
  }

  db.findUser(config.userId, function(err, user) {
    if (err) {
      console.error('Could not fetch user:', err);
      return;
    }

    console.log('User:', user.name);
  });
});

This works. It's perfectly valid Node.js code. But notice what happened to the structure: every async step requires nesting inside the previous one's callback. And we only have three operations. Real applications often have five, eight, ten.

Callback Hell

The nesting problem has a name in the Node.js community: callback hell — sometimes called the "pyramid of doom" because of the shape the indentation makes.

Here's what five sequential async steps looks like with callbacks:

readFile(path, function(err, data) {
  if (err) return handleError(err);
  parseConfig(data, function(err, config) {
    if (err) return handleError(err);
    fetchUser(config.userId, function(err, user) {
      if (err) return handleError(err);
      fetchPermissions(user.id, function(err, perms) {
        if (err) return handleError(err);
        generateReport(user, perms, function(err, report) {
          if (err) return handleError(err);
          console.log(report);
        });
      });
    });
  });
});

This is technically correct but practically painful:

• Every level of nesting adds cognitive load

• Error handling must be repeated at every step

• You can't reuse a step independently — everything is tangled together

• Adding a sixth step means another level of indentation

• Debugging means mentally tracking which variables are in scope at which nesting depth

The code describes what happens in the right order, but it doesn't read that way. You can't scan it top-to-bottom and understand the flow linearly.

You can partially escape callback hell without Promises by naming your callbacks and defining them separately instead of inline. The same five-step sequence above can be written flat if you define each callback as a named function. It's not as ergonomic as Promises, but it's far more readable than nested inline functions. Many legacy Node.js codebases use exactly this pattern.

Promises

A Promise is an object that represents the eventual result of an async operation. Instead of passing a callback into a function, the function returns a Promise object that you work with.

The Promise can be in one of three states:

• Pending — the operation is still in progress

• Fulfilled — the operation succeeded; the result is available

• Rejected — the operation failed; an error is available

Once a Promise settles (fulfills or rejects), it stays that way forever. It won't randomly fulfill again, or change its result. This immutability is one of the things that makes Promises easier to reason about than callbacks.

Here's the same file-read example with a Promise-based API:

const fs = require('fs').promises;

fs.readFile('./config.json', 'utf8')
  .then(function(data) {
    console.log(data);
  })
  .catch(function(err) {
    console.error('Failed to read file:', err);
  });

The .then() runs when the Promise fulfills. The .catch() runs if it rejects. And critically you can chain them.

Chaining

Here's the power move. Instead of nesting, you chain .then() calls in a flat sequence:

const fs = require('fs').promises;

fs.readFile('./config.json', 'utf8')
  .then(data => JSON.parse(data))           // step 2: parse
  .then(config => db.findUser(config.userId)) // step 3: fetch user
  .then(user => {
    console.log('User:', user.name);
  })
  .catch(err => {
    console.error('Something went wrong:', err); // catches errors from ANY step
  });

Compare this to the callback version. It's the same five operations, written flat, with a single .catch() at the end that handles any error from any step.

This is why Promises were adopted so rapidly. The logic flows top to bottom. You can read it and understand the sequence. Error handling is centralized. Each .then() receives the return value of the previous one so passing data from step to step is just a matter of returning it.

Creating Your Own Promises

You won't just consume Promises — you'll need to wrap older callback-based code in them. Here's how:

function readFileAsync(path) {
  return new Promise(function(resolve, reject) {
    fs.readFile(path, 'utf8', function(err, data) {
      if (err) {
        reject(err);    // → Promise rejects with the error
      } else {
        resolve(data);  // → Promise fulfills with the data
      }
    });
  });
}

// Now you can use it with .then()/.catch()
readFileAsync('./data.txt')
  .then(data => console.log(data))
  .catch(err => console.error(err));

The new Promise(executor) pattern: inside the executor function, you call resolve(value) when the work succeeds and reject(error) when it fails. The Promise object carries that result forward.

What most tutorials skip: Node.js ships with util.promisify(), a built-in utility that automatically wraps any error-first callback function into a Promise-returning function. Instead of writing the wrapper above manually:

const { promisify } = require('util');
const readFileAsync = promisify(fs.readFile);

readFileAsync('./data.txt', 'utf8')
  .then(data => console.log(data))
  .catch(err => console.error(err));

One line. Works on any standard Node.js callback-style function. And fs.promises (used earlier) is essentially the entire fs module pre-promisified — it's been available since Node 10 and is the modern default.

Promise.all: Running Multiple Async Operations in Parallel

This is one of the most useful patterns in real applications, and it has no clean equivalent in callback code.

Instead of chaining operations one after another, Promise.all runs multiple async operations simultaneously and waits for all of them:

const userPromise = db.findUser(userId);
const permsPromise = db.fetchPermissions(userId);
const prefsPromise = db.fetchPreferences(userId);

Promise.all([userPromise, permsPromise, prefsPromise])
  .then(([user, perms, prefs]) => {
    console.log(user.name, perms, prefs);
  })
  .catch(err => {
    // If ANY of the three fails, this runs
    console.error(err);
  });

Three DB queries running at the same time. All three results available together when they all finish. If any one fails, the .catch() fires.

Without Promises, achieving this with callbacks requires a manual counter or an async utility library. With Promises, it's one line.

Callbacks were the original Node.js async mechanism — simple, flexible, but painful to chain and error-handle at scale. They gave us "callback hell."

Promises replaced them with an object that represents a future value. .then() chains are flat and readable. .catch() handles errors from any step in the chain. Promise.all enables true parallelism in application code.

Understanding both is non-negotiable. You'll encounter callback-based APIs in older packages and existing codebases. You'll write and consume Promises in any modern Node.js project. And once you've internalized Promises, the final piece — async/await — clicks into place immediately.

Node.js runs your JavaScript on a single thread. One thread means one thing executes at a time. In a traditional server, this would be catastrophic one slow database query and every user would freeze.

Traditional servers solve this by throwing more threads at the problem. A hundred users? A hundred threads. But threads aren't free. Each one consumes memory (typically 1–8MB of stack space), and most of them spend the majority of their time doing nothing useful waiting. Waiting for a database to respond. Waiting for a file to load. Waiting for an API to return. All that waiting, and all that memory, and yet no actual work is happening.

Node.js takes a different position: instead of adding more threads, use the one thread more intelligently. Never let it wait. Whenever it would have to stop and wait for something, hand that something off and go do other work. Come back when the result is ready.

The mechanism that makes "come back when it's ready" possible is the event loop.

Event Loop

Here's the simplest mental model: the event loop is a task manager that runs in a continuous cycle.

It watches two things:

1. The call stack — what's currently executing

2. The task queue — what's finished and ready to be processed next

Its job is simple whenever the call stack is empty, take the next task from the queue and put it on the stack.

That's it. The whole mechanism boils down to that one rule. Everything else callbacks, promises, timers is just a way of getting tasks onto the queue at the right time.

The Call Stack

The call stack is where JavaScript execution happens. When you call a function, it gets pushed onto the stack. When it returns, it gets popped off.

function greet(name) {
  return `Hello, ${name}`;
}

function main() {
  const message = greet("Node.js");
  console.log(message);
}

main();

→ main() pushed onto stack
  → greet() pushed onto stack
  ← greet() returns, popped off stack
  → console.log() pushed onto stack
  ← console.log() completes, popped off stack
← main() returns, popped off stack
Stack is empty.

JavaScript can only run one thing at a time. While a function is on the stack, nothing else runs. This is why blocking code is dangerous it keeps something on the stack for a long time, preventing anything else from ever getting a turn.

The Task Queue

When you kick off an async operation a database query, a file read, a timer Node.js registers a callback for it and immediately returns. Your synchronous code keeps running. The stack keeps moving.

Meanwhile, the I/O operation is happening elsewhere (more on this below). When it completes, its result and callback don't get shoved directly onto the call stack. Instead, they get placed into the task queue a waiting line.

The event loop watches this queue. The moment the call stack is empty, it picks up the next item from the queue and pushes it onto the stack. The callback runs. Gets popped off. The event loop checks for more items. The cycle continues.

console.log("first");

setTimeout(() => {
  console.log("third");  // callback queued, runs after stack clears
}, 0);

console.log("second");

first
second
third

Even with a 0ms timer, "third" prints last. The setTimeout callback goes to the task queue. The synchronous code — console.log("second") — stays on the stack and runs first. Only after the stack is completely empty does the event loop pull the callback from the queue.

This surprises developers the first time. The timer delay is not a promise of when the callback runs. It's a minimum time before it's eligible to run. The event loop decides the actual execution time.

Timers vs I/O Callbacks

Here's something most introductory articles skip: not all async callbacks are treated equally in the task queue.

Node.js actually has multiple queues with different priorities:

Timers (setTimeout, setInterval) — checked first each cycle. A callback becomes eligible after the specified delay has passed, but runs at the start of the next loop tick once eligible.

I/O callbacks — responses from file reads, network requests, database queries. These sit in a separate pool and are processed after timers.

setImmediate — runs after I/O callbacks in the current cycle, before the next timer check. This is a uniquely Node.js feature with no browser equivalent.

process.nextTick — this one is special. It runs before the event loop moves to the next phase, no matter what. Immediately after the current operation finishes, before any I/O or timers. Developers use it to defer work until the current call stack unwinds, but still within "this tick."

setTimeout(function fun1() {
  console.log("timer")
},0);

setImmediate(function fun2() {
  console.log("immediate")
});

process.nextTick(function fun3() {
  console.log("next tick")
});

console.log("synchronous");

synchronous
nextTick
timer (or immediate — order between these two can vary)
immediate (or timer)

process.nextTick always fires before any I/O or timers, even before setImmediate. This makes it useful for ensuring something happens after the current operation but before any async work. Use it carefully stacking too many nextTick calls can starve the I/O queue.

Delegating to Background Workers

Here's the part the "single-threaded" framing obscures: when Node.js delegates I/O work, that work doesn't vanish into thin air. It goes to libuv — the C library underneath Node.js that provides the event loop and a worker thread pool.

When you call fs.readFile(), Node hands the actual disk read to libuv. Libuv's thread pool (4 threads by default) handles the operation. When it finishes, libuv places the callback on the event loop's I/O queue. The event loop picks it up and runs your callback on the JavaScript thread.

Your JavaScript never sees the worker threads. From your perspective, you called a function, moved on, and later your callback ran with the result. The multi-threading is invisible.

This is why Node.js can claim to be "single-threaded" while also doing actual parallel I/O work. The single thread is your thread the JavaScript execution context. The libuv thread pool is infrastructure, below the JS layer.

The developers who truly understand the event loop don't just write async code they write async code that keeps the loop running smoothly. That's the difference between a Node.js server that handles 10,000 concurrent connections and one that mysteriously crawls under load.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

Who better know than us, what blocking means. Sad story...
Whether it’s your ex-girlfriend or your Node.js server, being blocked fundamentally ruins everyone's day.

Symptoms of Blocking

• Timer Freeze.

• Callbacks waiting..

Non Blocking

Opposite of blocking. It's smooth process.

Example

Blocking (synchronous)

const fs = require('fs');

console.log('Before read');

const data = fs.readFileSync('./data.txt', 'utf8'); // ← thread stops here
console.log(data);

console.log('After read'); 

Before read
[file contents]
After read

The entire thread pauses at readFileSync. If this file is on a slow disk, or it's a large file, your server is frozen for that entire duration. Every other user waiting on your server waits too.

Non-blocking (asynchronous) file read:

const fs = require('fs');

console.log('Before read');

fs.readFile('./data.txt', 'utf8', (err, data) => {
  if (err) throw err;
  console.log(data); // ← runs when the file is done reading
});

console.log('After read'); // ← runs IMMEDIATELY, doesn't wait

Before read
After read
[file contents]

This confuses developers the first time they see it. "After read" prints before the file contents? Yes. Because the file read is happening in the background. The callback fires later, when the OS has finished reading. The thread kept running after registering the callback.

This reordering of output is the most reliable indicator that code is truly non-blocking.

Why Blocking Slows Servers:

Let's say your server handles a request that reads a 10ms file. Ten milliseconds sounds nothing. But under load, it compounds fast.

With blocking code:

User A request arrives  → file read starts → [10ms frozen] → response sent
User B request arrives  → queued, waiting while A is frozen
User C request arrives  → queued, waiting while A is frozen
...

If 100 users hit this endpoint simultaneously and each file read takes 10ms, the last user waits 1000ms — 1 full second — not because their file read took that long, but because they're waiting for 99 people ahead of them to get their turn on a frozen thread.

With non-blocking code:

User A request arrives → readFile registered → callback queued → thread free
User B request arrives → readFile registered → callback queued → thread free
User C request arrives → readFile registered → callback queued → thread free
...
All file reads happen in parallel at OS level
All callbacks fire roughly at t=10ms
All responses sent near-simultaneously

Same 100 users. Total wait time: ~10ms for everyone. Not 1000ms. The non-blocking version is 100x faster in this scenario — not because the disk ran faster, but because the thread stopped waiting.

What "Async" Means in Practice

You'll see "async" used interchangeably with "non-blocking" in the Node.js world. They're not quite identical, but in practice the distinction rarely matters for application code.

Node.js gives you three ways to write non-blocking code, and they've evolved over time:

Callbacks (original Node.js style)

fs.readFile('./file.txt', 'utf8', (err, data) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(data);
});

Promises

const fs = require('fs').promises;

fs.readFile('./file.txt', 'utf8')
  .then(data => console.log(data))
  .catch(err => console.error(err));

Async/Await (modern Node.js)

const fs = require('fs').promises;

async function readMyFile() {
  try {
    const data = await fs.readFile('./file.txt', 'utf8');
    console.log(data);
  } catch (err) {
    console.error(err);
  }
}

readMyFile();

Summary

Blocking code freezes your entire server. Non-blocking code keeps your server responsive even under load. This isn't just good practice in Node.js it's the foundational contract that makes the single-threaded model work.

The Sync functions exist. Use them only when you're not handling concurrent requests (scripts, startup, CLI tools). In a running server, they're almost always a bug waiting to manifest under load.

Async/await is the cleanest way to write non-blocking code today. Under the hood it's still callbacks and promises but the syntax keeps your code readable while the event loop stays unblocked.

Write non-blocking code, and Node.js rewards you with performance that surprises people who've only ever used thread-per-request servers.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

How can a single thread handle thousands of simultaneous users?
That's a fair question and the answer changes the way you think about concurrent systems.

What a Thread Actually Is ?

Before we can talk about single-threaded, we need to be clear on what a thread is.

A process is a running program. When you start Node.js, your OS creates a process for it memory space, file handles, all of it. That process is isolated. Other processes can't mess with its memory directly.

A thread lives inside a process. It's a unit of execution a sequence of instructions the CPU can run. One process can have many threads, all sharing the same memory space, all potentially running at the same time on different CPU cores.

Traditional web servers like Apache create a new thread (or even a new process) per incoming request.

One user connects → one thread. A hundred users → a hundred threads. That model is simple and intuitive.

Node.js says one thread. For everything.

That sounds like a weakness. Here's why it isn't at least not for most web applications.

Event Loop

The single thread in Node.js isn't doing what you think it's doing most of the time. It's not running your code nonstop. It's mostly checking.

The event loop runs in a continuous cycle. Each pass through the loop (called a "tick") looks like this:

1. Are there any timers that have expired? Run their callbacks.

2. Are there any pending I/O callbacks ready? Run them.

3. Are there any setImmediate callbacks queued? Run them.

4. Any close events? Handle them.

5. Nothing ready? Check again.

The entire secret of Node.js performance lives in step 5. When there's nothing ready, the thread doesn't spin-wait burning CPU. It goes into an efficient waiting state, and the OS wakes it up the moment something is ready.

This is called I/O multiplexing and Node.js gets it essentially for free by sitting on top of libuv, which uses epoll on Linux, kqueue on macOS, and IOCP on Windows under the hood.

These are OS-level mechanisms specifically designed for efficient I/O monitoring.

What Actually Happens When Multiple Requests Hit Node.js

Let's walk through three simultaneous requests arriving at a Node.js server.

Request A arrives. Your route handler fires. It calls db.query(...) with a callback. Node registers that callback and hands the DB work off to libuv. Your handler returns. Control goes back to the event loop.

Microseconds later, Request B arrives. Same thing handler fires, calls an API, callback registered, handler returns. Event loop keeps spinning.

Immediately after, Request C arrives. Maybe this one doesn't need I/O it just reads from an in-memory cache and returns a response. The handler runs to completion in a single tick. Response sent. Done.

Now the event loop keeps checking. Eventually, the DB responds for Request A. The callback fires. You format the data, call res.send(). Done. Then the API responds for Request B. Its callback fires. Response sent.

From the outside from the perspective of the three clients who connected all three requests were handled at the same time. From Node's perspective, there was always only one thing running at any given instant. But because the expensive work was delegated, the thread was almost never actually waiting.

Timeline (single thread):

t=0ms   Request A arrives → DB query fired → handler exits → event loop
t=1ms   Request B arrives → API call fired → handler exits → event loop
t=2ms   Request C arrives → cache lookup → response sent → event loop
t=45ms  DB responds → Request A callback → response sent
t=120ms API responds → Request B callback → response sent

One thread. Three requests handled. No waiting.

Thread vs Process: One More Thing Worth Knowing

Threads within a process share memory. This is efficient (no copying data) but risky one thread can corrupt another's memory. Debugging race conditions in multi-threaded apps is notoriously painful.

Processes have separate memory. Safer, but communicating between them requires explicit mechanisms (IPC, message passing, shared files).

Node.js sidesteps the thread safety problem entirely by using one JS thread. No shared mutable state between concurrent handlers. No race conditions in your JS code.

When you do want parallelism in Node.js (for CPU-heavy work), you use Worker Threads or the Cluster module (spawns multiple Node processes, each with their own event loop). These are explicit, opt-in parallelism.

Why Node.js Scales So Well (The Actual Reason)

It has a very low per-connection cost.

In a thread-per-request model, each connection holds a thread. Threads typically consume between 1MB and 8MB of stack memory by default. Ten thousand concurrent connections = 10–80 GB of memory just for stack space. Before you've done any actual work.

In Node.js, an open connection waiting for data is just an entry in the event loop — a file descriptor and a callback reference. A few hundred bytes. Ten thousand concurrent open connections might cost you 50MB total.

This is the real reason LinkedIn went from 30 servers to 3 with Node.js. It wasn't that Node's code ran faster. It's that each idle connection cost almost nothing, so one machine could hold far more of them.

The technical term is C10K problem handling ten thousand concurrent connections. This was a serious challenge in the early 2000s. Node.js's architecture basically solves it by default.

Actual Limitation

If you block the event loop, everything stops.

Not slows down. Stops. Every single client waiting on your server will be frozen until your blocking code finishes, because there's only one thread.

This can happen with:

• A for loop iterating over 10 million items

• Synchronous file reads (fs.readFileSync) in a hot path

• Heavy JSON parsing of a massive payload

• crypto.pbkdf2Sync with many iterations

• Any CPU-intensive computation running to completion without yielding

app.get('/danger', (req, res) => {
  let sum = 0;
  for (let i = 0; i < 1_000_000_000; i++) {
    sum += i; // 1 billion iterations on the JS thread
  }
  res.send({ sum }); // every other user waited for this
});

In a multi-threaded server, this would only block one thread. In Node.js, it blocks everything.

The fix: offload CPU work to Worker Threads, or use setImmediate/process.nextTick to yield control back to the event loop between chunks of work. But the key lesson is: Node's single-threaded model rewards I/O-heavy workloads and punishes CPU-heavy ones.

Know this going in. Build accordingly.

Moral of the Story

Single-threaded doesn't mean limited. It means focused. Node.js made a deliberate bet: most web applications are I/O-bound, not CPU-bound. If that's true for your application and it usually is then a single well-managed thread with non-blocking I/O outperforms a pool of threads most of which are just waiting.

Understand the event loop. Respect the single thread. Don't block it with CPU work. That's the entire contract.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

In Nodejs there are two important things to note down.

• V8

• Libuv

Here V8 (Chrome's JS engine) handles JavaScript execution. But the thing that makes Node.js fast for I/O isn't V8 it's libuv, a C library that powers the event loop, thread pool, and async I/O. When Node reads a file or makes a network call, libuv handles it at the OS level while your JS thread stays free.

What Nodejs offers

Blocking vs non-blocking I/O

Traditional servers handle one request per thread. While a thread waits for a database result, it just sits there blocked, doing nothing, burning memory. Node.js flips this instead of waiting, it registers a callback and moves on to the next request. When the data is ready, it circles back.

Event-driven architecture

Node.js is built around a simple idea: things happen, and you react to them. You don't sit and check "is the file read yet?" in a loop. You say "when the file is done, call this function" and walk away. That's the event-driven model.

Under the hood, the event loop runs in phases each responsible for a different kind of event. Timers fire in the timers phase. Completed I/O callbacks fire in the poll phase. setImmediate() runs in the check phase. Understanding this order stops a whole class of subtle bugs.

Single-threaded but not what you think

Single-threaded sounds like a weakness. It isn't. Node.js has one JS thread, but that thread is almost never the bottleneck if you understand JS properly or just follow my blogs.

Database queries, file reads, and HTTP calls don't run on your JS thread libuv offloads them to the OS or an internal thread pool. Your JS thread just dispatches work and handles results.

Concurrency vs parallelism

Parallelism is two cooks working simultaneously on two burners. Concurrency is one cook managing two pots starting one, monitoring both, stirring each when needed. Node.js is the one cook. Traditional multi-threaded servers are the two cooks. For I/O-heavy work, the one skilled cook wins less overhead, less coordination, less memory per request in flight.

When you genuinely need parallelism heavy encryption, image processing, ML inference use worker_threads. Unlike the cluster module (which spawns whole processes), Worker Threads share memory via SharedArrayBuffer. Your main thread stays free. Most devs still don't reach for it.

If you are building something on internet where to use Nodejs

Remember one thing no technology is the right for everything. Use it where it shines.

• REST APIs and GraphQL servers

• Real-time apps like chat, live feeds, collaboration

• Streaming data pipelines

• Avoid for CPU-heavy computation

Real Companies Betting on Node.js

Some of the highest-traffic systems in the world run on Node.js:

• Netflix moved their frontend server layer to Node.js and cut startup time by over 70%. They serve over 200 million users. LinkedIn switched from Ruby on Rails to Node.js and went from running 30 servers down to 3 handling double the traffic.

• Uber built their dispatch and notification systems on Node.js. The real-time nature of ride-hailing is a perfect fit for event-driven architecture.

• PayPal found Node.js handled double the requests per second compared to their Java solution, with 35% lower response times.

• Trello, Walmart, NASA, Medium all use Node.js in significant parts of their infrastructure. These aren't companies that chose Node.js because it was trendy.

Here's something that doesn't show up in benchmarks: Node.js shares JavaScript between your frontend and backend. Your team writes one language. You can share validation logic, type definitions, utility functions between client and server.
This isn't a Node.js performance feature. But it's a team performance feature. In organizations running at scale, the reduction in context-switching developers not needing to flip between Python/Java on the server and JavaScript on the client is genuinely significant.

I hope you get to know something valuable from the article.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

You already know JavaScript. You know it runs in the browser. The entire purpose was simple make web pages respond to user actions. But have you ever think why does it run in the browser at all?

Because something inside the browser is reading your JavaScript line by line and telling the computer what to do. That something is called a runtime engine. In Chrome, it's called V8. In Firefox, it's SpiderMonkey. Think of it as a translator JavaScript speaks, the engine listens, and the computer acts.

Now here's the problem. That translator only lived inside the browser. You couldn't take it outside. You couldn't run JavaScript on a server, talk to a database, read files on disk, or build an API. JavaScript was essentially trapped.

Ryan Dahl looked at this in 2009 and said what if we break it out? He took V8 out of Chrome and wrapped it with something extra. That wrapper became Node.js.

How Nodejs was build?

Ryan noticed that Google's V8 engine inside Chrome was fast, open-source, and not tied to the browser in any fundamental way. It was just a C++ library that could compile and execute JavaScript. So he pulled it out.

But V8 alone was only half the answer. He needed to give it hands. He wrapped V8 with a C library called libuv, which was built specifically to handle I/O operations file system calls, network connections, DNS lookups across different operating systems in a non-blocking way.

That combination is the entire foundation of Node.js.

V8

You don't need to understand V8 deeply to use Node.js. But a high-level picture helps.

V8 job is to take JavaScript code and turn it into something the CPU can actually. V8 reads your code, figures out what it's doing, and translates it into native machine code on the fly. This is called JIT(Just in time) compilation.

The result is that JavaScript runs fast compared to what anyone expected from a scripting language. V8 also handles memory management for you allocating it when you create objects, cleaning it up when you're done with them, through a process called garbage collection.

When Node.js runs your code, V8 is the one actually executing it. Node.js just sets the stage.

Event Drive Architecture

Let's use an analogy. Imagine a restaurant.

Traditional servers like PHP or Java with thread-per-request models work like a waiter who takes your order and then stands next to your table, doing absolutely nothing, until your food comes out of the kitchen. During that entire waiting time, that waiter is occupied. If 1,000 customers walk in, you need 1,000 waiters just standing around.

Node.js works like a smart waiter. They take your order, walk it to the kitchen, and immediately go take the next table's order. When the kitchen shouts "order up!", the waiter gets notified and delivers it. One waiter can handle 100 tables because they're never standing around waiting.

That's event-driven, non-blocking I/O. Instead of stopping everything while waiting for a database response or a file read, Node.js registers a callback and moves on. When the result is ready, it comes back via the event loop.

This is the reason Node.js can handle tens of thousands of concurrent connections on a single server process while traditional multi-threaded servers would be crushed under that load. Not because Node.js is faster at computation it's often not. But because it never idles.

Now here's how the Node.js runtime architecture actually fits together:

General use cases

• REST APIs and GraphQL Backends

• Streaming applications

• Serverless functions

• Internet of Things (IoT)

I hope you get to know something valuable from the article.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

A nested array (or a multi-dimensional array) is simply an array that contains other arrays as its elements.

Think of a standard array as a single-story egg carton. A nested array is more like a shipping crate filled with smaller boxes, some of which might contain even smaller boxes.

Example: const nested = [1, [2, 3], [[4, 5], 6]];

In the example above, 1 is at the top level, but 4 and 5 are buried three levels deep.

Why Bother Flattening?

Flattening is the process of reducing the dimensionality of an array. We do this because:

• Easier Iteration: It’s much simpler to run a single .map() or .forEach() on a flat list than to write recursive loops for every level.

• Data Consistency: Many UI components (like dropdowns or tables) expect a simple, linear array of items.

• Searchability: Finding a specific value is faster when you don't have to check every "sub-box."

Transformation

When we "flatten," we are essentially taking every element from the inner arrays and pushing them into a new, single-level array while maintaining their original order.

How to Flatten Arrays:

flat()

Introduced in ES2019, the .flat() method is the gold standard. By default, it flattens one level deep, but you can pass a depth or use Infinity to go all the way.

const multidimensional = [1, [2, [3, [4]]]];

console.log(multidimensional.flat()); // [1, 2, [3, [4]]]

console.log(multidimensional.flat(Infinity)); // [1, 2, 3, 4]

reduce() and concat()

Before .flat() existed, this was the go-to manual method. It helps you understand the logic of the transformation: "Take the accumulator, and merge it with the current item."

const nested = [1, [2, 3], [4]];
const flat = nested.reduce((acc, val) => acc.concat(val), []);

toString() and split()

If your array only contains numbers or strings, you can convert the whole thing to a string (which removes brackets) and then split it back.

Note: Use this with caution, as it turns everything into strings!

When you see a nested structure, just ask yourself about the depth.

• Is it always one level deep? Use [].concat(...arr).

• Is the depth unknown? Use .flat(Infinity).

• Are you on an older environment (like legacy IE)? You'll need a recursive polyfill.

Flattening isn't just about making arrays shorter; it’s about making your data usable.

Most of the time those assumptions hold. Then they don't and what happens next is entirely up to you.

JavaScript gives you a system for managing failures without letting them crash the whole program. Understanding it isn't just about catching errors. It's about writing code that fails gracefully code that tells you exactly what went wrong, cleans up after itself, and gives the user something useful instead of a blank screen or a frozen UI.

What errors actually are in JavaScript

When JavaScript encounters something it can't handle dividing by something illegal, calling a method on undefined, trying to parse malformed JSON it creates an Error object and throws it. This throw unwinds the call stack, skipping everything below it, until something catches it or it reaches the top level and crashes your program.

const user = null;
console.log(user.name); // TypeError: Cannot read properties of null

That TypeError is a real object. It has a message (what went wrong), a name (the type of error), and a stack (the trace of function calls that led here). JavaScript creates it, throws it, and your program stops unless something is listening for it.

JavaScript has several built-in error types:

• TypeError (wrong type)

• ReferenceError (variable doesn't exist)

• SyntaxError (invalid code)

• RangeError (value out of bounds).

They all inherit from the base Error class.

The try/catch block

try/catch lets you put risky code in a guarded zone. If anything throws inside try, execution jumps immediately to catch and you decide what to do with the error instead of letting it crash your program.

try {
  const data = JSON.parse("this is not valid json");
  console.log(data);
} catch (error) {
  console.error("Failed to parse:", error.message);
}

// Failed to parse: Unexpected token 'h', "this is n"... is not valid JSON

Without try/catch, that JSON.parse throws a SyntaxError and everything stops. With it, you catch the error, log it clearly, and your program keeps running.

The error object passed to catch is whatever was thrown. It has two properties you'll use constantly:

try {
  undeclaredVariable;
} catch (error) {
  console.log(error.name);    // "ReferenceError"
  console.log(error.message); // "undeclaredVariable is not defined"
}

The finally block

finally is a block that runs no matter what whether the try succeeded, whether the catch triggered, whether an error was re-thrown. It always runs.

function loadData() {
  showSpinner();

  try {
    const result = fetchSomething();
    display(result);
  } catch (error) {
    showErrorMessage(error.message);
  } finally {
    hideSpinner(); // always runs — success or failure
  }
}

hideSpinner() runs whether fetchSomething succeeded or crashed. Without finally, you'd have to call hideSpinner() in both the try and the catch, duplicating cleanup logic. finally exists precisely for this: teardown, cleanup, resource release anything that must happen regardless of outcome.

Here's the full execution order laid out clearly:

Throwing custom errors

JavaScript lets you throw anything but throwing a proper Error object (or a subclass of it) is best practice because it gives you a stack trace and a message.

function divide(a, b) {
  if (b === 0) {
    throw new Error("Cannot divide by zero");
  }
  return a / b;
}

try {
  const result = divide(10, 0);
} catch (error) {
  console.error(error.message); // "Cannot divide by zero"
}

You're not waiting for JavaScript to fail you're proactively saying "this situation is invalid" and throwing your own error. The caller's catch block handles it just like any built-in error.

For larger applications, creating custom error classes makes your error handling more precise you can catch specific error types and respond differently:

class ValidationError extends Error {
  constructor(message, field) {
    super(message);
    this.name = "ValidationError";
    this.field = field;
  }
}

class NetworkError extends Error {
  constructor(message, statusCode) {
    super(message);
    this.name = "NetworkError";
    this.statusCode = statusCode;
  }
}

function processForm(data) {
  if (!data.email.includes("@")) {
    throw new ValidationError("Invalid email address", "email");
  }
}

try {
  processForm({ email: "notanemail" });
} catch (error) {
  if (error instanceof ValidationError) {
    console.log(`Validation failed on field: ${error.field}`);
    highlightField(error.field);
  } else if (error instanceof NetworkError) {
    console.log(`Network failed with status: ${error.statusCode}`);
    showRetryButton();
  } else {
    console.error("Unexpected error:", error);
  }
}

instanceof lets you branch on error type different failures get different responses instead of one generic "something went wrong" message.

Error handling with async/await

try/catch works exactly the same way with async/await. Rejected promises become catchable errors:

async function loadUserData(id) {
  try {
    const response = await fetch(`/api/users/${id}`);

    if (!response.ok) {
      throw new NetworkError("Request failed", response.status);
    }

    const user = await response.json();
    return user;
  } catch (error) {
    if (error instanceof NetworkError) {
      console.error(`HTTP \({error.statusCode}: \){error.message}`);
    } else {
      console.error("Unexpected error:", error.message);
    }
    return null;
  } finally {
    hideLoadingIndicator();
  }
}

Same underlying problem. Completely different user experience. Error handling is how you translate a technical failure into a useful human message.

A pattern worth building into any serious application:

async function safeLoadDashboard() {
  try {
    const [user, stats, notifications] = await Promise.all([
      fetchUser(),
      fetchStats(),
      fetchNotifications()
    ]);

    renderDashboard(user, stats, notifications);
  } catch (error) {
    console.error("Dashboard load failed:", error);
    renderErrorState("Unable to load dashboard. Please refresh.");
  } finally {
    hideGlobalSpinner();
  }
}

If any of the three fetches fail, catch handles it.

getUser(userId)
  .then(user => {
    return getOrders(user.id);
  })
  .then(orders => {
    return getProduct(orders[0].productId);
  })
  .then(product => {
    console.log(product.name);
  })
  .catch(err => {
    console.error(err);
  });

It works. But it reads sideways. Each .then() is a new indentation, a new callback, a new mental context to hold. You can't easily share variables between steps without hoisting them outside the chain. Error handling applies to the whole chain but it's tacked on at the end, invisible until something breaks.

async/await was introduced in ES2017 to fix exactly this. Not by replacing promises by giving you a way to write promise-based code that looks and reads like regular synchronous code.

Syntactic sugar over promises

The first thing to understand is that async/await is not a new async system. It's a new syntax for working with promises. Under the hood, every async function returns a promise. Every await pauses execution and waits for a promise to resolve. No new engine magic just a cleaner way to write what you were already doing.

Think of it this way. Promises gave you a contract: "this will eventually have a value." async/await gives you a way to write code as if that value is already there, and JavaScript handles the waiting behind the scenes.

The async keyword

Putting async before a function declaration does one thing: it makes that function always return a promise. Even if you return a plain value, JavaScript automatically wraps it in a resolved promise.

async function greet() {
  return "Hello!";
}

greet().then(msg => console.log(msg)); // "Hello!"

You returned a string. But because the function is async, the caller receives a promise that resolves to that string. That's the contract.

You can use async with any function style:

// function declaration
async function fetchData() { ... }

// arrow function
const fetchData = async () => { ... }

// method in an object
const api = {
  async getUser() { ... }
};

The await keyword

await can only live inside an async function. It pauses that function's execution until the promise it's waiting on resolves then hands you the resolved value directly.

async function loadUser() {
  const user = await getUser(1); // pauses here until resolved
  console.log(user.name);        // then continues
}

Without await, getUser(1) returns a promise object not the user. With await, you get the user directly, as if the function was synchronous. The pause is real but it's non-blocking: while this function is waiting, JavaScript keeps running everything else.

Here's what that promise chain from earlier looks like rewritten with async/await:

async function loadProductFromUser(userId) {
  const user    = await getUser(userId);
  const orders  = await getOrders(user.id);
  const product = await getProduct(orders[0].productId);

  console.log(product.name);
}

Top to bottom. Left to right. Each line waits for the previous one before moving on. No callbacks. No indentation staircase. It reads like a recipe: get the user, get their orders, get the first product, show its name.

Here's the execution flow when you call an async function:

JavaScript is single-threaded. It runs one piece of code at a time, which means when you perform a slow operation, like fetching data from a server, reading a file, or waiting for a timer.

The entire thread can't afford to stop and wait. Instead, JavaScript uses an event-driven, asynchronous model: kick off the work, continue with other things, and handle the result when it's ready.

The earliest pattern for this was the callback you pass a function to another function, and that function calls yours back when the work completes. This works, but it breaks down fast. Imagine fetching a user, then fetching their posts, then fetching comments on each post. You end up nesting callbacks inside callbacks inside callbacks code that fans rightward across the screen, where error handling is duplicated at every level and the logical sequence of operations is buried in indentation. Developers called this callback hell.

Promises were introduced to solve this. A promise represents a value that isn't available yet, but will be in the future or won't arrive at all because something went wrong. Instead of passing callbacks into every function, you work with an object that carries the result of an asynchronous operation, with a clean, chainable API for handling success and failure.

Promise states

Every promise lives in exactly one of three states at any given moment:

Pending: The operation is in progress. No result yet. This is the starting state.

Fulfilled: The operation completed successfully. The promise now holds the resolved value.

Rejected: The operation failed. The promise now holds a reason, typically an Error object explaining what went wrong.

The key rule: once a promise transitions out of pending, it never changes again. A fulfilled promise stays fulfilled forever. A rejected promise stays rejected. This predictability is one of the things that makes promises much easier to reason about than raw callbacks.

Creating a promise

You create a promise by calling the Promise constructor and passing it an executor, a function that receives two callbacks: resolve and reject. You call one of them when the async work finishes.

const fetchUser = new Promise((resolve, reject) => {
  setTimeout(() => {
    const success = true; // pretend this comes from a network call

    if (success) {
      resolve({ id: 1, name: 'Priya' }); // fulfills the promise
    } else {
      reject(new Error('User not found')); // rejects the promise
    }
  }, 1000);
});

The executor runs immediately when new Promise(...) is called. The resolve and reject callbacks settle the promise and trigger any handlers that have been attached.

Handling success and failure

Once you have a promise, you react to its outcome using .then(), .catch(), and .finally():

fetchUser
  .then((user) => {
    console.log('Got user:', user.name); // runs if resolved
  })
  .catch((error) => {
    console.error('Failed:', error.message); // runs if rejected
  })
  .finally(() => {
    console.log('Done loading'); // always runs
  });

.then() receives the resolved value. .catch() receives the rejection reason. .finally() receives nothing.

It's purely for cleanup (hiding a loading spinner, closing a connection). A critical point: .finally() doesn't consume the promise value. Whatever the promise settled with flows through .finally() unchanged to any subsequent handler.

Callbacks vs promises

Let's look at a concrete comparison. Three sequential async operations: load a user, then load their orders, then calculate their total spend.

loadUser(userId, function(err, user) {
  if (err) return handleError(err);
  loadOrders(user.id, function(err, orders) {
    if (err) return handleError(err);
    calculateSpend(orders, function(err, total) {
      if (err) return handleError(err);
      console.log('Total spend:', total);
    });
  });
});

With promises:

loadUser(userId)
  .then((user) => loadOrders(user.id))
  .then((orders) => calculateSpend(orders))
  .then((total) => console.log('Total spend:', total))
  .catch(handleError);

The logic is identical. But the promise version reads like a linear sequence of steps because it is one. Error handling is consolidated in a single .catch() at the end rather than duplicated at every level.

Promise chaining

Promise chaining is possible because .then() always returns a new promise. Whatever value you return from inside a .then() callback becomes the resolved value of that new promise, which the next .then() in the chain receives.

fetchUser(1)
  .then((user) => {
    return fetchPostsByUser(user.id); // returns another promise
  })
  .then((posts) => {
    return posts.filter((p) => p.published); // returns a plain array
  })
  .then((publishedPosts) => {
    console.log(publishedPosts.length, 'published posts');
  })
  .catch((err) => {
    // any rejection in the chain above lands here
    console.error('Something went wrong:', err.message);
  });

The chain automatically unwraps promises: if you return a promise from inside .then(), the next .then() waits for that inner promise to settle before it fires. If you return a plain value, it's wrapped into a resolved promise automatically. This is the mechanism that makes chaining work seamlessly for both sync and async return values.

A note on async/await

Modern JavaScript introduced async/await as syntax sugar built directly on top of promises. An async function always returns a promise, and await pauses execution inside that function until a promise settles without blocking the thread. It makes promise-based code look synchronous:

async function loadDashboard(userId) {
  try {
    const user = await fetchUser(userId);
    const orders = await fetchOrders(user.id);
    const total = await calculateSpend(orders);
    console.log('Total spend:', total);
  } catch (err) {
    console.error('Failed:', err.message);
  }
}

This is the same sequence as the promise chain above, just written differently. Understanding promises deeply states, .then(), .catch(), chaining is essential before async/await makes sense, because under the hood, that's exactly what it's doing.

In JavaScript, strings come with a powerful set of built-in methods functions attached to every string value that let you search, transform, slice, and inspect text. When you call "hello".toUpperCase(), you're using a method that JavaScript's engine provides automatically. These aren't magic; they're functions defined on String.prototype, the shared blueprint that every string inherits from.

The key insight for interview preparation is this: knowing what a method does isn't enough. Interviewers want to know how it works and whether you could rebuild it from scratch. That's where polyfills come in.

Why developers write polyfills

A polyfill is a piece of code that implements a feature that the current runtime doesn't support or that you're implementing yourself to demonstrate understanding. When a new string method lands in the JavaScript specification, older browsers don't have it. Developers write polyfills to bridge that gap, attaching the implementation directly to String.prototype before the browser's built-in version would run.

But in interviews, polyfills serve a different purpose. They force you to reason about the logic behind familiar tools. Can you write trim() without calling trim()? Can you implement includes() using only index-based access? These questions reveal how deeply you understand strings as sequences of characters.

Here's how the string processing model works under the hood:

One important detail the diagram highlights: strings in JavaScript are immutable. No string method ever modifies the original string.

Implementing simple string utilities as polyfills

Before writing a polyfill, always check if the method already exists. This prevents overwriting the native implementation in environments that support it.

if (!String.prototype.customTrim) {
  String.prototype.customTrim = function () {
    // `this` refers to the string value the method is called on
    let start = 0;
    let end = this.length - 1;

    while (start <= end && this[start] === ' ') start++;
    while (end >= start && this[end] === ' ') end--;

    return this.slice(start, end + 1);
  };
}

The logic here is a two-pointer approach.

Advance from the left until you hit a non-space character, retreat from the right until you hit a non-space character, then slice out the middle. This is exactly the kind of thinking interviews test: can you express a simple operation in terms of indices and comparisons?

Here's how the polyfill checking behavior works visually:

Common interview string methods to implement

includes(searchStr)

The built-in method checks whether a substring exists anywhere in the string, returning true or false. The polyfill uses a sliding window: at every position, compare the next searchStr.length characters against the target.

String.prototype.myIncludes = function (searchStr) {
  const str = String(this);
  const search = String(searchStr);

  if (search.length === 0) return true;
  if (search.length > str.length) return false;

  for (let i = 0; i <= str.length - search.length; i++) {
    if (str.slice(i, i + search.length) === search) return true;
  }
  return false;
};

Note the edge cases: an empty search string always returns true (this matches the spec), and a search string longer than the source immediately returns false.

repeat(count)

This builds a new string by concatenating the original count times.

String.prototype.myRepeat = function (count) {
  const n = Math.floor(count);
  if (n < 0 || n === Infinity) throw new RangeError('Invalid count value');
  let result = '';
  for (let i = 0; i < n; i++) result += this;
  return result;
};

startsWith(prefix) and endsWith(suffix)

These are slice comparisons at fixed positions:

String.prototype.myStartsWith = function (prefix) {
  return this.slice(0, prefix.length) === prefix;
};

String.prototype.myEndsWith = function (suffix) {
  if (suffix.length === 0) return true;
  return this.slice(-suffix.length) === suffix;
};

padStart(targetLength, padStr) and padEnd()

Padding methods fill the string until it reaches a desired length:

String.prototype.myPadStart = function (targetLength, padStr = ' ') {
  const str = String(this);
  if (str.length >= targetLength) return str;
  const padNeeded = targetLength - str.length;
  let padding = '';
  while (padding.length < padNeeded) padding += padStr;
  return padding.slice(0, padNeeded) + str;
};