DEV Community: Akash Kumar

How ChatGPT Understands Your Questions?

Akash Kumar — Wed, 01 Jul 2026 13:59:49 +0000

You type a question into ChatGPT. Half a second later, a surprisingly relevant, well-formed answer starts streaming back.

It feels like magic. It isn't. It's math — a lot of math, wrapped in a system that's been engineered to feel conversational.

In this post, we'll pull back the curtain and walk through exactly what happens between the moment you hit "Enter" and the moment a response appears — from raw text, to numbers, to tokens, to Transformers.

You: "What's the capital of France?"
                 │
                 ▼
        [ ...this article... ]
                 │
                 ▼
ChatGPT: "The capital of France is Paris."

Let's open the black box.

1. What is an LLM?

LLM stands for Large Language Model.

Strip away the buzzwords, and an LLM is a program trained on enormous amounts of text (books, articles, code, websites) to do one core thing really well: predict the next word in a sequence, given everything that came before it.

That sounds almost too simple to power something like ChatGPT — but predicting "the next most likely word" over and over, billions of times during training, is enough for a model to learn grammar, facts, reasoning patterns, coding syntax, and conversational tone.

What problems do LLMs solve?

Before LLMs, computers were great at structured tasks (math, sorting, database lookups) but terrible at anything involving human language — understanding context, tone, ambiguity, or intent. LLMs closed that gap. They let computers:

Understand loosely-worded, ambiguous human input
Generate fluent, context-aware text
Summarize, translate, and explain complex information
Hold a conversation instead of just returning search results

Popular examples of LLMs
GPT-4 / GPT-4o / GPT-5 (OpenAI) — powers ChatGPT
Claude (Anthropic) — the model answering this very prompt
Gemini (Google DeepMind)
LLaMA (Meta) — open-weight models
Mistral, DeepSeek, and other open-source families

Common applications in daily life
Chatbots and customer support assistants
Code autocomplete (GitHub Copilot, Claude Code)
Writing assistants and grammar tools
Search engines with AI-generated summaries
Voice assistants that sound less robotic
Translation apps

        ┌─────────────────────────────┐
        │           LLM USES          │
        ├─────────────────────────────┤
        │  Chatbots      │  Coding     │
        │  Translation   │  Summaries  │
        │  Search        │  Writing    │
        └─────────────────────────────┘

2. What Happens When You Send a Message to ChatGPT?

Let's trace the journey of a single message.

Step 1 — Typing a prompt

You type something like:

"Explain how tokenization works, like I'm 12."

This is your prompt — plain human text, full of the messiness humans use: casual phrasing, typos, incomplete sentences.

Step 2 — Processing your message

Before the model can "think" about anything, your text has to be transformed into a format it can actually work with — a sequence of numbers. (We'll go deep on this in Sections 3 and 4.)

The system also adds invisible context around your message: system instructions, earlier turns in the conversation, and formatting markers — all packaged together and fed into the model at once.

Step 3 — Generating a response

The model doesn't write the whole answer in one shot. It predicts one token at a time — a token being a small chunk of text, often a word or part of a word — feeding each new token back in as input for predicting the next one.

Prompt tokens  →  [ MODEL ]  →  "The"
Prompt + "The" →  [ MODEL ]  →  "capital"
Prompt + ...   →  [ MODEL ]  →  "of"
Prompt + ...   →  [ MODEL ]  →  "France"
Prompt + ...   →  [ MODEL ]  →  "is"
Prompt + ...   →  [ MODEL ]  →  "Paris."

This is why responses "stream in" word by word — that's not a UI trick, that's literally the order in which the model generates them.

Step 4 — Why responses aren't copied from the internet

A common misconception: people assume ChatGPT is "searching the web" or "quoting a database" for its answers. It isn't (unless a browsing tool is explicitly turned on).

Instead, during training, the model adjusted billions of internal parameters based on patterns across huge amounts of text. By the time you're chatting with it, none of the original training text is being looked up — the model is generating new text based on learned patterns, one probable next-token at a time. That's also why it can occasionally get things confidently wrong: it's producing what's statistically likely, not retrieving a verified fact from a source.

3. Why Computers Don't Understand Human Language

Here's the uncomfortable truth: computers don't understand words at all.

Text vs numbers

At the hardware level, a computer only understands one thing: numbers, encoded as electrical signals — on or off, 1 or 0. Every piece of text, image, or sound you've ever seen on a screen is, underneath, a pile of numbers.

"Hi" → H = 72, i = 105  (in plain ASCII)

That's fine for storing and displaying text. But it's nowhere near enough for a computer to grasp meaning, grammar, or intent.

Why computers need everything converted into numbers

Machine learning models are, at their core, mathematical functions — matrix multiplications, additions, and non-linear transformations. You can't multiply a matrix by the word "dog." You can multiply it by a list of numbers that represents "dog."

So before any language model can process your sentence, that sentence has to be converted into numerical form the math can operate on.

Introduction to tokens

This is where tokens come in — the bridge between human-readable text and machine-readable numbers. Instead of chopping text into individual characters (too granular) or whole words (too limiting for a language with typos, slang, and multiple languages), models break text into tokens: small, reusable chunks of text.

That's the perfect segue into the next section.

4. Tokenization

What tokens are

A token is a chunk of text — sometimes a whole word, sometimes part of a word, sometimes a single character or punctuation mark. Tokenization is the process of breaking your input into these chunks before feeding it to the model.

Why tokenization is needed

Tokenization solves a few problems at once:

It gives the model a manageable, fixed-size vocabulary (tens of thousands of tokens) instead of infinite possible words.
It lets the model handle words it's never seen before, by breaking them into familiar sub-pieces.
It keeps common words efficient (one token) while rare or complex words get split into multiple tokens. ### Words vs tokens

A common beginner assumption is "1 word = 1 token." That's often wrong.

Text	Token Breakdown	Token Count
"cat"	`cat`	1
"cats"	`cat`, `s`	2
"tokenization"	`token`, `ization`	2
"unbelievable"	`un`, `believ`, `able`	3
"ChatGPT"	`Chat`, `G`, `PT`	3

As a rough rule of thumb, in English, 1 token ≈ 4 characters, or about ¾ of a word.

Simple example — full sentence

Text:    "Tokenization is cool!"

Tokens:  [ "Token" | "ization" | " is" | " cool" | "!" ]

Numbers: [ 15496   | 1634     | 318   | 3608   | 0 ]
                       (illustrative IDs)

Each token gets mapped to a unique number (a token ID) from the model's vocabulary. That list of numbers is what actually gets fed into the model — not the words themselves.

   TEXT
    │
    ▼
 TOKENS   ["Token", "ization", " is", " cool", "!"]
    │
    ▼
 TOKEN IDs   [15496, 1634, 318, 3608, 0]
    │
    ▼
  MODEL INPUT

5. Transformers

What a Transformer is

The Transformer is a neural network architecture introduced by Google researchers in 2017, in a paper with the memorable title "Attention Is All You Need." It's the architectural backbone behind GPT ("Generative Pre-trained Transformer"), Claude, Gemini, and virtually every major LLM today.

At its core, a Transformer takes a sequence of token numbers and passes them through many stacked layers that repeatedly ask: "Given every other token in this sequence, how relevant is each one to understanding this particular token?"

Why it changed AI

Before Transformers, models processed text mostly one word at a time, in order (like reading left to right, one step at a time, forgetting earlier context along the way). This made it hard to handle long sentences or connect ideas that were far apart in the text.

Transformers introduced a mechanism called self-attention, which lets the model look at all tokens in a sequence simultaneously and weigh how much each one matters to every other one — regardless of distance. This was faster to train (highly parallelizable on GPUs) and dramatically better at capturing long-range context.

How it helps understand language

Consider this sentence:

"The trophy didn't fit in the suitcase because it was too big."

What does "it" refer to — the trophy or the suitcase? Humans resolve this instantly using context. Self-attention lets the model do something similar: when processing the token "it," it can assign high attention weight to "trophy" (and lower weight to "suitcase"), effectively learning which words matter most for interpreting which other words.

        ATTENTION FOR "it"

  The   trophy   didn't  fit  suitcase  because  it  was  too  big
   .      ███       .     .      ▓        .      ●   .    .    .

  ███ = strong attention   ▓ = some attention   ● = current token

Stack dozens of these attention layers on top of each other, across billions of parameters, and the model builds up a rich internal representation of grammar, meaning, and even reasoning patterns.

Why almost every modern LLM uses Transformers

Transformers scale remarkably well — feed them more data and more compute, and they reliably keep getting better, a trend often called the "scaling laws" of deep learning. Combined with their ability to train in parallel (much faster than older sequential architectures) and their strength at capturing context over long passages, Transformers became the default choice for essentially every major LLM built since 2018 — GPT, Claude, Gemini, LLaMA, and beyond.

Putting It All Together — The Complete Workflow

┌──────────┐   ┌────────────┐   ┌─────────────┐   ┌──────────────┐   ┌──────────┐
│  YOUR    │──▶│ TOKENIZE   │──▶│  CONVERT TO │──▶│  TRANSFORMER │──▶│ RESPONSE │
│  PROMPT  │   │ (text →    │   │  NUMBERS    │   │  (predicts   │   │ (decoded │
│  "Hi!"   │   │  tokens)   │   │  (token IDs)│   │  next token, │   │  back to │
│          │   │            │   │             │   │  repeatedly) │   │  text)   │
└──────────┘   └────────────┘   └─────────────┘   └──────────────┘   └──────────┘

Bonus concept: the context window

Every LLM has a context window — the maximum number of tokens (prompt + conversation history + response) it can "see" at once. Think of it as the model's short-term memory span for a single conversation.

┌──────────────────────── CONTEXT WINDOW (e.g. 128K tokens) ────────────────────────┐
│  [ System instructions ] [ Earlier chat turns ] [ Your prompt ] [ Response so far ]│
└──────────────────────────────────────────────────────────────────────────────────┘
        ▲                                                                    ▲
   older tokens                                                     model generates
   may get dropped                                                  new tokens here
   if window is full

If a conversation grows longer than the context window, the oldest parts eventually fall outside the model's view — which is why very long chats can sometimes cause a model to "forget" something mentioned much earlier.

Bonus concept: temperature

Temperature is a setting that controls how "predictable" vs "creative" the model's next-token choices are.

LOW TEMPERATURE (e.g. 0.2)          HIGH TEMPERATURE (e.g. 1.2)
────────────────────────            ────────────────────────
Prompt: "The sky is"                Prompt: "The sky is"

  blue      ████████████ 92%          blue      ███████ 40%
  clear     ██ 5%                     falling    █████ 28%
  grey      █ 2%                      infinite   ████ 20%
  (other)   ▏ 1%                      (other)    ███ 12%

→ Picks "blue" almost every time    → More willing to pick unusual,
  (focused, deterministic,            surprising words (creative,
  repetitive on retries)              varied, less predictable)

Lower temperature is useful for factual, consistent answers (like code or math). Higher temperature is useful for creative writing, brainstorming, or varied phrasing.

Wrapping Up

ChatGPT doesn't "understand" your question the way a human does. It doesn't have beliefs, memories of you between separate conversations, or a database of facts it looks up. What it has is:

Your text, broken into tokens
Those tokens converted into numbers
A Transformer architecture that uses self-attention to figure out which parts of your input matter most to each other
A generation loop that predicts the most probable next token, one at a time, until it forms a complete response It's pattern-matching at a staggering scale — trained on enough human-written text that the patterns it learned are genuinely useful for reasoning, writing, and conversation. Not magic. Just very, very good math.

If you found this useful, the next post in this series will dig into **embeddings* — how tokens actually get turned into the vectors that carry meaning inside a Transformer. Stay tuned.*

Securing Apps: Password Hashing, RBAC, OAuth, and OpenID Connect

Akash Kumar — Sun, 28 Jun 2026 08:07:28 +0000

"Security isn't a feature you add at the end. It's the foundation you build everything else on top of."

Introduction: How Does a Website Know Who You Are?

Think about the last time you logged into a website. You typed your email and password, clicked a button, and suddenly the app knew who you were — your name appeared, your data loaded, your settings were right.

That moment involves several invisible systems working together. How did the server verify your password without storing it somewhere a hacker could read? How did it decide what you're allowed to see? How does "Login with Google" work without giving Google your password?

These questions touch on the core of application security. This guide answers all of them — from the fundamentals of password storage through modern authentication architectures used by the world's largest platforms.

1. Why Application Security Matters

Common Security Risks in Web Applications

Web applications face a consistent set of threats:

Credential theft — Attackers obtain usernames and passwords, either by breaching a database or by tricking users through phishing.

Privilege escalation — A regular user gains access to admin functionality by manipulating requests or exploiting missing authorization checks.

Session hijacking — An attacker steals an active session token and impersonates a legitimate user without ever knowing their password.

Injection attacks — Malicious input is used to manipulate database queries, expose data, or execute unauthorized commands.

Credential stuffing — Attackers use leaked username/password combinations from one breach to attempt logins on hundreds of other services, banking on users reusing passwords.

Authentication vs Authorization: Two Different Problems

These words are often used interchangeably, but they represent distinct concerns:

AUTHENTICATION                        AUTHORIZATION
"Who are you?"                        "What are you allowed to do?"

Verifying identity                    Enforcing permissions
Login with password, biometric, token Role-based access, feature flags
Happens first                         Happens after authentication

Example: Proving you're Alice         Example: Alice can edit posts
         at the company entrance                 but not delete them

A system can authenticate perfectly and still authorize incorrectly. A user with a valid login might be able to access another user's data if authorization isn't enforced on every request.

The Cost of Insecure Systems

Security failures are expensive — measured in money, reputation, and legal liability:

LinkedIn (2012) — 117 million password hashes leaked. Passwords were hashed with unsalted MD5, a weak algorithm, allowing attackers to crack millions of them within days. LinkedIn paid $1.25 million in a class action settlement.

Adobe (2013) — 153 million user records exposed, including passwords encrypted (not hashed) with a weak, reversible algorithm. Because the same "encrypted" value was used for identical passwords, attackers could cross-reference records to crack them.

RockYou2024 (2024) — Nearly 10 billion unique plaintext passwords compiled from decades of breaches and released publicly, fuelling credential stuffing attacks across the web.

The pattern across every major breach: passwords were either stored in plain text, hashed with outdated algorithms, or hashed without salting. All three are preventable.

2. Password Hashing and Storage

Why Passwords Should Never Be Stored in Plain Text

Storing a plain-text password means a database breach immediately hands attackers every user's password, verbatim. They don't need to crack anything — they just read the column.

The same applies to reversible encryption. If your server can decrypt a password to verify it, an attacker with access to the encryption key can decrypt every password in the database.

The correct approach is one-way hashing — a transformation that can't be reversed.

What Hashing Is

A hash function converts input of any length into a fixed-length output (the hash or digest). The same input always produces the same output, but the process is irreversible — you cannot recover the original input from the hash.

"mypassword"  ──►  bcrypt  ──►  $2b$12$...rFqLbHFSEKkQo7f7qAW6u
"mypassword"  ──►  bcrypt  ──►  $2b$12$...rFqLbHFSEKkQo7f7qAW6u  ← same
"myPassword"  ──►  bcrypt  ──►  $2b$12$...t8ZUkPqNzDqFvLxm1Y3Xi  ← different

The comparison direction matters. To verify a password at login:

User types password  ──►  hash it  ──►  compare to stored hash
                                         ↑
                         The stored hash never needs to be "undecrypted"

The Problem with Simple Hashing: Rainbow Tables

If you hash "password" with SHA-256 on any computer in the world, you get the same result. Attackers exploit this by precomputing hashes for millions of common passwords — a rainbow table — and comparing them against leaked hashes.

Two more problems arise with naive hashing:

Identical passwords produce identical hashes. If Alice and Bob both use "hunter2", their hashes are identical. Crack one, crack both.

Fast hashing algorithms are a liability. SHA-256 and MD5 were designed to be fast. Modern hardware can compute billions of SHA-256 hashes per second — making brute force attacks tractable.

How bcrypt Solves Both Problems

bcrypt is a password hashing function designed specifically for storing passwords. It addresses every weakness of naive hashing:

1. Salting — defeats rainbow tables and identical-password leaks

Before hashing, bcrypt generates a random value called a salt and incorporates it into the hash. The salt is stored alongside the hash (it doesn't need to be secret — its job is uniqueness, not secrecy).

PASSWORD HASHING WITH SALT

User A: "hunter2" + salt_A  ──►  hash_A   ← unique
User B: "hunter2" + salt_B  ──►  hash_B   ← different despite same password

Each user's hash is unique, even with an identical password.
Rainbow tables are useless — attackers would need one per salt.

2. Work factor — defeats brute force

bcrypt includes a configurable cost factor (also called work factor or rounds). Higher rounds mean more computation per hash — making each attempt slower. This is intentional.

COST FACTOR IMPACT (approximate on modern hardware)

cost=10  →  ~100ms per hash   ← 10 attempts/sec for attacker
cost=12  →  ~400ms per hash   ← 2.5 attempts/sec for attacker
cost=14  →  ~1500ms per hash  ← <1 attempt/sec for attacker

For users: a 100–400ms login is imperceptible
For attackers: 100ms × billions of attempts = years

The cost factor can be increased over time as hardware improves, without invalidating existing hashes — just re-hash passwords when users log in next.

3. The full bcrypt hash contains everything needed for verification

$2b$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
 ↑   ↑  ↑                   ↑
 |   |  salt (22 chars)      hash (31 chars)
 |   cost factor (12 rounds)
 algorithm version (2b)

No separate lookup table needed — everything required to verify the password is in the hash string itself.

Password Verification Process

REGISTRATION                          LOGIN

User: "mysecretpassword"              User: "mysecretpassword"
         │                                      │
         ▼                                      ▼
  bcrypt.hash(password, 12)           bcrypt.compare(
         │                              inputPassword,
         ▼                              storedHash
  $2b$12$...Kq7mN8pLrXt              )
         │                                      │
         ▼                                      ▼
  Store in database                    true / false
  (never store plain text)

const bcrypt = require("bcrypt");

// Registration — hash before storing
async function registerUser(email, plainPassword) {
  const SALT_ROUNDS = 12;
  const hashedPassword = await bcrypt.hash(plainPassword, SALT_ROUNDS);

  await db.users.create({ email, password: hashedPassword });
  // Store hashedPassword — NEVER plainPassword
}

// Login — compare without decrypting
async function loginUser(email, plainPassword) {
  const user = await db.users.findByEmail(email);
  if (!user) return null; // User not found

  const isMatch = await bcrypt.compare(plainPassword, user.password);
  if (!isMatch) return null; // Wrong password

  return user; // Authenticated
}

Best Practices for Password Storage

DO                                    DO NOT
─────────────────────────────────────────────────────────────────
Use bcrypt, scrypt, or Argon2         Use MD5, SHA-1, SHA-256 alone
Use cost factor ≥ 12 for bcrypt       Store plain text passwords
Let bcrypt generate the salt          Use reversible encryption
Return generic error messages         Indicate whether email or
("Invalid credentials")               password was wrong specifically
Re-hash on login if cost is outdated  Log passwords anywhere
Enforce a minimum password length     Truncate long passwords

3. Authentication vs Authorization

What Authentication Means

Authentication is the process of verifying that a user is who they claim to be. It answers the question: "Are you really Alice?"

Authentication happens at the boundary of your system — when a user presents credentials and the system decides whether those credentials are valid.

Authentication methods include:

Something you know: password, PIN, security question
Something you have: OTP from an authenticator app, SMS code, hardware key
Something you are: fingerprint, face ID, voice

Multi-factor authentication (MFA) requires two or more of these — so a stolen password alone isn't enough.

What Authorization Means

Authorization determines what an authenticated user is allowed to do. It answers the question: "Alice is authenticated — what can she access?"

Authorization is checked continuously — on every request, every route, every API call. It's not a one-time gate at login; it's a question asked every time a resource is touched.

Authorization is not:
  "Did Alice log in?" → That's authentication.

Authorization is:
  "Is Alice allowed to DELETE /posts/42?" → That's authorization.
  "Can Alice see the billing dashboard?" → That's authorization.
  "Is Alice's subscription tier high enough?" → That's authorization.

Why Applications Need Both

AUTHENTICATION + AUTHORIZATION TOGETHER

Without authentication:
  Anyone can claim to be Alice → impersonation

Without authorization:
  Alice can access Bob's data, admin panels, billing records

Without both:
  Anyone can do anything → the application is open

With both:
  ✓ Identity is verified at login
  ✓ Permissions are enforced on every request
  ✓ Users see only what they're allowed to see

Everyday Examples

Application	Authentication	Authorization
Gmail	Password + 2FA	Read your own emails; not others'
Notion	Google SSO	Viewers can read; editors can write
Stripe Dashboard	Password + hardware key	Developers see logs; Owners see financials
GitHub	Username + SSH key	Collaborators can push; Maintainers can merge
Hospital system	Badge + PIN	Nurses see patient notes; Doctors see prescriptions

4. Role-Based Access Control (RBAC)

What RBAC Is

Role-Based Access Control is an authorization model where permissions are assigned to roles, and roles are assigned to users. Instead of granting individual permissions directly to each user, you define roles that represent job functions and assign users to those roles.

WITHOUT RBAC (permission per user — doesn't scale)
  Alice: [read_posts, write_posts, delete_posts, manage_users, view_analytics]
  Bob:   [read_posts, write_posts]
  Carol: [read_posts, write_posts, delete_posts, view_analytics]

WITH RBAC (permission per role — scales cleanly)
  ROLE admin:      [read_posts, write_posts, delete_posts, manage_users, view_analytics]
  ROLE editor:     [read_posts, write_posts, delete_posts, view_analytics]
  ROLE writer:     [read_posts, write_posts]
  ROLE viewer:     [read_posts]

  Alice → admin
  Bob   → writer
  Carol → editor

When Alice's role changes from admin to editor, you update one assignment — not a list of individual permissions. When a new permission is created, you add it to the role — all users in that role immediately have it.

Users, Roles, and Permissions

The RBAC model has three building blocks:

User — A person with an account in the system.

Role — A named collection of permissions, representing a job function or access level (admin, editor, billing_manager, support_agent).

Permission — A specific action on a specific resource (read:posts, delete:users, view:billing, publish:articles).

The relationship chain is: User → has Role → has Permissions

RBAC ENTITY RELATIONSHIP

┌─────────┐     assigned      ┌──────────┐    contains    ┌────────────────┐
│  User   │ ────────────────► │   Role   │ ─────────────► │  Permission    │
│         │     (many-to-many)│          │  (many-to-many)│                │
│ Alice   │                   │  admin   │                │ delete:posts   │
│ Bob     │                   │  editor  │                │ manage:users   │
│ Carol   │                   │  viewer  │                │ view:analytics │
└─────────┘                   └──────────┘                └────────────────┘

Role Hierarchy Example: Blog Platform

ROLE HIERARCHY — BLOG PLATFORM

         ┌──────────────────────────────────────┐
         │                ADMIN                 │
         │  manage users · manage roles         │
         │  delete any content · view analytics │
         │  all editor permissions              │
         └──────────────────┬───────────────────┘
                            │ inherits from
         ┌──────────────────▼───────────────────┐
         │               EDITOR                 │
         │  publish articles · delete own posts │
         │  moderate comments · view analytics  │
         │  all writer permissions              │
         └──────────────────┬───────────────────┘
                            │ inherits from
         ┌──────────────────▼───────────────────┐
         │               WRITER                 │
         │  create posts · edit own posts       │
         │  upload images                       │
         │  all viewer permissions              │
         └──────────────────┬───────────────────┘
                            │ inherits from
         ┌──────────────────▼───────────────────┐
         │               VIEWER                 │
         │  read published articles             │
         │  post comments                       │
         └──────────────────────────────────────┘

Implementing RBAC in Express

// Middleware to check role
function requireRole(...allowedRoles) {
  return (req, res, next) => {
    const userRole = req.user?.role; // Set during authentication

    if (!userRole || !allowedRoles.includes(userRole)) {
      return res.status(403).json({
        error: "Forbidden — insufficient permissions"
      });
    }

    next();
  };
}

// Permission-level check (more granular than role check)
function requirePermission(permission) {
  return (req, res, next) => {
    const userPermissions = req.user?.permissions || [];

    if (!userPermissions.includes(permission)) {
      return res.status(403).json({
        error: "Forbidden — missing required permission"
      });
    }

    next();
  };
}

// Route protection examples
app.get("/admin/users",
  requireRole("admin"),               // only admins
  listAllUsers
);

app.delete("/posts/:id",
  requireRole("admin", "editor"),     // admins and editors
  deletePost
);

app.post("/posts",
  requireRole("admin", "editor", "writer"),
  createPost
);

app.get("/posts",                     // no role check — public
  listPosts
);

Scaling Permissions in Large Applications

As applications grow, flat role lists become insufficient. Common patterns for scaling:

Attribute-Based Access Control (ABAC) — Permissions based on attributes of the user, the resource, and the environment. "Alice can edit this document because she's in the Engineering team and this document's department is Engineering."

Resource ownership — Users can always perform certain actions on resources they created, regardless of their global role.

Scoped permissions — Permissions limited to a specific organization, workspace, or tenant. Alice might be admin in workspace A but only viewer in workspace B.

5. OAuth 2.0 Explained

The Problem OAuth Solves

Before OAuth, the only way for one application to access your data in another was to give it your username and password. Want a printing service to access your Google Photos? Type your Google password into the printing service's form.

The problems with this approach are obvious:

PROBLEMS WITH SHARING PASSWORDS

1. You expose your entire account to the third party
   → They could read your emails, see all your files, access everything

2. You have no way to limit what they can access
   → There's no "give access to photos only"

3. You can't revoke access without changing your password
   → Which logs out every other service using that password

4. You can't tell what the third party is doing with your credentials
   → No audit trail of their actions

OAuth 2.0 is an authorization framework that lets users grant third-party applications limited, scoped access to their account — without sharing their password.

The Four Actors in OAuth

OAUTH 2.0 ACTORS

┌──────────────────┐    owns data    ┌──────────────────┐
│  Resource Owner  │ ─────────────── │ Resource Server  │
│   (the user)     │                 │  (Google Photos, │
│                  │                 │   GitHub, etc.)  │
└────────┬─────────┘                 └──────────────────┘
         │
         │ grants permission to
         │
┌────────▼─────────┐  gets token from ┌──────────────────┐
│  Client App      │ ──────────────── │  Authorization   │
│ (the third-party │                  │     Server       │
│  application)    │                  │  (issues tokens) │
└──────────────────┘                  └──────────────────┘

Resource Owner — The user who owns the data and decides what to share.

Client Application — The third-party app requesting access (a photo editor, a code analysis tool, a calendar integration).

Authorization Server — The server that authenticates the user and issues access tokens (Google's auth server, GitHub's auth server, your own identity provider).

Resource Server — The API server holding the actual data (Google Photos API, GitHub API). Often the same system as the authorization server.

The Authorization Code Flow

The most common OAuth flow for web applications:

OAUTH 2.0 — AUTHORIZATION CODE FLOW

  User                Client App           Auth Server        Resource Server
    │                     │                    │                    │
    │  1. Click           │                    │                    │
    │  "Login with        │                    │                    │
    │   Google"           │                    │                    │
    │ ─────────────────► │                    │                    │
    │                     │  2. Redirect to    │                    │
    │                     │  auth server with  │                    │
    │                     │  scope + client_id │                    │
    │                     │ ─────────────────► │                    │
    │                     │                    │                    │
    │  3. Google shows consent screen          │                    │
    │ ◄──────────────────────────────────────  │                    │
    │                     │                    │                    │
    │  4. User approves   │                    │                    │
    │ ─────────────────────────────────────── ►│                    │
    │                     │                    │                    │
    │                     │  5. Auth server sends authorization code│
    │                     │ ◄───────────────── │                    │
    │                     │                    │                    │
    │                     │  6. Client exchanges code for           │
    │                     │     access token (server-to-server)     │
    │                     │ ─────────────────► │                    │
    │                     │                    │                    │
    │                     │  7. Access token   │                    │
    │                     │ ◄───────────────── │                    │
    │                     │                    │                    │
    │                     │  8. Use access token to call API        │
    │                     │ ──────────────────────────────────────► │
    │                     │                    │                    │
    │                     │  9. Protected resource data             │
    │                     │ ◄────────────────────────────────────── │

Access Tokens and Scopes

An access token is a credential that represents the user's grant of access to the client application. It's typically a signed string (often a JWT) that the resource server validates on every API call.

Scopes limit what the token can access. The client declares which scopes it needs, the user approves them, and the token is bound to those scopes:

Common OAuth scopes:

GitHub:   repo          → read/write repos
          read:user     → read profile info
          gist          → create gists
          notifications → read notifications

Google:   email              → read email address
          profile            → read basic profile info
          https://www.googleapis.com/auth/calendar → full calendar access
          https://www.googleapis.com/auth/drive.readonly → read-only Drive

The principle: request only the scopes you need. A tool that reads your GitHub issues doesn't need repo (which would let it push code).

Real-World Example: "Login with GitHub"

What the user sees:
  "Would you like to authorize CodeAnalyzer to:
   ✓ Read your public profile information
   ✓ Access your public repositories
   Authorize App | Cancel"

What's happening behind the scenes:
  → Client requests scopes: ["read:user", "public_repo"]
  → User approves on GitHub's own server
  → Client receives access token
  → Client can now call GitHub API with that token
  → Client CANNOT read your emails, private repos, or billing info
  → You can revoke this token any time in GitHub Settings → Applications

6. OpenID Connect (OIDC)

What OAuth 2.0 Is Missing

OAuth 2.0 solves authorization — it lets applications access resources on your behalf. But it doesn't answer an important question: who are you?

OAuth provides an access token that says "the bearer of this token is allowed to read photos." But it doesn't say whose photos, or anything about the user's identity. Applications had to hack around this by calling a separate /me or /userinfo endpoint — and every provider implemented it differently.

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that standardizes the answer to "who are you?" It adds authentication to OAuth's authorization.

How OIDC Extends OAuth

OIDC adds one critical thing to the OAuth flow: an ID token.

OAUTH 2.0 (authorization only)
  → Access token: "I can read your photos"

OPENID CONNECT (authorization + authentication)
  → Access token: "I can read your photos"    ← same as OAuth
  → ID token:     "You are Alice, born 1990, email alice@example.com"  ← new

The ID token is a JWT (JSON Web Token) — a signed, structured object that contains claims about the user's identity:

{
  "iss": "https://accounts.google.com",
  "sub": "10769150350006150715113082367",
  "aud": "your-client-id.apps.googleusercontent.com",
  "exp": 1735689600,
  "iat": 1735686000,
  "name": "Alice Smith",
  "email": "alice@example.com",
  "picture": "https://lh3.googleusercontent.com/...",
  "email_verified": true
}

These fields are called claims. The application can trust them because the ID token is cryptographically signed by the identity provider.

The OIDC Flow

OPENID CONNECT FLOW

1. Client redirects user to identity provider with:
   scope: openid profile email   ← "openid" scope triggers OIDC

2. User authenticates with their identity provider
   (enters password, uses biometric, passes MFA)

3. Identity provider returns:
   → Authorization code (same as OAuth)

4. Client exchanges code for:
   → Access token  (for calling APIs)
   → ID token      (contains user identity)
   → Refresh token (optional, for long sessions)

5. Client validates the ID token signature using
   the identity provider's public key

6. Client extracts user identity from ID token claims:
   sub = "unique user ID" (never changes for this user)
   email = "alice@example.com"
   name = "Alice Smith"

7. Client creates a local session for Alice

Authentication vs Authorization in OIDC

IN AN OIDC SYSTEM:

ID token       = authentication result
               → "This is Alice" (signed by Google/Okta/your IdP)

Access token   = authorization grant
               → "Alice allowed this app to read her calendar"

Refresh token  = session extension mechanism
               → "Silently get a new access token when this one expires"

Why OIDC Matters for Modern Applications

Before OIDC, "Login with Google" wasn't a standard — every provider (Google, Facebook, Twitter) had different endpoints, different response formats, different claim names. Developers had to write separate integration code for each.

OIDC standardizes everything. An application built to OIDC spec works with any compliant identity provider — Google, Microsoft, Okta, Auth0, GitHub, your own corporate identity server — by changing configuration, not code.

7. Modern Authentication Architecture

From Traditional to Modern

TRADITIONAL LOGIN SYSTEM (2000s)

  Browser ──────────────────► Your Server
                               ├── Check username/password
                               ├── Create server-side session
                               ├── Set session cookie
                               └── Store session in memory/DB

  Every request:
  Browser sends cookie ──► Server looks up session ──► Get user data

  Problems:
  → Sessions stored on server (memory/database) — hard to scale
  → Works per-domain only — can't share login across subdomains or apps
  → Each application manages its own user database and auth code

MODERN TOKEN-BASED SYSTEM (today)

  Browser ──────────────────► Auth Server (dedicated)
                               ├── Verify credentials
                               ├── Issue JWT access token (signed)
                               └── Issue refresh token

  Every API request:
  Browser sends JWT ──► API validates signature (stateless) ──► Serve data

  Advantages:
  → Stateless — no server-side session storage
  → Scalable — any server can validate the signature
  → Cross-domain — token works across subdomains and APIs

Social Login

Social login (Login with Google/GitHub/Apple) uses OIDC:

SOCIAL LOGIN ARCHITECTURE

  Your App                Google OIDC               Your Database
     │                       │                           │
     │  1. Redirect to       │                           │
     │  Google with          │                           │
     │  scope=openid email   │                           │
     │ ────────────────────► │                           │
     │                       │  2. User logs in to       │
     │                       │  Google (not your app)    │
     │  3. ID token          │                           │
     │ ◄──────────────────── │                           │
     │                       │                           │
     │  4. Extract sub (Google's unique user ID)         │
     │ ─────────────────────────────────────────────────►│
     │                       │                           │
     │  5. Find or create user record by sub             │
     │ ◄─────────────────────────────────────────────────│
     │                       │                           │
     │  6. Issue your own session/JWT for the user       │

You never see the user's Google password. You receive a verified, signed assertion from Google that this person authenticated successfully and here is their identity.

Single Sign-On (SSO)

SSO lets users authenticate once and access multiple applications without logging in again.

SINGLE SIGN-ON ARCHITECTURE

                        ┌─────────────────────┐
                        │   Identity Provider  │
                        │       (IdP)          │
                        │  (Okta, Azure AD,   │
                        │   Google Workspace) │
                        └──────────┬──────────┘
                                   │ issues tokens
                    ┌──────────────┼──────────────┐
                    │              │              │
             ┌──────▼──────┐ ┌────▼──────┐ ┌────▼──────┐
             │    CRM App  │ │ HR Portal │ │  Dev Tools│
             │  (Salesforce)│ │  (Workday)│ │  (GitHub) │
             └─────────────┘ └───────────┘ └───────────┘

User logs in once to the IdP → all three apps recognize the session
Log out from IdP → logged out from all three simultaneously

SSO is standard in enterprise environments. Employees authenticate with corporate credentials once, and all internal tools (email, project management, HR, developer tools) share that authentication.

Authentication in Modern SaaS Products

MULTI-TENANT SAAS AUTHENTICATION

  Personal accounts:    Email/password + MFA, social login (OIDC)
  Team accounts:        SSO with company IdP (Okta, Azure AD)
  API access:           API keys or OAuth tokens with scopes
  Machine-to-machine:   OAuth client credentials flow (no user involved)
  Administrative:       Separate admin portal, hardware MFA required

8. Security Best Practices

Strong Password Policies

MINIMUM PASSWORD REQUIREMENTS (modern guidance)

Length:       12+ characters minimum (NIST recommends 14-64)
Characters:   Allow all printable characters + spaces
Complexity:   Don't mandate special chars — encourages predictable patterns
              (P@ssw0rd! is weaker than a long passphrase)
Blocklist:    Reject passwords found in breach databases (HaveIBeenPwned)
Rotation:     Don't force periodic rotation — causes weak patterns
MFA:          Treat MFA as a stronger control than complex passwords

Multi-Factor Authentication (MFA)

MFA requires a second factor beyond the password. Even if a password is leaked, an attacker without the second factor can't log in.

Factor Type	Example	Strength
SMS code	6-digit code via text	Low (SIM swapping)
TOTP app	Google Authenticator, Authy	Medium-high
Hardware key	YubiKey, FIDO2	Very high
Push notification	Duo, Okta Verify	High
Passkey (biometric)	Face ID, Windows Hello	Very high

For high-security routes (admin panels, payment operations, account changes), require re-authentication or step-up MFA even for already-authenticated sessions.

Token Expiration and Refresh Strategy

TOKEN LIFECYCLE

  Access token:   Short-lived (15 minutes – 1 hour)
                  Used for every API request
                  If stolen: attacker has access for a short window only

  Refresh token:  Long-lived (days to weeks)
                  Stored securely (HTTP-only cookie, secure storage)
                  Used only to get new access tokens
                  If stolen: attacker can get new access tokens

  Rotation:       Issue a new refresh token on every refresh
                  Invalidate the old one
                  If refresh token is reused → detect theft, revoke all sessions

  Revocation:     Maintain a token revocation list (blocklist) for
                  logout, password change, or suspected compromise

// Access token payload — keep it small
{
  "sub": "user-123",           // user identifier
  "role": "editor",            // for authorization
  "iat": 1735686000,           // issued at
  "exp": 1735689600            // expires in 1 hour
}

// What NOT to include in tokens
// ❌ password hash
// ❌ sensitive personal data (full SSN, credit card)
// ❌ large permission lists (keep tokens small)

Principle of Least Privilege

Every user, role, service, and API key should have the minimum permissions required to perform its function — nothing more.

PRINCIPLE OF LEAST PRIVILEGE IN PRACTICE

API keys:
  ❌  One master API key with full access for all services
  ✅  Separate key per service, scoped to only what it needs

Service accounts:
  ❌  All microservices run as admin
  ✅  Each microservice has a role with only its required permissions

User roles:
  ❌  Default new users to admin "for convenience"
  ✅  Default new users to viewer; elevate permissions explicitly

OAuth scopes:
  ❌  Request all available scopes at login
  ✅  Request only scopes needed for current features
  ✅  Request sensitive scopes only when needed (incremental auth)

Protecting Sensitive Routes

// Layer multiple controls on sensitive endpoints
app.delete("/admin/users/:id",
  authenticate,                      // 1. Must be logged in
  requireMFA,                        // 2. Must have MFA verified recently
  requireRole("admin"),              // 3. Must be admin
  requirePermission("delete:users"), // 4. Must have specific permission
  logAuditEvent("user.deleted"),     // 5. Log every admin action
  deleteUser
);

// Protect against CSRF on state-changing requests
app.use(csrf({ cookie: true }));

// Rate-limit login endpoint to prevent brute force
app.use("/auth/login", rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 10                    // 10 attempts per window
}));

// Always use HTTPS — HTTP leaks tokens in transit
app.use((req, res, next) => {
  if (!req.secure) return res.redirect(`https://${req.host}${req.url}`);
  next();
});

Secure Storage of Credentials

WHERE TO STORE TOKENS (CLIENT SIDE)

                localStorage    sessionStorage    HTTP-only Cookie
──────────────────────────────────────────────────────────────────
XSS risk          HIGH            HIGH              NONE
CSRF risk         NONE            NONE              YES (mitigate)
Persists          Yes             Tab only          Configurable
Server control    No              No                Yes (expire/revoke)
Recommended for   Short-lived     Temporary         Refresh tokens
                  non-sensitive   UI state          Long sessions
──────────────────────────────────────────────────────────────────

Best practice:
  Access tokens  → Short-lived, memory only (JS variable, not storage)
  Refresh tokens → HTTP-only, Secure, SameSite=Strict cookie
  API keys       → Environment variables (never in code, never in git)
  Secrets        → Secret management service (AWS Secrets Manager, Vault)

Security Layers in a Complete Application

DEFENSE IN DEPTH — SECURITY LAYERS

   Request arrives
         │
   ┌─────▼────────────────────────────────────┐
   │  1. TRANSPORT LAYER                      │
   │     HTTPS/TLS — encrypt data in transit  │
   └─────┬────────────────────────────────────┘
         │
   ┌─────▼────────────────────────────────────┐
   │  2. NETWORK LAYER                        │
   │     Rate limiting · IP allowlisting      │
   │     DDoS protection · WAF rules          │
   └─────┬────────────────────────────────────┘
         │
   ┌─────▼────────────────────────────────────┐
   │  3. AUTHENTICATION LAYER                 │
   │     Verify identity · Validate token     │
   │     Check MFA · Detect anomalies         │
   └─────┬────────────────────────────────────┘
         │
   ┌─────▼────────────────────────────────────┐
   │  4. AUTHORIZATION LAYER                  │
   │     Check role · Verify permissions      │
   │     Enforce resource ownership           │
   └─────┬────────────────────────────────────┘
         │
   ┌─────▼────────────────────────────────────┐
   │  5. INPUT VALIDATION LAYER               │
   │     Sanitize input · Validate types      │
   │     Prevent injection · Schema validate  │
   └─────┬────────────────────────────────────┘
         │
   ┌─────▼────────────────────────────────────┐
   │  6. DATA LAYER                           │
   │     Parameterized queries · Encryption   │
   │     Hashed passwords · Minimal exposure  │
   └─────┬────────────────────────────────────┘
         │
   ┌─────▼────────────────────────────────────┐
   │  7. AUDIT LAYER                          │
   │     Log all sensitive actions            │
   │     Alert on anomalies · Retain logs     │
   └──────────────────────────────────────────┘

No single layer is impenetrable. Defense in depth means an attacker who bypasses one layer still faces all the others.

Quick Reference

Concept	One-line definition
Authentication	Verifying who a user is
Authorization	Controlling what a user can do
Hashing	One-way transformation of a value
Salt	Random value added before hashing to prevent rainbow tables
bcrypt	Password hashing function with configurable work factor
RBAC	Permissions assigned to roles, roles assigned to users
OAuth 2.0	Framework for delegated authorization without sharing passwords
OIDC	Identity layer on top of OAuth that standardizes user authentication
Access token	Short-lived credential authorizing API access
Refresh token	Long-lived credential used to obtain new access tokens
ID token	JWT containing verified claims about user identity (OIDC)
SSO	Authenticate once, access multiple applications
MFA	Require two or more authentication factors
Scope	A permission boundary on an OAuth token
JWT	Signed, structured token format used for access and ID tokens

Key Takeaways

Authentication and authorization are separate problems — both are required, and authorization must be checked on every request, not just at login
Never store plain-text passwords — use bcrypt (cost ≥ 12), which handles salting automatically and is intentionally slow to resist brute force
OAuth 2.0 enables delegated authorization — users grant third-party apps scoped access without sharing their password
OpenID Connect adds authentication to OAuth — the ID token carries verified user identity claims in a standardized format
RBAC decouples permissions from users — assign permissions to roles, assign roles to users; changing a role changes everyone in it
Defense in depth — security must be enforced at transport, authentication, authorization, input validation, and data layers
Principle of least privilege — every user, service, and token should have the minimum access required
Short access tokens, secure refresh tokens — access tokens expire quickly; refresh tokens live longer but are stored in HTTP-only cookies

What's Next?

With a solid foundation in application security, these topics extend naturally:

JWT deep dive — the structure of JSON Web Tokens, signature verification, and common attack vectors (algorithm confusion, key confusion)
PKCE (Proof Key for Code Exchange) — hardening the OAuth flow for public clients like mobile apps and SPAs
Passkeys and WebAuthn — the passwordless future: device-based cryptographic authentication that eliminates phishing
Zero-trust architecture — never trust, always verify: extending least privilege across networks, services, and identities
OWASP Top 10 — the ten most critical web application security risks, with mitigation strategies for each

Security is not a checklist you complete once — it's a continuous practice of understanding threats, applying defenses, and monitoring for what slips through.

"The best security is the kind users never notice — they just feel safe." 🔐

Blocking vs Non-Blocking Code in Node.js

Akash Kumar — Sun, 28 Jun 2026 07:49:46 +0000

"Blocking code makes your server wait. Non-blocking code makes your server work while it waits."

Introduction

You've heard that Node.js is fast. But Node.js doesn't make your CPU faster or your database queries instant. What it does is eliminate something far more wasteful than slow code — idle waiting.

Most performance problems in web servers aren't caused by computation being too slow. They're caused by threads sitting frozen, doing absolutely nothing, while they wait for a file to load or a database to reply. Node.js is built from the ground up to never let that happen.

To understand how, you need to understand the difference between blocking and non-blocking code — and why that difference changes everything about how a server handles real-world load.

1. What Blocking Code Means

Blocking code is code that prevents anything else from executing until it finishes.

When a blocking operation runs, the thread freezes. It starts the operation, then stands there doing nothing — completely locked — until the result comes back. Only then can the next line of code run.

const fs = require("fs");

// BLOCKING
const data = fs.readFileSync("users.json", "utf8"); // thread frozen here
console.log("File loaded:", data);
console.log("This runs AFTER the file is fully loaded");

The readFileSync call tells Node: "Read this file. Don't do anything else until you're done." The thread sits completely still — not processing other requests, not running other callbacks — just waiting for the operating system to hand back the file contents.

The Queue Analogy

Blocking code is like a bank teller who only handles one customer at a time — and spends most of that time staring at the printer waiting for paperwork to come out. The teller is occupied but not productive. Everyone in line waits for the printer, not the teller.

What Blocking Looks Like on a Thread

Thread executing blocking code:

Time ───────────────────────────────────────────────────────►

  [Start readFileSync]
  │
  │  ← thread is FROZEN here
  │  ← cannot accept new requests
  │  ← cannot run any other code
  │  ← just... waiting
  │
  [OS returns file data]
  │
  [console.log runs — finally]

Everything halts. The thread cannot do anything else during that gap — no matter how long it takes.

2. What Non-Blocking Code Means

Non-blocking code starts an operation, registers a callback (or returns a Promise), and immediately moves on to the next piece of work. When the operation finishes, Node.js comes back and runs the callback.

const fs = require("fs");

// NON-BLOCKING
fs.readFile("users.json", "utf8", (err, data) => {
  // This runs LATER — when the file is ready
  if (err) throw err;
  console.log("File loaded:", data);
});

// This runs IMMEDIATELY — doesn't wait for the file
console.log("Continuing while file loads...");

// Output order:
// Continuing while file loads...    ← runs first
// File loaded: { ... }              ← runs when OS is ready

The thread hands off the file-read task to the operating system, registers the callback, and immediately moves forward. When the OS signals the file is ready, Node.js queues the callback and runs it on the next available tick.

The Same Thread, But Never Idle

Thread executing non-blocking code:

Time ───────────────────────────────────────────────────────►

  [Call readFile → hand off to OS]
  [Register callback]
  [Continue to next line — runs IMMEDIATELY]
  [Handle other requests]
  [Run other callbacks]
                         [OS signals: file ready]
                         [Callback fires — process data]

The thread is never frozen. It keeps moving. The slow work happens off to the side and the thread is notified when it's done.

3. Why Blocking Slows Servers

A single user triggering a blocking read is a minor nuisance. A hundred concurrent users doing it is a disaster.

Blocking Under Load

When your server uses blocking I/O, every request that triggers a blocking operation freezes the thread handling it:

BLOCKING SERVER — 4 requests arrive simultaneously

Time ───────────────────────────────────────────────────────►

Req A: [── read file ──][respond]
Req B:                  [── read file ──][respond]
Req C:                                  [── read file ──][respond]
Req D:                                                  [── read file ──][respond]

Total time = sum of all waits.
Under 100 concurrent requests: catastrophic queue buildup.

Each request waits for the one before it. As traffic grows, response times grow linearly. At enough concurrency, requests time out before they're even handled.

The Thread Pool Trap

Traditional multi-threaded servers (PHP, Java out of the box) sidestep this by giving each request its own thread. That way, each blocking request only freezes its own thread. But threads are expensive:

Traditional server under 1,000 concurrent requests:
→ 1,000 threads spawned
→ ~1–2 GB RAM just for thread stacks
→ constant OS context switching between them
→ diminishing returns as concurrency grows beyond the pool size

Node.js sidesteps this entirely — one thread, never blocking, handles thousands of connections.

Non-Blocking Under Load

NODE.JS NON-BLOCKING — same 4 requests

Time ───────────────────────────────────────────────────────►

Thread: [A:start][B:start][C:start][D:start][A:cb][B:cb][C:cb][D:cb]
              ↓       ↓       ↓       ↓
             OS      OS      OS      OS   ← all 4 reads run simultaneously

Total time ≈ time of the SLOWEST single read, not their sum.

All four I/O operations run concurrently in the background via libuv. The thread registers all four, keeps moving, and handles callbacks as each one completes.

4. Async Operations in Node.js

Node.js gives you three patterns for writing non-blocking code, each building on the previous.

Pattern 1: Callbacks

The original Node.js pattern. Pass a function as the last argument — it's called when the async operation completes.

const fs = require("fs");

fs.readFile("config.json", "utf8", (err, data) => {
  if (err) {
    console.error("Read failed:", err.message);
    return;
  }
  const config = JSON.parse(data);
  console.log("Config loaded:", config);
});

console.log("Server starting..."); // runs immediately, before the file loads

The Node.js callback convention: The first argument is always the error (null on success), the second is the result. You'll see this pattern throughout Node.js core modules.

Pattern 2: Promises

Promises represent a future value and are cleanly chainable. fs.promises gives you Promise-based versions of all file system operations.

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

fs.readFile("config.json", "utf8")
  .then(data => {
    const config = JSON.parse(data);
    console.log("Config:", config);
  })
  .catch(err => {
    console.error("Read failed:", err.message);
  });

console.log("Server starting..."); // still runs immediately

Pattern 3: async/await (preferred)

async/await is syntactic sugar over Promises. It makes async code look synchronous — without actually blocking.

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

async function loadConfig() {
  try {
    const data = await fs.readFile("config.json", "utf8");
    const config = JSON.parse(data);
    console.log("Config:", config);
    return config;
  } catch (err) {
    console.error("Read failed:", err.message);
  }
}

loadConfig();
console.log("Server starting..."); // still runs immediately

await looks like it's waiting — but it only suspends the async function itself, releasing the thread to do other work. When the Promise resolves, execution resumes exactly where it paused.

The Critical Difference at a Glance

// BLOCKING — thread frozen for the entire read duration
const data = fs.readFileSync("users.json", "utf8");
processData(data);
handleNextRequest();   // waits for everything above to finish

// NON-BLOCKING — thread free the entire time
fs.readFile("users.json", "utf8", (err, data) => {
  processData(data);   // runs when file is ready
});
handleNextRequest();   // runs IMMEDIATELY, in parallel with the read

5. Real-World Examples

File Read: Sync vs Async in an Express Route

const express = require("express");
const fs = require("fs");
const fsPromises = require("fs").promises;
const app = express();

// BLOCKING — freezes the entire server for every single request
app.get("/config-bad", (req, res) => {
  const data = fs.readFileSync("config.json", "utf8"); // server stalls here
  res.json(JSON.parse(data));
});

// NON-BLOCKING — correct approach
app.get("/config-good", async (req, res) => {
  try {
    const data = await fsPromises.readFile("config.json", "utf8");
    res.json(JSON.parse(data));
  } catch (err) {
    res.status(500).json({ error: "Failed to load config" });
  }
});

With the blocking version, 50 simultaneous requests to /config-bad form a strict queue — each one waiting for the previous file read to complete. With the non-blocking version, all 50 reads start immediately and resolve as the OS finishes each one.

Database Calls: The Most Common Real-World Case

Every database query is I/O. Blocking on a DB call in a request handler is one of the most common and costly beginner mistakes.

// BLOCKING DB CALL (conceptual — good DB libraries are always async)
app.get("/users-bad/:id", (req, res) => {
  // Server frozen for the entire 50–200ms DB round trip
  const user = db.querySync("SELECT * FROM users WHERE id = ?", [req.params.id]);
  res.json(user);
});

// NON-BLOCKING — how every good Node.js DB library works
app.get("/users/:id", async (req, res) => {
  try {
    // Thread is FREE during the 50–200ms DB round trip
    // Other requests are handled while this query runs in the background
    const user = await db.query(
      "SELECT * FROM users WHERE id = ?",
      [req.params.id]
    );

    if (!user) return res.status(404).json({ error: "Not found" });
    res.json(user);
  } catch (err) {
    res.status(500).json({ error: "Database error" });
  }
});

A typical DB query takes 20–200ms. With a blocking model, that's 20–200ms where your server can't respond to anyone else. With non-blocking, the thread handles dozens of other requests during that same window.

Running Multiple I/O Operations in Parallel

The biggest win from non-blocking I/O is Promise.all() — firing multiple operations simultaneously and waiting for all of them to finish.

const fsPromises = require("fs").promises;

// SEQUENTIAL — each await waits for the previous one to finish
async function loadSequential() {
  const users    = await fsPromises.readFile("users.json",    "utf8"); // 50ms
  const products = await fsPromises.readFile("products.json", "utf8"); // 50ms
  const orders   = await fsPromises.readFile("orders.json",   "utf8"); // 50ms
  return { users, products, orders };
  // Total: ~150ms
}

// PARALLEL — all three start and run at the same time
async function loadParallel() {
  const [users, products, orders] = await Promise.all([
    fsPromises.readFile("users.json",    "utf8"),
    fsPromises.readFile("products.json", "utf8"),
    fsPromises.readFile("orders.json",   "utf8")
  ]);
  return { users, products, orders };
  // Total: ~50ms (time of the slowest read, not the sum)
}

Three sequential awaits: ~150ms. Three parallel via Promise.all: ~50ms. The savings multiply with every additional operation.

The One Case Where Blocking Is Acceptable

Blocking I/O has exactly one legitimate home: startup scripts — code that runs once before the server begins accepting requests.

const fs = require("fs");

// ACCEPTABLE: runs once at startup, before any requests arrive
const config = fs.readFileSync("config.json", "utf8");
const settings = JSON.parse(config);

const app = express();
app.listen(3000, () => console.log("Server ready"));

// NEVER ACCEPTABLE: inside a request handler
app.get("/data", (req, res) => {
  const data = fs.readFileSync("data.json"); // blocks ALL concurrent requests
  res.json(data);
});

At startup, nothing is waiting — no requests are being handled, no users are impacted. Once the server is listening, treat every blocking call as a bug.

Blocking vs Non-Blocking: The Full Picture

                     BLOCKING                 NON-BLOCKING
──────────────────────────────────────────────────────────────────
Thread during I/O    Frozen — does nothing    Free — handles other work
Concurrent requests  Queue behind each other  All start immediately
Response time trend  Grows linearly with load Stays low under load
Code pattern         Direct return value       Callback / Promise / await
Node.js file API     readFileSync             readFile / fs.promises
Risk                 Server stall under load  CPU blocking (separate issue)
Route handlers       Never use blocking       Always use non-blocking
Startup scripts      Blocking is acceptable   Also fine either way
──────────────────────────────────────────────────────────────────

Quick Reference

	Blocking	Non-Blocking
Thread during I/O	Frozen	Free
Other requests	Queued	Handled in parallel
Node.js file API	`fs.readFileSync`	`fs.readFile` / `fs.promises`
Pattern	Return value	Callback / Promise / async-await
Multiple ops	Sequential only	`Promise.all()` for parallel
Route handlers	Never	Always
Startup scripts	Acceptable	Also fine

Key Takeaways

Blocking code freezes the thread until an operation completes — nothing else can run during that time
Non-blocking code hands off the operation, keeps moving, and handles the result via callback or Promise when it's ready
Under concurrent load, blocking I/O causes requests to queue — response times grow linearly with traffic
Node.js's single-thread model only works because of non-blocking I/O — mixing in blocking calls destroys the advantage
Use fs.readFile, async DB drivers, and async/await in all request handlers — never the Sync variants
Promise.all() runs multiple I/O operations in parallel — total time equals the slowest, not the sum
Blocking calls at startup (before the server listens) are the one acceptable exception

What's Next?

With a solid grip on blocking vs non-blocking, these topics follow naturally:

The event loop in depth — understanding exactly how Node.js decides which callback runs next and what "ticks" really means
Streams — processing large files and data without loading everything into memory at once
Worker Threads — the escape hatch for genuinely CPU-intensive work that would otherwise stall the event loop
async/await error handling patterns — centralising error handling so every async route is covered cleanly

The mental shift from "wait for it" to "come back when it's ready" is the core of everything Node.js does well. Once this clicks, writing high-performance server code becomes intuitive.

Next in the series: the Node.js event loop in depth — understanding exactly how callbacks are scheduled, what the call stack is, and why setTimeout(fn, 0) doesn't mean "immediately". 🚀

REST API Design Made Simple with Express.js

Akash Kumar — Sat, 27 Jun 2026 12:00:44 +0000

"An API is a contract between your server and everyone who wants to talk to it. REST is the language that contract is written in."

Introduction

Every time your frontend fetches a list of users, a mobile app submits a form, or one service talks to another — that communication happens through an API. And the most widely adopted style for building those APIs is REST.

REST isn't a library or a framework. It's a set of conventions — a shared language for structuring how clients and servers communicate. Express.js is the tool that makes implementing those conventions in Node.js clean and fast.

By the end of this guide you'll understand what REST means, how HTTP methods map to actions, how to name your routes correctly, and how to build a complete set of user endpoints with Express.

1. What REST API Means

REST stands for Representational State Transfer. Ignore the academic name — what it actually means in practice is a simple set of rules for how a client (a browser, a mobile app, another server) communicates with your server over HTTP.

APIs as Communication

Think of an API as a waiter in a restaurant:

CLIENT                        SERVER
(diner)                    (kitchen)

  │  "I'd like the user     │
  │   with ID 42, please"   │
  │ ──────────────────────► │
  │                         │  looks up user 42
  │                         │  prepares a response
  │ ◄────────────────────── │
  │  Here's your user:      │
  │  { id: 42, name: "..." }│

The client doesn't know how the kitchen works. It just sends a request in the right format and expects a response. The API is the menu that defines what requests are valid and what responses look like.

What Makes an API "RESTful"

A REST API follows these core principles:

Resources over actions — You describe things (users, orders, products), not verbs (getUser, createOrder). The action is expressed by the HTTP method, not the URL.

Stateless — Every request contains all the information the server needs. The server holds no session between requests.

Uniform interface — Consistent URL patterns and HTTP methods mean any developer can predict how your API works without reading every endpoint's documentation.

2. Resources in REST Architecture

The most important concept in REST is the resource. A resource is any piece of data your API exposes — a user, a post, a product, an order.

In REST, resources are represented as nouns in the URL:

✅ CORRECT — noun-based resources
/users
/users/42
/users/42/posts

❌ WRONG — verb-based URLs (not RESTful)
/getUser
/createUser
/deleteUserById
/fetchAllPosts

The URL tells you what you're working with. The HTTP method tells you what you want to do with it.

Two URL Patterns

Every resource has two URL patterns:

COLLECTION       →  /users         (all users)
SINGLE RESOURCE  →  /users/:id     (one specific user)

This simple pattern covers every operation you'll ever need.

3. HTTP Methods: The Four Pillars of REST

HTTP methods are the verbs that act on your noun-based resources. Four cover the overwhelming majority of what any API needs to do.

HTTP METHOD  │  ACTION        │  SQL EQUIVALENT  │  CRUD
─────────────┼────────────────┼──────────────────┼────────
GET          │  Read          │  SELECT           │  Read
POST         │  Create        │  INSERT           │  Create
PUT          │  Update        │  UPDATE           │  Update
DELETE       │  Remove        │  DELETE           │  Delete

GET — Fetch Data

GET retrieves data. It should never change anything on the server. It's safe to call multiple times with the same result.

// Get all users
app.get("/users", async (req, res) => {
  const users = await db.getAll();
  res.status(200).json(users);
});

// Get a specific user
app.get("/users/:id", async (req, res) => {
  const user = await db.getById(req.params.id);
  res.status(200).json(user);
});

POST — Create a Resource

POST creates a new resource. The data for the new resource comes in the request body. The server decides the new resource's ID.

// Create a new user
app.post("/users", async (req, res) => {
  const { name, email } = req.body;
  const newUser = await db.create({ name, email });
  res.status(201).json(newUser); // 201 = Created
});

PUT — Update a Resource

PUT updates an existing resource. It typically replaces the entire resource with the new data sent in the body.

// Update (replace) a user
app.put("/users/:id", async (req, res) => {
  const { name, email } = req.body;
  const updatedUser = await db.update(req.params.id, { name, email });
  res.status(200).json(updatedUser);
});

PUT vs PATCH: PUT replaces the whole resource. PATCH updates only the fields you send. For simplicity, most beginner APIs just use PUT.

DELETE — Remove a Resource

DELETE removes a resource. The server deletes it and typically responds with either the deleted item or nothing (just a status code).

// Delete a user
app.delete("/users/:id", async (req, res) => {
  await db.delete(req.params.id);
  res.status(204).send(); // 204 = No Content (success, nothing to return)
});

4. Status Codes: Communicating What Happened

HTTP status codes are the server's way of telling the client what happened to its request. They're three-digit numbers grouped by category.

The Categories

1xx → Informational   (rare in APIs)
2xx → Success         (request worked)
3xx → Redirection     (go look elsewhere)
4xx → Client error    (you did something wrong)
5xx → Server error    (we did something wrong)

The Codes You'll Actually Use

Code	Name	When to use
`200`	OK	Successful GET, PUT
`201`	Created	Successful POST — new resource made
`204`	No Content	Success, nothing to return (DELETE)
`400`	Bad Request	Request body is malformed or missing fields
`401`	Unauthorized	No valid authentication provided
`403`	Forbidden	Authenticated, but not allowed to do this
`404`	Not Found	Resource doesn't exist
`409`	Conflict	Resource already exists (duplicate email)
`500`	Internal Server Error	Something broke on the server

In Practice

app.get("/users/:id", async (req, res) => {
  const user = await db.getById(req.params.id);

  if (!user) {
    return res.status(404).json({ error: "User not found" });
    //                   ^^^  Tell the client WHY it failed
  }

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

The key rule: Never just send 200 with an error message in the body. Use the actual status code — that's how clients (and developers) know what happened without reading the response body.

5. Designing REST Routes

Good REST route design is consistent, predictable, and readable. Here are the conventions that make routes instantly understandable.

URL Convention Rules

RULE 1 — Always use plural nouns
  ✅  /users      ❌  /user
  ✅  /products   ❌  /product

RULE 2 — Use kebab-case for multi-word resources
  ✅  /blog-posts   ❌  /blogPosts   ❌  /blog_posts

RULE 3 — No verbs in URLs (the method IS the verb)
  ✅  DELETE /users/42       ❌  POST /deleteUser/42
  ✅  POST   /users          ❌  GET  /createUser

RULE 4 — Nest for sub-resources (but max 2 levels deep)
  ✅  /users/42/posts         (posts belonging to user 42)
  ✅  /users/42/posts/7       (post 7 belonging to user 42)
  ❌  /users/42/posts/7/comments/3/likes   (too deep)

RULE 5 — Query strings for filtering, sorting, pagination
  ✅  GET /users?role=admin
  ✅  GET /users?sort=createdAt&order=desc
  ✅  GET /users?page=2&limit=20

The Request-Response Lifecycle

CLIENT                                           SERVER
  │                                                │
  │   GET /users/42                                │
  │   Headers: { Authorization: "Bearer ..." }     │
  │ ─────────────────────────────────────────────► │
  │                                                │  1. Parse URL → extract id: 42
  │                                                │  2. Run middleware (auth check)
  │                                                │  3. Hit route handler
  │                                                │  4. Query database
  │                                                │  5. Build response
  │                                                │
  │ ◄───────────────────────────────────────────── │
  │   Status: 200 OK                               │
  │   Content-Type: application/json               │
  │   Body: { "id": 42, "name": "Alice", ... }     │
  │                                                │
  │   (or on failure)                              │
  │                                                │
  │ ◄───────────────────────────────────────────── │
  │   Status: 404 Not Found                        │
  │   Body: { "error": "User not found" }          │

6. Example Resource: Users

Let's bring everything together and build a complete, RESTful users API with Express.

The Route Map

METHOD   ROUTE           ACTION               BODY REQUIRED?
──────────────────────────────────────────────────────────
GET      /users          List all users        No
GET      /users/:id      Get one user          No
POST     /users          Create a user         Yes
PUT      /users/:id      Update a user         Yes
DELETE   /users/:id      Delete a user         No

The Full Implementation

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

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

// ── In-memory data store (replace with a real DB) ─────────
let users = [
  { id: 1, name: "Alice", email: "alice@example.com", role: "admin"  },
  { id: 2, name: "Bob",   email: "bob@example.com",   role: "editor" },
  { id: 3, name: "Carol", email: "carol@example.com", role: "viewer" }
];
let nextId = 4;

// ── GET /users ────────────────────────────────────────────
app.get("/users", (req, res) => {
  let result = users;
  if (req.query.role) {
    result = users.filter(u => u.role === req.query.role);
  }
  res.status(200).json(result);
});

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

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

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

  const exists = users.find(u => u.email === email);
  if (exists) {
    return res.status(409).json({ error: "Email already in use" });
  }

  const newUser = { id: nextId++, name, email, role: role || "viewer" };
  users.push(newUser);
  res.status(201).json(newUser);
});

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

  const { name, email, role } = req.body;
  if (!name || !email) {
    return res.status(400).json({ error: "Name and email are required" });
  }

  users[index] = { id: users[index].id, name, email, role: role || users[index].role };
  res.status(200).json(users[index]);
});

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

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

Testing with curl

# List all users
curl http://localhost:3000/users

# Filter by role
curl "http://localhost:3000/users?role=admin"

# Get one user
curl http://localhost:3000/users/1

# Create a user
curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Dave","email":"dave@example.com","role":"editor"}'

# Update a user
curl -X PUT http://localhost:3000/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice Smith","email":"alice@example.com","role":"admin"}'

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

What Each Response Looks Like

GET /users           → 200  [ { id, name, email, role }, ... ]
GET /users/1         → 200  { id: 1, name: "Alice", ... }
GET /users/999       → 404  { error: "User not found" }
POST /users          → 201  { id: 4, name: "Dave", ... }
POST /users (no email) → 400  { error: "Name and email are required" }
POST /users (dupe)   → 409  { error: "Email already in use" }
PUT /users/1         → 200  { id: 1, name: "Alice Smith", ... }
DELETE /users/2      → 204  (empty body)

CRUD → HTTP Method Mapping

ACTION      │  METHOD  │  ROUTE        │  SUCCESS CODE
────────────┼──────────┼───────────────┼──────────────
Read all    │  GET     │  /users       │  200 OK
Read one    │  GET     │  /users/:id   │  200 OK
Create      │  POST    │  /users       │  201 Created
Update      │  PUT     │  /users/:id   │  200 OK
Delete      │  DELETE  │  /users/:id   │  204 No Content
────────────┼──────────┼───────────────┼──────────────
Not found   │  any     │  /users/:id   │  404 Not Found
Bad body    │  POST/PUT│  /users       │  400 Bad Request
Duplicate   │  POST    │  /users       │  409 Conflict

Quick Reference

Concept	Rule
URL naming	Plural nouns: `/users`, `/products`
Multi-word	Kebab-case: `/blog-posts`
No verbs in URLs	The HTTP method is the verb
Sub-resources	Nest up to 2 levels: `/users/:id/posts`
Filtering / paging	Query strings: `?role=admin&page=2`
Successful GET	`200 OK` + data
Successful POST	`201 Created` + new resource
Successful DELETE	`204 No Content`
Resource not found	`404 Not Found` + error message
Invalid body	`400 Bad Request` + error message

Key Takeaways

REST is a set of conventions for how clients and servers communicate over HTTP — not a library
Resources are nouns in URLs; HTTP methods are the verbs that act on them
The four HTTP methods — GET, POST, PUT, DELETE — map directly to Read, Create, Update, Delete
Status codes tell clients what happened without reading the response body — use them correctly
URL design: plural nouns, no verbs, kebab-case, max 2 nesting levels
Query strings handle filtering, sorting, and pagination — not new endpoints

What's Next?

With a solid REST API foundation, natural next steps include:

Authentication middleware — protecting routes with JWT tokens so only authorised users can call PUT and DELETE
Input validation — using express-validator or zod to validate request bodies cleanly instead of manual checks
Error handling middleware — a centralised error handler so you don't repeat res.status(500) in every route
Router modules — splitting routes into routes/users.js, routes/posts.js so app.js stays clean as the API grows
Database integration — swapping the in-memory array for a real database like PostgreSQL, MongoDB, or SQLite

REST is the foundation every backend developer needs. Master these conventions and every API — whether you're building it or consuming it — will make immediate sense.

Next up: securing your REST API with JWT authentication — adding an auth middleware that turns your open endpoints into protected resources. 🚀

Map and Set in JavaScript

Akash Kumar — Fri, 26 Jun 2026 10:37:52 +0000

"Objects and arrays are JavaScript's workhorses. Map and Set are their smarter siblings — built for the jobs where the workhorses struggle."

Introduction

JavaScript developers reach for objects and arrays instinctively — they're everywhere, they're familiar, and they handle most situations just fine. But both have real limitations that quietly cause bugs and unnecessary complexity.

What happens when you need an object whose keys aren't strings? What about storing a list of values where duplicates should be impossible? What if you need to know how many entries an object has without counting them yourself?

These are exactly the gaps that Map and Set were designed to fill. Introduced in ES6, they don't replace objects and arrays — they complement them. Knowing when to reach for each one is the mark of a developer who understands their tools.

1. What Is a Map?

A Map is a collection of key-value pairs where the keys can be any type — strings, numbers, objects, booleans, even functions. Every entry is unique by key, and the Map remembers the order entries were inserted.

Creating and Using a Map

const map = new Map();

// Setting entries — key can be ANY type
map.set("name", "Alice");       // string key
map.set(42, "the answer");      // number key
map.set(true, "boolean key");   // boolean key

const objKey = { id: 1 };
map.set(objKey, "object as key"); // object key — unique capability

// Getting values
console.log(map.get("name"));   // "Alice"
console.log(map.get(42));       // "the answer"
console.log(map.get(objKey));   // "object as key"

// Checking existence
console.log(map.has("name"));   // true
console.log(map.has("age"));    // false

// Size — instant, no counting needed
console.log(map.size);          // 4

// Deleting an entry
map.delete(42);
console.log(map.size);          // 3

Iterating a Map

Map preserves insertion order, making iteration predictable:

const userRoles = new Map([
  ["alice", "admin"],
  ["bob",   "editor"],
  ["carol", "viewer"]
]);

// Iterate entries in insertion order
for (const [user, role] of userRoles) {
  console.log(`${user} → ${role}`);
}
// alice → admin
// bob   → editor
// carol → viewer

// Access just keys or just values
console.log([...userRoles.keys()]);   // ["alice", "bob", "carol"]
console.log([...userRoles.values()]); // ["admin", "editor", "viewer"]

Map Initialization Shorthand

You can initialize a Map directly from an array of [key, value] pairs:

const scores = new Map([
  ["Alice", 98],
  ["Bob",   85],
  ["Carol", 91]
]);

console.log(scores.get("Alice")); // 98
console.log(scores.size);         // 3

2. What Is a Set?

A Set is a collection of unique values. Adding a value that already exists does nothing — the Set simply ignores it. Like Map, Set remembers insertion order.

Creating and Using a Set

const set = new Set();

set.add("apple");
set.add("banana");
set.add("cherry");
set.add("apple"); // duplicate — silently ignored

console.log(set.size);            // 3, not 4
console.log(set.has("banana"));   // true
console.log(set.has("mango"));    // false

set.delete("banana");
console.log(set.size);            // 2

The Uniqueness Property in Action

This is Set's defining characteristic. No matter how many times you add the same value, it appears exactly once:

const tags = new Set();

// Simulating tags being added from multiple places
tags.add("javascript");
tags.add("nodejs");
tags.add("javascript"); // already there — no-op
tags.add("webdev");
tags.add("nodejs");     // already there — no-op
tags.add("javascript"); // already there — no-op

console.log([...tags]); // ["javascript", "nodejs", "webdev"]
console.log(tags.size); // 3

SET UNIQUENESS — VALUES ARE STORED ONLY ONCE

Input stream:
  "js"  "css"  "js"  "html"  "css"  "js"  "html"
    ↓     ↓     ✗      ↓      ✗     ✗       ✗
  ┌─────────────────────────────────────────┐
  │  Set  │  "js"  │  "css"  │  "html"  │  │
  └─────────────────────────────────────────┘

Duplicates never enter. Set size stays at 3.

The Most Common Set Use Case: Deduplication

// Remove duplicates from an array — one line
const withDupes  = [1, 2, 3, 2, 4, 1, 5, 3];
const unique     = [...new Set(withDupes)];

console.log(unique); // [1, 2, 3, 4, 5]

// Works with strings too
const words    = ["the", "quick", "the", "brown", "fox", "the"];
const dedupedWords = [...new Set(words)];

console.log(dedupedWords); // ["the", "quick", "brown", "fox"]

Iterating a Set

const colors = new Set(["red", "green", "blue"]);

for (const color of colors) {
  console.log(color);
}
// red
// green
// blue

// Convert to array for array methods
const upperColors = [...colors].map(c => c.toUpperCase());
console.log(upperColors); // ["RED", "GREEN", "BLUE"]

3. Map vs. Object: When the Familiar Tool Falls Short

Objects look like key-value stores, and they work as one — until they don't. Here are the specific ways objects surprise you.

Problem 1: Object keys are always strings (or Symbols)

const obj = {};

// You set a number key...
obj[42] = "the answer";

// ...but it gets silently converted to a string
console.log(Object.keys(obj)); // ["42"] ← became a string

// This causes real bugs:
console.log(obj[42]);   // "the answer"
console.log(obj["42"]); // "the answer" — same thing!

// With Map, key types are preserved exactly:
const map = new Map();
map.set(42, "the answer");
map.set("42", "different value");

console.log(map.get(42));    // "the answer"
console.log(map.get("42")); // "different value" — genuinely separate

Problem 2: Objects have prototype baggage

const obj = {};

// These keys exist even though you never set them:
console.log("toString" in obj);        // true  ← inherited
console.log("hasOwnProperty" in obj);  // true  ← inherited
console.log("constructor" in obj);     // true  ← inherited

// This can cause unexpected bugs if your data has these key names
obj["toString"] = "my value"; // Silently shadows a built-in

// Map has zero inherited keys — completely clean slate:
const map = new Map();
console.log(map.has("toString"));        // false
console.log(map.has("hasOwnProperty"));  // false

Problem 3: No built-in size

const obj = { a: 1, b: 2, c: 3 };

// Getting the count requires a manual call:
console.log(Object.keys(obj).length); // 3 — workaround, not elegant

// Map has it built in:
const map = new Map([["a", 1], ["b", 2], ["c", 3]]);
console.log(map.size); // 3 — direct property

Side-by-Side Comparison

MAP vs. OBJECT
────────────────────────────────────────────────────────────────
Feature               │  Object             │  Map
──────────────────────┼─────────────────────┼──────────────────
Key types allowed     │  String, Symbol      │  Any type
Prototype keys        │  Yes (inherited)     │  None
Size                  │  Object.keys().length│  .size property
Insertion order       │  Not guaranteed *    │  Always preserved
Iteration             │  for...in, Object.keys│  for...of, .forEach
JSON serializable     │  Yes                 │  No (manual work)
Best for              │  Structured records  │  Dynamic key-value

* Modern engines do preserve string-key order, but it's not
  part of the spec for all cases (e.g. integer-like string keys).
────────────────────────────────────────────────────────────────

4. Set vs. Array: When Order Isn't the Point

Arrays are ordered lists that allow duplicates. Sets are unordered collections that guarantee uniqueness. The difference sounds small but changes everything.

Problem 1: Arrays don't enforce uniqueness

const subscribers = [];

function subscribe(email) {
  // Without a guard, duplicates slip in
  subscribers.push(email);
}

subscribe("alice@example.com");
subscribe("bob@example.com");
subscribe("alice@example.com"); // duplicate!

console.log(subscribers.length); // 3 ← should be 2
console.log(subscribers);
// ["alice@example.com", "bob@example.com", "alice@example.com"]

// With a Set — uniqueness is automatic:
const subscriberSet = new Set();

subscriberSet.add("alice@example.com");
subscriberSet.add("bob@example.com");
subscriberSet.add("alice@example.com"); // ignored

console.log(subscriberSet.size); // 2 ← correct

Problem 2: Checking membership in arrays is slow

const blocklist = ["spam1.com", "spam2.com", "spam3.com" /* ... 10,000 items */];

// Array .includes() scans every element — O(n) time
function isBlocked(domain) {
  return blocklist.includes(domain); // gets slower as list grows
}

// Set .has() uses a hash lookup — O(1) time regardless of size
const blocklistSet = new Set(["spam1.com", "spam2.com", "spam3.com"]);

function isBlockedFast(domain) {
  return blocklistSet.has(domain); // instant, 10 or 10,000 items
}

Problem 3: Removing duplicates from arrays is awkward

const ids = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3];

// Array approach — verbose
const uniqueIds = ids.filter((id, index) => ids.indexOf(id) === index);

// Set approach — clean one-liner
const uniqueIdsFast = [...new Set(ids)];

console.log(uniqueIdsFast); // [3, 1, 4, 5, 9, 2, 6]

Side-by-Side Comparison

SET vs. ARRAY
────────────────────────────────────────────────────────────────
Feature               │  Array              │  Set
──────────────────────┼─────────────────────┼──────────────────
Duplicates            │  Allowed            │  Not allowed
Access by index       │  Yes — arr[0]       │  No
Membership check      │  .includes() → O(n) │  .has()    → O(1)
Insertion order       │  Preserved          │  Preserved
Size                  │  .length            │  .size
Rich methods          │  .map .filter .reduce│  .add .has .delete
Deduplication         │  Manual / verbose   │  Automatic
Best for              │  Ordered sequences  │  Unique collections
────────────────────────────────────────────────────────────────

5. When to Use Map and Set

The right choice becomes clear once you know what property you need to enforce.

Reach for Map when:

Your keys aren't strings

// Storing metadata about DOM elements (object keys)
const elementData = new Map();
const button = document.querySelector("#submit");
elementData.set(button, { clicks: 0, lastClicked: null });

// Later — retrieve by the actual element reference
button.addEventListener("click", () => {
  const data = elementData.get(button);
  data.clicks++;
  data.lastClicked = new Date();
});

You need to count or tally things

const text = "the quick brown fox jumps over the lazy dog";
const wordCount = new Map();

for (const word of text.split(" ")) {
  wordCount.set(word, (wordCount.get(word) || 0) + 1);
}

console.log(wordCount.get("the")); // 2
console.log(wordCount.size);       // 8 unique words

You need to frequently check size or iterate in order

// Track active user sessions
const activeSessions = new Map();

activeSessions.set("user-001", { loginTime: Date.now(), ip: "192.168.1.1" });
activeSessions.set("user-002", { loginTime: Date.now(), ip: "10.0.0.5" });

console.log(`Active sessions: ${activeSessions.size}`);

for (const [userId, session] of activeSessions) {
  console.log(`${userId}: connected from ${session.ip}`);
}

Reach for Set when:

You need a list with guaranteed uniqueness

// Track which tutorial steps a user has completed
const completed = new Set();

completed.add("intro");
completed.add("setup");
completed.add("intro"); // already done — ignored

console.log(completed.has("setup")); // true
console.log(`${completed.size} of 5 steps done`);

You need fast membership checks

const SUPPORTED_CURRENCIES = new Set(["USD", "EUR", "GBP", "JPY", "INR"]);

function validateCurrency(code) {
  if (!SUPPORTED_CURRENCIES.has(code)) {
    throw new Error(`Unsupported currency: ${code}`);
  }
  return true;
}

You're working with set operations (union, intersection, difference)

const frontend = new Set(["alice", "bob", "carol"]);
const backend  = new Set(["carol", "dave", "eve"]);

// Union — everyone on either team
const allDevs = new Set([...frontend, ...backend]);
console.log([...allDevs]); // ["alice", "bob", "carol", "dave", "eve"]

// Intersection — works on both teams
const fullstack = new Set([...frontend].filter(dev => backend.has(dev)));
console.log([...fullstack]); // ["carol"]

// Difference — frontend only
const frontendOnly = new Set([...frontend].filter(dev => !backend.has(dev)));
console.log([...frontendOnly]); // ["alice", "bob"]

Decision Guide

Do you need key-value pairs?
  │
  ├─ YES → Do your keys need to be non-string types,
  │         OR do you need clean iteration / .size?
  │          ├─ YES → Use Map
  │          └─ NO  → Plain Object is fine
  │
  └─ NO → Do you need a list?
            ├─ YES → Must values be unique?
            │          ├─ YES → Use Set
            │          └─ NO  → Use Array
            └─ NO → You probably need neither

Quick Reference

Method / Property	Map	Set
Add an entry	`map.set(key, value)`	`set.add(value)`
Get a value	`map.get(key)`	— (no index access)
Check existence	`map.has(key)`	`set.has(value)`
Remove an entry	`map.delete(key)`	`set.delete(value)`
Count entries	`map.size`	`set.size`
Remove all	`map.clear()`	`set.clear()`
Iterate	`for (const [k, v] of map)`	`for (const v of set)`
Convert to array	`[...map]` or `[...map.values()]`	`[...set]`
Initialize from array	`new Map([[k1,v1],[k2,v2]])`	`new Set([v1,v2,v3])`

Key Takeaways

Map is a key-value store where keys can be any type — not just strings
Set is a collection of unique values — duplicates are silently ignored on add
Use Map over Object when keys are non-strings, when you need .size, or when you want a clean prototype-free store
Use Set over Array when values must be unique, when you need fast O(1) membership checks with .has(), or when deduplicating
Both Map and Set preserve insertion order and are iterable with for...of
Convert between them and arrays easily with [...map], [...set], new Set(array), new Map(arrayOfPairs)

What's Next?

With Map and Set in your toolkit, great next topics include:

WeakMap and WeakSet — memory-efficient versions that allow garbage collection of keys; useful for caching and private data patterns
Iterators and generators — the protocol that makes Map and Set work with for...of
Array methods in depth — .reduce(), .flatMap(), .find() — complementing what Set and Map don't do
Data structures in interviews — Map and Set are the foundation of solving many common algorithm problems efficiently

Objects and arrays will always be your everyday tools. Map and Set are the specialists — reach for them when the job calls for it, and your code will be cleaner and faster for it.

Next in the series: JavaScript's WeakMap and WeakSet — the memory-conscious cousins that clean up after themselves. 🚀

Why Node.js is Perfect for Building Fast Web Applications

Akash Kumar — Fri, 26 Jun 2026 10:23:37 +0000

"Node.js doesn't make your code run faster — it makes your server stop waiting."

Introduction

Speed in web applications rarely comes from raw CPU power. In most web servers, the real bottleneck is time spent waiting — waiting for a database to respond, waiting for a file to load, waiting for a third-party API to reply.

Traditional servers block during that wait. Node.js doesn't.

That single architectural difference is what makes Node.js uniquely suited for building fast, scalable web applications — and why companies like Netflix, LinkedIn, and Uber adopted it. This guide breaks down exactly how it works, without the jargon.

1. What Makes Node.js Fast

Node.js is built on two foundational ideas that work together:

V8 — the same JavaScript engine inside Google Chrome. V8 compiles JavaScript directly to machine code rather than interpreting it line by line, making raw execution significantly faster than older scripting runtimes.

libuv — a C library that gives Node.js its superpower: a non-blocking, event-driven I/O model that lets a single thread handle thousands of concurrent connections.

It's that second piece — the I/O model — that matters most for web applications. The speed of Node.js isn't about how fast it can compute. It's about how efficiently it handles waiting.

The key insight: In web servers, most time is spent waiting on I/O — databases, files, external APIs. Node.js is architected to make that wait time nearly free.

2. Non-Blocking I/O: The Core Concept

To understand non-blocking I/O, you first need to feel what blocking looks like.

The Blocking Model (Traditional Servers)

In a traditional multi-threaded server (like a default PHP or Java setup), each incoming request gets its own thread. When that request needs to talk to a database, the thread waits — frozen, doing nothing — until the database responds.

BLOCKING SERVER — Thread-per-request model

Request A ──► [Thread 1]──► DB query... waiting... waiting... ──► Response
Request B ──► [Thread 2]──► DB query... waiting... waiting... ──► Response
Request C ──► [Thread 3]──► DB query... waiting... waiting... ──► Response
Request D ──► [Thread 4]──► DB query... waiting... waiting... ──► Response

Each thread is LOCKED during the wait.
Under high traffic, you run out of threads → new requests queue up → slowdown.

This works fine at low traffic. But under load, you run out of threads. New requests queue up. Memory spikes. The server slows to a crawl — not because your CPU is overloaded, but because hundreds of threads are frozen, doing nothing but waiting for I/O.

The Non-Blocking Model (Node.js)

Node.js takes a completely different approach. Instead of assigning a thread per request, it uses one thread and never lets it block. When a request triggers an I/O operation (a DB query, a file read), Node.js registers a callback and immediately moves on to handle the next request. When the I/O completes, the callback fires and the response is sent.

NON-BLOCKING NODE.JS — Single-thread, event-driven

                    ┌─────────────────────────────────────┐
                    │          Single JS Thread            │
Request A ──────►  │  → Start DB query A (non-blocking)  │
Request B ──────►  │  → Start DB query B (non-blocking)  │
Request C ──────►  │  → Start DB query C (non-blocking)  │
Request D ──────►  │  → Start DB query D (non-blocking)  │
                    └────────────────┬────────────────────┘
                                     │
                    ┌────────────────▼────────────────────┐
                    │          Background (libuv)          │
                    │  DB A ──► result ──► callback fires  │
                    │  DB B ──► result ──► callback fires  │
                    │  DB C ──► result ──► callback fires  │
                    │  DB D ──► result ──► callback fires  │
                    └─────────────────────────────────────┘

The thread is NEVER idle. While I/O waits in the background,
the thread keeps accepting and processing more requests.

The thread is never blocked. It never waits. It just keeps moving.

The Restaurant Analogy

Imagine two restaurants serving the same menu:

Blocking restaurant (traditional server): Every customer gets a dedicated waiter. That waiter takes the order, walks to the kitchen, and stands there staring at the grill until the food is ready — doing nothing else. With 10 waiters and an 11th customer arriving, they have to wait outside for a waiter to become available.

Node.js restaurant: One highly efficient waiter serves the entire floor. They take an order, hand it to the kitchen, and immediately move to the next table. When the kitchen calls out "Order up!", they grab it and deliver it. The kitchen handles the slow cooking — the waiter is never idle.

Node.js is that single waiter. The "kitchen" (database, filesystem, APIs) does the slow I/O work in the background while Node.js stays free to handle the next request.

3. Event-Driven Architecture

Node.js is built around an event emitter pattern. Everything that happens asynchronously — a file being read, a database query completing, an HTTP request arriving — is modeled as an event. You register a listener for that event, and Node.js calls it when the event fires.

const fs = require("fs");

// Register a listener for "file read complete" event
fs.readFile("data.json", "utf8", (err, data) => {
  if (err) throw err;
  console.log("File ready:", data);
});

// This runs IMMEDIATELY — doesn't wait for the file read
console.log("Continuing while file loads...");

// Output:
// Continuing while file loads...
// File ready: { ... }  ← arrives when the OS is done

The call to fs.readFile hands off the work to the OS and registers a callback. Execution continues to the next line instantly. When the OS signals that the file is ready, the callback fires.

This event-driven model means Node.js applications respond to things happening, rather than waiting for them to happen.

4. The Single-Threaded Model Explained

"Single-threaded" sounds like a limitation. In most contexts, it is — but for I/O-heavy web servers, it's actually an advantage.

Concurrency vs. Parallelism

These two terms are often confused. The difference matters here:

PARALLELISM — doing multiple things at the same time
(requires multiple CPU cores / threads)

  Thread 1: ████████████
  Thread 2: ████████████
  Thread 3: ████████████

CONCURRENCY — managing multiple tasks by switching between them
(only one thing executes at a time, but nothing is left idle)

  Single thread: ██░░██░░██░░██
                 run wait run wait
                 ↑         ↑
              (callbacks fire during "run" phases)

Node.js uses concurrency, not parallelism. There is only one thread — but it's always doing something useful. The waiting (I/O) happens off-thread, in the background, managed by libuv. The JS thread only runs when there's actual JavaScript to execute.

For CPU-bound work (heavy computation, video encoding, cryptography), this model struggles — the single thread gets tied up. But for the vast majority of web applications — which are I/O-bound — a single non-blocking thread easily outperforms a pool of blocking ones.

What the Single Thread Actually Looks Like

// All of these are triggered "at the same time" from Node's perspective
// but execute their callbacks sequentially on one thread

setTimeout(() => console.log("Timer done"),    1000); // handled by libuv
fetch("https://api.example.com/data")
  .then(r => r.json())
  .then(d => console.log("API done:", d));             // handled by libuv
fs.readFile("config.json", callback);                   // handled by libuv

// The JS thread is free to process the next request immediately
// libuv notifies the thread when each operation completes

5. The Event Loop: Bringing It All Together

The event loop is the mechanism that ties everything together. It's a continuous cycle that checks: "Has any pending I/O operation finished? Are there callbacks waiting to run?"

┌───────────────────────────────────────────────────────┐
│                    THE EVENT LOOP                      │
│                                                        │
│   ┌─────────────┐                                      │
│   │   Timers    │  ← setTimeout, setInterval callbacks │
│   └──────┬──────┘                                      │
│          │                                             │
│   ┌──────▼──────┐                                      │
│   │  I/O events │  ← File reads, network, DB queries  │
│   └──────┬──────┘                                      │
│          │                                             │
│   ┌──────▼──────┐                                      │
│   │  setImmed.  │  ← setImmediate() callbacks          │
│   └──────┬──────┘                                      │
│          │                                             │
│   ┌──────▼──────┐                                      │
│   │  Close evts │  ← socket.on("close", ...)           │
│   └──────┬──────┘                                      │
│          │                                             │
│          └───────────────────► (loop again)            │
│                                                        │
│  Between each phase: process.nextTick() + Promises run │
└───────────────────────────────────────────────────────┘

The event loop keeps spinning. Each iteration checks the queues for pending callbacks. When I/O completes in the background, the result is placed in the appropriate queue — and the event loop picks it up on the next tick.

This is why Node.js can handle thousands of concurrent connections on a single thread: the thread is always running callbacks, never waiting.

6. Where Node.js Performs Best

The non-blocking model shines brightest in specific categories of applications. Knowing these helps you make the right architectural choice.

Perfect fits for Node.js

REST APIs and microservices — Receive a request, query a database, return JSON. This is pure I/O work — exactly what Node.js handles with minimal overhead per connection.

app.get("/users/:id", async (req, res) => {
  const user = await db.query("SELECT * FROM users WHERE id = ?", [req.params.id]);
  res.json(user); // Non-blocking from start to finish
});

Real-time applications — Chat apps, live dashboards, collaborative tools, multiplayer games. Node.js maintains thousands of open WebSocket connections without breaking a sweat.

io.on("connection", (socket) => {
  socket.on("message", (msg) => {
    io.emit("message", msg); // Broadcast to all connected clients
  });
});
// Handles 10,000 simultaneous connections on one thread

API gateways and BFF layers — Applications that aggregate data from multiple upstream services (calling 4 APIs in parallel and combining the results) are ideal — Node.js fires all requests concurrently without blocking.

Streaming data — File uploads, video streaming, processing large datasets piece by piece. Node.js's stream model handles data as it arrives, without loading everything into memory first.

Where to be cautious

CPU-intensive tasks — Image processing, video transcoding, complex mathematical models, ML inference. These tie up the single JS thread. Solution: offload to Worker Threads, a separate process, or a dedicated service.

Heavy synchronous computation — A loop running 10 million iterations blocks the event loop. Every other request waits for it to finish.

7. Real-World Companies Using Node.js

The architectural advantages of Node.js aren't theoretical — they've been validated at massive scale.

Company	Use Case	What Node.js Solved
Netflix	API layer, streaming infrastructure	Reduced startup time by 70%; handles millions of concurrent streams
LinkedIn	Mobile backend API	Replaced Rails servers 1:1 — 10 servers became 3, handling 20× the traffic
Uber	Real-time dispatch, trip matching	Massive concurrent connections between drivers and riders
PayPal	REST API rewrite	35% faster response times; 2× requests per second vs Java
NASA	EVA suit data pipeline	Moved from 14+ separate siloed systems into one Node.js API
Trello	Real-time board updates	Long-lived WebSocket connections at scale

PayPal's case is particularly telling: they rewrote a Java API in Node.js and measured 35% faster response times and double the requests per second — with fewer servers. The bottleneck wasn't computation. It was I/O — and Node.js eliminated the wait.

Blocking vs. Non-Blocking: The Full Picture

SCENARIO: 1,000 users hit the server simultaneously,
each request needs a 50ms database query.

─────────────────────────────────────────────────────────────────
BLOCKING SERVER (e.g., traditional multi-threaded)
─────────────────────────────────────────────────────────────────
• Spawns 1,000 threads (or queues behind a thread pool)
• Each thread: allocates memory, waits 50ms idle, responds
• Memory: ~2MB per thread × 1,000 = ~2GB RAM for one burst
• Under higher load: threads exhaust → requests queue → timeouts

─────────────────────────────────────────────────────────────────
NODE.JS (non-blocking, event-driven)
─────────────────────────────────────────────────────────────────
• Accepts all 1,000 requests on 1 thread
• Fires 1,000 non-blocking DB queries simultaneously
• Thread is free while all 1,000 queries run in parallel (in libuv)
• As each query completes (~50ms), callback fires, response sent
• Memory: fraction of the thread-per-request model
• Under higher load: event loop absorbs more events → scales up

Winner: Node.js — not because it's faster per request,
but because it never stalls under concurrent load.

Quick Reference

Concept	What it means
Non-blocking I/O	I/O operations run in the background; thread never waits
Event-driven	Code runs in response to events (I/O complete, timer fired)
Single-threaded	One JS thread, but concurrency via the event loop
Event loop	Continuous cycle that picks up and runs completed callbacks
libuv	The C library that manages async I/O and the thread pool
V8	Chrome's JS engine — compiles JS to machine code
Callback	Function registered to run when an async event completes
Concurrency	Managing multiple tasks by not letting any block (≠ parallelism)

Key Takeaways

Node.js is fast for web servers because it never blocks on I/O — it offloads waiting to the background
The event loop keeps one thread continuously processing callbacks, never sitting idle
The single-threaded model handles concurrency through events, not parallelism through threads
Node.js excels at I/O-bound work: APIs, real-time apps, streaming, API gateways
For CPU-bound work, use Worker Threads or offload to a dedicated service
The performance advantage isn't raw speed — it's efficiency under concurrent load

What's Next?

With a solid understanding of why Node.js is fast, natural next topics include:

async/await in Node.js — the modern syntax for writing non-blocking code that reads like synchronous code
Express.js — the minimal web framework that builds on Node's HTTP module
Streams — Node.js's built-in model for processing data incrementally without loading it all into memory
Worker Threads — how to handle CPU-intensive work without blocking the event loop
Clustering — using multiple Node.js processes to take advantage of multi-core CPUs

The mental model you've built here — a single thread, never blocking, callbacks firing as I/O completes — is the foundation everything else in Node.js is built on.

Next read: once you understand Node's architecture, Express middleware will make complete sense — it's literally the same event-driven pipeline applied to HTTP requests. 🚀

Destructuring in JavaScript

Akash Kumar — Fri, 26 Jun 2026 00:00:32 +0000

"Destructuring is JavaScript's way of letting you unpack what you need and leave the rest behind."

Introduction

You've worked with arrays and objects in JavaScript. You know how to access their values. But have you noticed how repetitive it gets?

const user = { name: "Alice", age: 28, city: "Delhi" };

const name = user.name;
const age  = user.age;
const city = user.city;

Three lines. Three times you wrote user.something. Now imagine doing this for an object with ten properties. Or doing it across dozens of files.

Destructuring is JavaScript's answer to that repetition. It's a concise syntax that lets you extract values from arrays and objects directly into variables — in a single line. No dot notation chains. No index lookups. Just clean, readable assignments.

1. What Does Destructuring Mean?

Destructuring means pulling values out of a data structure and binding them to named variables, using a syntax that mirrors the shape of the data itself.

The key insight: instead of describing where to put things (left side) and then going to fetch them (right side), destructuring lets you describe the shape of what you expect on the left — and JavaScript fills in the values from the right.

// Traditional access — fetch and assign one by one
const name = user.name;
const age  = user.age;

// Destructuring — describe the shape, get the values
const { name, age } = user;

Both do the same thing. The destructured version is just less noise.

Destructuring works on two kinds of data structures in JavaScript: objects and arrays. The syntax is slightly different for each, and for good reason.

2. Destructuring Arrays

Array destructuring uses square brackets [] on the left side of the assignment. Values are extracted by position — the first variable gets index 0, the second gets index 1, and so on.

Before vs. After

const colors = ["red", "green", "blue"];

// ❌ Before — manual index access
const first  = colors[0];
const second = colors[1];
const third  = colors[2];

// ✅ After — array destructuring
const [first, second, third] = colors;

ARRAY DESTRUCTURING — POSITIONAL MAPPING

colors  →  [ "red",  "green",  "blue" ]
                ↓        ↓        ↓
            [first, second,  third ]

first  = "red"
second = "green"
third  = "blue"

Skipping Elements

You're not forced to take every value. Leave a gap with a comma to skip positions you don't need.

const scores = [95, 82, 76, 61, 54];

// Only want first and third — skip the second
const [gold, , bronze] = scores;

console.log(gold);   // 95
console.log(bronze); // 76

The Rest Element

Capture the remaining items into a new array using the rest syntax (...).

const [top, ...rest] = [1, 2, 3, 4, 5];

console.log(top);  // 1
console.log(rest); // [2, 3, 4, 5]

Swapping Variables

One elegant trick array destructuring unlocks — swapping two variables without a temporary placeholder:

let a = 1;
let b = 2;

// ❌ Before — needs a temp variable
let temp = a;
a = b;
b = temp;

// ✅ After — one-line swap
[a, b] = [b, a];

console.log(a); // 2
console.log(b); // 1

3. Destructuring Objects

Object destructuring uses curly braces {} on the left side. Unlike arrays, values are matched by property name — not by position — so the order on the left doesn't matter.

Before vs. After

const product = {
  id: 101,
  name: "Mechanical Keyboard",
  price: 4999,
  inStock: true
};

// ❌ Before — repeated property lookups
const id      = product.id;
const name    = product.name;
const price   = product.price;
const inStock = product.inStock;

// ✅ After — object destructuring
const { id, name, price, inStock } = product;

OBJECT DESTRUCTURING — NAME-BASED EXTRACTION

product = {
  id:      101,          ──►  const id      = 101
  name:    "Keyboard",   ──►  const name    = "Keyboard"
  price:   4999,         ──►  const price   = 4999
  inStock: true          ──►  const inStock = true
}

{ id, name, price, inStock } = product
         ↑
  Matches by property name — order doesn't matter

Renaming Variables

Sometimes the property name from the object clashes with an existing variable, or just isn't descriptive enough in context. Use a colon : to rename while destructuring.

const response = { status: 200, data: { user: "Alice" } };

// Rename 'status' → 'statusCode', 'data' → 'payload'
const { status: statusCode, data: payload } = response;

console.log(statusCode); // 200
console.log(payload);    // { user: "Alice" }

// Original names (status, data) no longer exist as variables

Nested Object Destructuring

Objects inside objects can be destructured in one go by mirroring the nested shape.

const user = {
  name: "Akash",
  address: {
    city: "Patna",
    pincode: "800001"
  }
};

// ❌ Before — two-step access
const city    = user.address.city;
const pincode = user.address.pincode;

// ✅ After — nested destructuring
const { name, address: { city, pincode } } = user;

console.log(name);    // "Akash"
console.log(city);    // "Patna"
console.log(pincode); // "800001"

Note that address itself is not created as a variable here — it's only used as a path to reach city and pincode.

Destructuring in Function Parameters

This is one of the most common places you'll see object destructuring in real code. Instead of passing a full object and accessing its properties inside the function, you destructure right in the parameter list.

const order = { id: 42, item: "Laptop", quantity: 2 };

// ❌ Before — access properties inside the function
function printOrder(order) {
  console.log(`Order #${order.id}: ${order.quantity}x ${order.item}`);
}

// ✅ After — destructure in the parameter itself
function printOrder({ id, item, quantity }) {
  console.log(`Order #${id}: ${quantity}x ${item}`);
}

printOrder(order);
// Order #42: 2x Laptop

4. Default Values

What happens when you destructure a property that doesn't exist? You get undefined. Default values let you specify a fallback for exactly that case.

Default Values in Object Destructuring

const settings = { theme: "dark" };

// 'language' doesn't exist in settings
const { theme, language } = settings;
console.log(language); // undefined ← not great

// With a default value
const { theme, language = "en" } = settings;
console.log(language); // "en" ← much better

The default only kicks in when the value is undefined — not when it's null, 0, or "".

const config = { timeout: 0, retries: null };

const { timeout = 5000, retries = 3, debug = false } = config;

console.log(timeout); // 0     ← 0 is a real value, default ignored
console.log(retries); // null  ← null is a real value, default ignored
console.log(debug);   // false ← undefined, so default applies

Default Values in Array Destructuring

const [primary = "blue", secondary = "gray"] = ["red"];

console.log(primary);   // "red"  ← value present, default ignored
console.log(secondary); // "gray" ← nothing at index 1, default applies

Combining Rename and Default

You can rename and set a default at the same time:

const user = {};

// Rename 'name' → 'username', with fallback "Guest"
const { name: username = "Guest" } = user;

console.log(username); // "Guest"

5. Benefits of Destructuring

Destructuring is more than a shorthand — it changes how you think about working with data.

Less Repetition

// ❌ Without destructuring — object name repeated everywhere
function formatAddress(location) {
  return `${location.street}, ${location.city}, ${location.state} ${location.zip}`;
}

// ✅ With destructuring — clean and flat
function formatAddress({ street, city, state, zip }) {
  return `${street}, ${city}, ${state} ${zip}`;
}

Cleaner API Responses

Real-world API responses are often deeply nested. Destructuring lets you pull out exactly what you need without intermediate variables:

// A typical API response
const response = {
  status: 200,
  data: {
    user: {
      id: 7,
      name: "Akash",
      email: "akash@example.com",
      role: "admin"
    }
  }
};

// Extract only what this function cares about
const { data: { user: { name, role } } } = response;

console.log(name); // "Akash"
console.log(role); // "admin"

Readable Function Return Values

Destructuring makes functions that return multiple values feel natural:

function getMinMax(numbers) {
  return {
    min: Math.min(...numbers),
    max: Math.max(...numbers)
  };
}

// Named return values — no [0] and [1] guessing
const { min, max } = getMinMax([3, 1, 9, 4, 7]);

console.log(min); // 1
console.log(max); // 9

Works Beautifully with Loops

const users = [
  { id: 1, name: "Alice", role: "admin" },
  { id: 2, name: "Bob",   role: "viewer" },
  { id: 3, name: "Carol", role: "editor" }
];

// Destructure each object directly in the loop
for (const { name, role } of users) {
  console.log(`${name} is a ${role}`);
}

// Alice is a admin
// Bob is a viewer
// Carol is a editor

Before vs. After: A Full Comparison

WITHOUT DESTRUCTURING                │  WITH DESTRUCTURING
─────────────────────────────────────┼───────────────────────────────────────
const name    = user.name;           │  const {
const age     = user.age;            │    name,
const city    = user.city;           │    age,
const country = user.country;        │    city,
                                     │    country
                                     │  } = user;
─────────────────────────────────────┼───────────────────────────────────────
const r = rgb[0];                    │  const [r, g, b] = rgb;
const g = rgb[1];                    │
const b = rgb[2];                    │
─────────────────────────────────────┼───────────────────────────────────────
function greet(user) {               │  function greet({ name, age = 0 }) {
  const name = user.name;            │    console.log(`Hi ${name}, ${age}`);
  const age  = user.age || 0;        │  }
  console.log(`Hi ${name}, ${age}`); │
}                                    │
─────────────────────────────────────┼───────────────────────────────────────
❌ Repetitive property access        │  ✅ Clean, intention-revealing syntax
❌ More lines for same result        │  ✅ Fewer lines, same result
❌ Easy to mistype property names    │  ✅ Single source of truth per name
❌ Verbose function bodies           │  ✅ Self-documenting parameter shapes

Quick Reference

Syntax	What It Does
`const [a, b] = arr`	Extract by position from an array
`const [a, , c] = arr`	Skip index 1, take index 0 and 2
`const [a, ...rest] = arr`	Take first, collect the rest
`const { x, y } = obj`	Extract named properties from an object
`const { x: newName } = obj`	Extract and rename `x` to `newName`
`const { x = 5 } = obj`	Extract with a fallback default
`const { x: n = 5 } = obj`	Rename and set a default
`const { a: { b } } = obj`	Nested destructuring
`function f({ x, y }) {}`	Destructure in function parameters
`[a, b] = [b, a]`	Swap two variables

Key Takeaways

Destructuring extracts values from arrays and objects into named variables
Arrays are destructured by position using []; objects are destructured by name using {}
Use , to skip positions in array destructuring
Use : to rename a property while destructuring an object
Use = to set default values when a property might be absent
Destructuring works in function parameters, for...of loops, and nested structures
Defaults only activate for undefined — not for null, 0, or ""

What's Next?

With destructuring under your belt, these topics will click much faster:

Spread and rest operators (...) — the sibling syntax that complements destructuring
ES6 modules (import/export) — which use object destructuring syntax to import named exports
React props — nearly every React component destructures its props in the parameter list
Array methods with destructuring — combining .map(), .filter(), and destructuring for expressive data transformations

Destructuring is one of those features that, once you start using it, you'll wonder how you ever wrote JavaScript without it.

If this helped you write cleaner JavaScript, the natural next read is the spread and rest operator — same concise philosophy, even more use cases. 🚀

Destructuring in JavaScript

Akash Kumar — Fri, 26 Jun 2026 00:00:32 +0000

"Destructuring is JavaScript's way of letting you unpack what you need and leave the rest behind."

Introduction

You've worked with arrays and objects in JavaScript. You know how to access their values. But have you noticed how repetitive it gets?

const user = { name: "Alice", age: 28, city: "Delhi" };

const name = user.name;
const age  = user.age;
const city = user.city;

Three lines. Three times you wrote user.something. Now imagine doing this for an object with ten properties. Or doing it across dozens of files.

1. What Does Destructuring Mean?

Destructuring means pulling values out of a data structure and binding them to named variables, using a syntax that mirrors the shape of the data itself.

// Traditional access — fetch and assign one by one
const name = user.name;
const age  = user.age;

// Destructuring — describe the shape, get the values
const { name, age } = user;

Both do the same thing. The destructured version is just less noise.

Destructuring works on two kinds of data structures in JavaScript: objects and arrays. The syntax is slightly different for each, and for good reason.

2. Destructuring Arrays

Array destructuring uses square brackets [] on the left side of the assignment. Values are extracted by position — the first variable gets index 0, the second gets index 1, and so on.

Before vs. After

const colors = ["red", "green", "blue"];

// ❌ Before — manual index access
const first  = colors[0];
const second = colors[1];
const third  = colors[2];

// ✅ After — array destructuring
const [first, second, third] = colors;

ARRAY DESTRUCTURING — POSITIONAL MAPPING

colors  →  [ "red",  "green",  "blue" ]
                ↓        ↓        ↓
            [first, second,  third ]

first  = "red"
second = "green"
third  = "blue"

Skipping Elements

You're not forced to take every value. Leave a gap with a comma to skip positions you don't need.

const scores = [95, 82, 76, 61, 54];

// Only want first and third — skip the second
const [gold, , bronze] = scores;

console.log(gold);   // 95
console.log(bronze); // 76

The Rest Element

Capture the remaining items into a new array using the rest syntax (...).

const [top, ...rest] = [1, 2, 3, 4, 5];

console.log(top);  // 1
console.log(rest); // [2, 3, 4, 5]

Swapping Variables

One elegant trick array destructuring unlocks — swapping two variables without a temporary placeholder:

let a = 1;
let b = 2;

// ❌ Before — needs a temp variable
let temp = a;
a = b;
b = temp;

// ✅ After — one-line swap
[a, b] = [b, a];

console.log(a); // 2
console.log(b); // 1

3. Destructuring Objects

Object destructuring uses curly braces {} on the left side. Unlike arrays, values are matched by property name — not by position — so the order on the left doesn't matter.

Before vs. After

const product = {
  id: 101,
  name: "Mechanical Keyboard",
  price: 4999,
  inStock: true
};

// ❌ Before — repeated property lookups
const id      = product.id;
const name    = product.name;
const price   = product.price;
const inStock = product.inStock;

// ✅ After — object destructuring
const { id, name, price, inStock } = product;

OBJECT DESTRUCTURING — NAME-BASED EXTRACTION

product = {
  id:      101,          ──►  const id      = 101
  name:    "Keyboard",   ──►  const name    = "Keyboard"
  price:   4999,         ──►  const price   = 4999
  inStock: true          ──►  const inStock = true
}

{ id, name, price, inStock } = product
         ↑
  Matches by property name — order doesn't matter

Renaming Variables

Sometimes the property name from the object clashes with an existing variable, or just isn't descriptive enough in context. Use a colon : to rename while destructuring.

const response = { status: 200, data: { user: "Alice" } };

// Rename 'status' → 'statusCode', 'data' → 'payload'
const { status: statusCode, data: payload } = response;

console.log(statusCode); // 200
console.log(payload);    // { user: "Alice" }

// Original names (status, data) no longer exist as variables

Nested Object Destructuring

Objects inside objects can be destructured in one go by mirroring the nested shape.

const user = {
  name: "Akash",
  address: {
    city: "Patna",
    pincode: "800001"
  }
};

// ❌ Before — two-step access
const city    = user.address.city;
const pincode = user.address.pincode;

// ✅ After — nested destructuring
const { name, address: { city, pincode } } = user;

console.log(name);    // "Akash"
console.log(city);    // "Patna"
console.log(pincode); // "800001"

Note that address itself is not created as a variable here — it's only used as a path to reach city and pincode.

Destructuring in Function Parameters

const order = { id: 42, item: "Laptop", quantity: 2 };

// ❌ Before — access properties inside the function
function printOrder(order) {
  console.log(`Order #${order.id}: ${order.quantity}x ${order.item}`);
}

// ✅ After — destructure in the parameter itself
function printOrder({ id, item, quantity }) {
  console.log(`Order #${id}: ${quantity}x ${item}`);
}

printOrder(order);
// Order #42: 2x Laptop

4. Default Values

What happens when you destructure a property that doesn't exist? You get undefined. Default values let you specify a fallback for exactly that case.

Default Values in Object Destructuring

const settings = { theme: "dark" };

// 'language' doesn't exist in settings
const { theme, language } = settings;
console.log(language); // undefined ← not great

// With a default value
const { theme, language = "en" } = settings;
console.log(language); // "en" ← much better

The default only kicks in when the value is undefined — not when it's null, 0, or "".

const config = { timeout: 0, retries: null };

const { timeout = 5000, retries = 3, debug = false } = config;

console.log(timeout); // 0     ← 0 is a real value, default ignored
console.log(retries); // null  ← null is a real value, default ignored
console.log(debug);   // false ← undefined, so default applies

Default Values in Array Destructuring

const [primary = "blue", secondary = "gray"] = ["red"];

console.log(primary);   // "red"  ← value present, default ignored
console.log(secondary); // "gray" ← nothing at index 1, default applies

Combining Rename and Default

You can rename and set a default at the same time:

const user = {};

// Rename 'name' → 'username', with fallback "Guest"
const { name: username = "Guest" } = user;

console.log(username); // "Guest"

5. Benefits of Destructuring

Destructuring is more than a shorthand — it changes how you think about working with data.

Less Repetition

// ❌ Without destructuring — object name repeated everywhere
function formatAddress(location) {
  return `${location.street}, ${location.city}, ${location.state} ${location.zip}`;
}

// ✅ With destructuring — clean and flat
function formatAddress({ street, city, state, zip }) {
  return `${street}, ${city}, ${state} ${zip}`;
}

Cleaner API Responses

Real-world API responses are often deeply nested. Destructuring lets you pull out exactly what you need without intermediate variables:

// A typical API response
const response = {
  status: 200,
  data: {
    user: {
      id: 7,
      name: "Akash",
      email: "akash@example.com",
      role: "admin"
    }
  }
};

// Extract only what this function cares about
const { data: { user: { name, role } } } = response;

console.log(name); // "Akash"
console.log(role); // "admin"

Readable Function Return Values

Destructuring makes functions that return multiple values feel natural:

function getMinMax(numbers) {
  return {
    min: Math.min(...numbers),
    max: Math.max(...numbers)
  };
}

// Named return values — no [0] and [1] guessing
const { min, max } = getMinMax([3, 1, 9, 4, 7]);

console.log(min); // 1
console.log(max); // 9

Works Beautifully with Loops

const users = [
  { id: 1, name: "Alice", role: "admin" },
  { id: 2, name: "Bob",   role: "viewer" },
  { id: 3, name: "Carol", role: "editor" }
];

// Destructure each object directly in the loop
for (const { name, role } of users) {
  console.log(`${name} is a ${role}`);
}

// Alice is a admin
// Bob is a viewer
// Carol is a editor

Before vs. After: A Full Comparison

WITHOUT DESTRUCTURING                │  WITH DESTRUCTURING
─────────────────────────────────────┼───────────────────────────────────────
const name    = user.name;           │  const {
const age     = user.age;            │    name,
const city    = user.city;           │    age,
const country = user.country;        │    city,
                                     │    country
                                     │  } = user;
─────────────────────────────────────┼───────────────────────────────────────
const r = rgb[0];                    │  const [r, g, b] = rgb;
const g = rgb[1];                    │
const b = rgb[2];                    │
─────────────────────────────────────┼───────────────────────────────────────
function greet(user) {               │  function greet({ name, age = 0 }) {
  const name = user.name;            │    console.log(`Hi ${name}, ${age}`);
  const age  = user.age || 0;        │  }
  console.log(`Hi ${name}, ${age}`); │
}                                    │
─────────────────────────────────────┼───────────────────────────────────────
❌ Repetitive property access        │  ✅ Clean, intention-revealing syntax
❌ More lines for same result        │  ✅ Fewer lines, same result
❌ Easy to mistype property names    │  ✅ Single source of truth per name
❌ Verbose function bodies           │  ✅ Self-documenting parameter shapes

Quick Reference

Syntax	What It Does
`const [a, b] = arr`	Extract by position from an array
`const [a, , c] = arr`	Skip index 1, take index 0 and 2
`const [a, ...rest] = arr`	Take first, collect the rest
`const { x, y } = obj`	Extract named properties from an object
`const { x: newName } = obj`	Extract and rename `x` to `newName`
`const { x = 5 } = obj`	Extract with a fallback default
`const { x: n = 5 } = obj`	Rename and set a default
`const { a: { b } } = obj`	Nested destructuring
`function f({ x, y }) {}`	Destructure in function parameters
`[a, b] = [b, a]`	Swap two variables

Key Takeaways

Destructuring extracts values from arrays and objects into named variables
Arrays are destructured by position using []; objects are destructured by name using {}
Use , to skip positions in array destructuring
Use : to rename a property while destructuring an object
Use = to set default values when a property might be absent
Destructuring works in function parameters, for...of loops, and nested structures
Defaults only activate for undefined — not for null, 0, or ""

What's Next?

With destructuring under your belt, these topics will click much faster:

Spread and rest operators (...) — the sibling syntax that complements destructuring
ES6 modules (import/export) — which use object destructuring syntax to import named exports
React props — nearly every React component destructures its props in the parameter list
Array methods with destructuring — combining .map(), .filter(), and destructuring for expressive data transformations

Destructuring is one of those features that, once you start using it, you'll wonder how you ever wrote JavaScript without it.

If this helped you write cleaner JavaScript, the natural next read is the spread and rest operator — same concise philosophy, even more use cases. 🚀

What is Middleware in Express and How It Works

Akash Kumar — Thu, 25 Jun 2026 15:59:17 +0000

"Middleware is the invisible assembly line your request travels through before it ever reaches your route."

Introduction

You've set up an Express server. You have routes. Things work. But then real-world requirements show up — you need to log every incoming request, verify that users are authenticated, validate request bodies, handle errors gracefully. Where does all that logic go?

The answer is middleware — one of the most powerful and fundamental concepts in Express.js. Once you understand middleware, you stop writing tangled route handlers and start building clean, composable server applications.

This guide walks through what middleware is, how it fits into the request lifecycle, the different types available, and how to use it in practice.

1. What Is Middleware?

In Express, middleware is a function that has access to the request object (req), the response object (res), and a special function called next().

Every middleware function can do one of three things:

Execute any code — logging, validation, authentication checks
Modify req or res — attach data, set headers, parse a body
End the request-response cycle — send back a response and stop
Call next() — pass control to the next middleware in line

Think of middleware as a series of checkpoints a request must pass through before it reaches its final destination — your route handler.

// The shape of every middleware function
function myMiddleware(req, res, next) {
  // Do something with the request or response
  console.log("Checkpoint reached!");

  // Then either end the cycle...
  // res.send("Stopped here");

  // ...or pass control to the next middleware
  next();
}

2. Where Middleware Sits in the Request Lifecycle

Every time a client sends a request to your Express server, that request doesn't jump straight to your route handler. It travels through a pipeline — a chain of middleware functions executed in order, one after another.

CLIENT REQUEST
     │
     ▼
┌─────────────────────────────────────────────────────────────┐
│                   EXPRESS APPLICATION                       │
│                                                             │
│  ┌──────────────┐   ┌──────────────┐   ┌────────────────┐  │
│  │  Middleware  │   │  Middleware  │   │  Middleware    │  │
│  │      1       │──►│      2       │──►│       3        │  │
│  │   (logger)   │   │   (auth)     │   │  (validator)   │  │
│  └──────────────┘   └──────────────┘   └────────────────┘  │
│         │                 │                    │            │
│     next() called     next() called        next() called   │
│                                                 │           │
│                                        ┌────────────────┐  │
│                                        │  Route Handler │  │
│                                        │  GET /profile  │  │
│                                        └────────────────┘  │
│                                                 │           │
└─────────────────────────────────────────────────┼───────────┘
                                                  │
                                                  ▼
                                           CLIENT RESPONSE

Each middleware in the chain either passes the baton (calls next()) or ends the race (sends a response). If a middleware doesn't call next() and doesn't send a response, the request just... hangs. That's a bug worth memorizing.

The pipeline analogy: Imagine your request is water flowing through pipes. Each pipe fitting (middleware) can filter it, add something to it, or block it entirely. Your route handler is the tap at the end — it only receives water that made it through every fitting before it.

3. Types of Middleware in Express

Express organizes middleware into four categories. Understanding which type to reach for is key to keeping your code organized.

Application-Level Middleware

This middleware is bound directly to your app instance using app.use() or app.METHOD(). It runs for every request that matches its path (or all requests, if no path is given).

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

// Runs on EVERY incoming request (no path specified)
app.use((req, res, next) => {
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
  next();
});

// Runs only for requests to /dashboard and its sub-paths
app.use("/dashboard", (req, res, next) => {
  console.log("Dashboard section accessed");
  next();
});

When to use it: Global concerns — logging, parsing request bodies, setting security headers — anything that should run across all (or most) routes.

Router-Level Middleware

Router-level middleware works identically to application-level middleware, but it's bound to an Express Router instance (express.Router()). This lets you group related routes and their middleware together into modular units.

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

// Middleware scoped only to this router
router.use((req, res, next) => {
  console.log("User router middleware running");
  next();
});

router.get("/profile", (req, res) => {
  res.send("User profile page");
});

router.get("/settings", (req, res) => {
  res.send("User settings page");
});

// Mount the router on the app
app.use("/users", router);

When to use it: Feature-specific concerns — auth checks that only apply to /admin routes, validation that only applies to /api routes. Keeps your app.js clean and each feature self-contained.

Built-in Middleware

Express ships with a small set of built-in middleware functions that handle common tasks out of the box.

// Parse incoming JSON request bodies
// Attaches parsed data to req.body
app.use(express.json());

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

// Serve static files (HTML, CSS, images) from a directory
app.use(express.static("public"));

These three cover the vast majority of what you need for a standard web application or REST API. Always add express.json() before any route that expects a JSON body — otherwise req.body will be undefined.

When to use it: Body parsing and static file serving. These almost always appear at the top of every Express application.

Error-Handling Middleware

Error-handling middleware has a special signature — it takes four parameters: (err, req, res, next). Express recognizes the four-argument signature and only calls this middleware when an error occurs.

// Must be registered LAST, after all other app.use() and routes
app.use((err, req, res, next) => {
  console.error("Error caught:", err.message);
  res.status(err.status || 500).json({
    error: err.message || "Internal Server Error"
  });
});

To trigger it from anywhere in your application, call next(error) and pass an error object:

app.get("/data", (req, res, next) => {
  try {
    // Something that might fail
    const result = riskyOperation();
    res.json(result);
  } catch (err) {
    next(err); // Skips all regular middleware and jumps to error handler
  }
});

When to use it: Centralizing error responses. Without it, you'd write the same res.status(500) block in every route.

4. Execution Order: Order Is Everything

Middleware in Express runs in the exact order it is registered. This is not a minor implementation detail — it's the defining rule of the middleware system.

const app = express();

app.use((req, res, next) => {
  console.log("Step 1: Logger");
  next();
});

app.use((req, res, next) => {
  console.log("Step 2: Auth check");
  next();
});

app.use((req, res, next) => {
  console.log("Step 3: Request validation");
  next();
});

app.get("/profile", (req, res) => {
  console.log("Step 4: Route handler");
  res.send("Profile data");
});

// Console output for GET /profile:
// Step 1: Logger
// Step 2: Auth check
// Step 3: Request validation
// Step 4: Route handler

A common source of bugs is registering middleware after the routes it's meant to protect. If you put your auth check below your route, it simply won't run for that route.

// ❌ WRONG — auth middleware registered too late
app.get("/secret", (req, res) => res.send("Secret data"));
app.use(authMiddleware); // This never runs for /secret

// ✅ CORRECT — auth middleware registered before the route
app.use(authMiddleware);
app.get("/secret", (req, res) => res.send("Secret data"));

5. The Role of `next()`

next() is the function that keeps the pipeline moving. Without it, your request stalls permanently.

Middleware calls next()   →  Next middleware runs
Middleware sends response →  Pipeline ends (no more middleware runs)
Middleware does neither   →  Request hangs forever (a bug)

Passing an Error with `next(err)`

Calling next() with no argument moves to the next regular middleware. Calling next(err) with an argument skips all regular middleware and jumps directly to the nearest error-handling middleware.

// Middleware chain execution paths:

//  next()          ──►  Next regular middleware or route handler
//  next(new Error) ──►  Skips everything → error handler
//  res.send()      ──►  Ends the request-response cycle entirely

function checkApiKey(req, res, next) {
  const apiKey = req.headers["x-api-key"];

  if (!apiKey) {
    // Skip remaining middleware, jump to error handler
    return next(new Error("API key required"));
  }

  // All good — continue down the chain
  next();
}

Always return when calling next() early. Without return, the rest of the middleware function keeps executing after next(), which can cause double-response errors (Cannot set headers after they are sent).

6. Real-World Examples

Logging Middleware

Logs every request with its method, URL, and how long the server took to respond.

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

  // Hook into the response finish event to capture response time
  res.on("finish", () => {
    const duration = Date.now() - start;
    console.log(
      `${req.method} ${req.url} → ${res.statusCode} (${duration}ms)`
    );
  });

  next(); // Always call next — logger should never block a request
}

app.use(requestLogger);

// Output example:
// GET /users → 200 (14ms)
// POST /login → 401 (3ms)
// GET /profile → 200 (22ms)

Authentication Middleware

Checks for a valid JWT token in the Authorization header. Blocks the request with a 401 if invalid, or attaches the decoded user to req.user and continues.

const jwt = require("jsonwebtoken");

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

  // Check header exists and has the right format
  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    return res.status(401).json({ error: "No token provided" });
  }

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

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded; // Attach user data for downstream handlers
    next();
  } catch (err) {
    return res.status(401).json({ error: "Invalid or expired token" });
  }
}

// Applied selectively to protected routes only
app.get("/profile", authenticate, (req, res) => {
  res.json({ message: `Welcome, ${req.user.name}!` });
});

app.get("/settings", authenticate, (req, res) => {
  res.json({ settings: getUserSettings(req.user.id) });
});

Request Validation Middleware

Validates that a request body contains the required fields before it reaches the route handler. Returns a descriptive 400 error if anything is missing.

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

  if (!name || name.trim().length < 2) {
    errors.push("Name must be at least 2 characters");
  }

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

  if (!password || password.length < 8) {
    errors.push("Password must be at least 8 characters");
  }

  if (errors.length > 0) {
    // Stop here — don't let invalid data reach the route handler
    return res.status(400).json({ errors });
  }

  next(); // Validation passed — continue
}

app.post("/register", validateRegistration, (req, res) => {
  // If we're here, req.body is guaranteed to be valid
  const user = createUser(req.body);
  res.status(201).json(user);
});

Putting It All Together

Here's how a realistic Express application composes all of these middleware types in the correct order:

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

// ── 1. Built-in middleware (always first) ──────────────────────
app.use(express.json());
app.use(express.urlencoded({ extended: true }));

// ── 2. Application-level middleware (global) ───────────────────
app.use(requestLogger);

// ── 3. Public routes (no auth required) ───────────────────────
app.post("/register", validateRegistration, registerUser);
app.post("/login", loginUser);

// ── 4. Protected routes (auth required) ───────────────────────
app.use("/api", authenticate);       // All /api/* routes are protected
app.get("/api/profile", getProfile);
app.put("/api/settings", updateSettings);

// ── 5. Error handler (always last) ────────────────────────────
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(err.status || 500).json({ error: err.message });
});

app.listen(3000);

Quick Reference

Middleware Type	Bound To	Typical Use
Application-level	`app.use()`	Logging, body parsing, global auth
Router-level	`router.use()`	Feature-scoped logic (admin, API)
Built-in	`app.use()`	JSON parsing, static files
Error-handling	`app.use(err, req, res, next)`	Centralized error responses

`next()` Call	What Happens
`next()`	Move to the next middleware or route handler
`next(err)`	Skip to the nearest error-handling middleware
`res.send()` / `res.json()`	End the request-response cycle
Nothing called	Request hangs — always a bug

Key Takeaways

Middleware functions run in registration order — sequence matters
Every middleware must either call next() or send a response — never neither
Use return next() to prevent code from continuing after passing control
Use next(err) to trigger your centralized error handler
Built-in middleware (express.json()) should be registered before any routes that need it
Error-handling middleware (err, req, res, next) must always be last

What's Next?

Now that you have a solid foundation in Express middleware, great next steps include:

Third-party middleware — helmet for security headers, cors for cross-origin requests, morgan for production-grade logging
express-validator — a dedicated library for request validation with a clean, chainable API
Rate limiting — using express-rate-limit to protect routes from abuse
Async middleware — wrapping async functions cleanly so errors are always caught

Middleware is the architecture that separates a prototype from a production application. Master the pipeline, and your Express code will be cleaner, safer, and far easier to maintain.

If this clicked for you, the next read is async/await error handling in Express — because try/catch in every route handler is its own kind of callback hell. 🚀

JavaScript Promises Explained for Beginners

Akash Kumar — Thu, 25 Jun 2026 15:53:23 +0000

Introduction

If you spent anytime writing JavaScript, you've almost certainly beyond into a asynchronous code - code that doesn't run top-to-bottom instantly, but instead waits on something (a server response, a timer, a file read). For years, managers developed this with callbacks, and it worked... untill it didn't.

Enter Promises - a cleaner, more readable, and far more managebale way to handle async operations in JavaScript.

This guide will walk you through everything you need to understand promises from the ground up: what problems they solve, how they work under the hood, and how to use them effectively.

1. What Problem do Promises Solve?

To understand Promises, you first need to feel the pain they eliminated.

The Old Way: Callbacks

A callback is simply a function you pass into another function, to be called once the asynchronous work is done.

// Fetching a user, then their posts, then the comments on the first post
getUser(userId, function(user) {
  getPosts(user.id, function(posts) {
    getComments(posts[0].id, function(comments) {
      displayComments(comments, function() {
        // We're four levels deep... and this is a simple example
        console.log("Done!");
      });
    });
  });
});

This deeply nested structure is affectionately (and painfully) known as "Callback Hell" or the Pyramid of Doom.

The problem with callbacks:

Hard to read - logic is buried inside nested indentation
Hard to debug - error handling must be manually wired at every level
Hard to maintain - adding a new step means restructuring the whole pyramid
No composability - you can't easily reuse or chain operations

The Promise Key

getUser(userId)
  .then(user => getPosts(user.id))
  .then(posts => getComments(posts[0].id))
  .then(comments => displayComments(comments))
  .then(() => console.log("Done!"))
  .catch(error => console.error("Something went wrong:", error));

Flat. Linear. Readable. One centralized error handler at the bottom. This is what Promises give you.

2. Promise States: The Three Phases of a Promise

Every Promise exists in exactly one of three states at any given moment:

┌─────────────────────────────────────────────────────────────┐
│                     PROMISE LIFECYCLE                       │
│                                                             │
│    ┌───────────┐    resolve()    ┌─────────────┐           │
│    │           │ ─────────────► │  FULFILLED  │           │
│    │  PENDING  │                └─────────────┘           │
│    │           │    reject()    ┌─────────────┐           │
│    │ (initial) │ ─────────────► │  REJECTED   │           │
│    └───────────┘                └─────────────┘           │
│                                                             │
│    • Pending   → The operation is still in progress        │
│    • Fulfilled → The operation completed successfully       │
│    • Rejected  → The operation failed                       │
│                                                             │
│    Once settled (fulfilled OR rejected), a Promise         │
│    is IMMUTABLE — its state can never change again.        │
└─────────────────────────────────────────────────────────────┘

State	Meaning	Has a value?
Pending	The async operation is still running	No
Fulfilled	The operation succeeded	Yes — the resolved value
Rejected	The operation failed	Yes — the reason/error

Key insight: Once a Promise transitions from pending to either fulfilled or rejected, it is settled and its state is locked forever. This immutability is what makes Promises predictable and trustworthy.

3. The Basic Promise Lifecycle

Creating a Promise

You create a Promise with the new Promise() constructor, which takes an executor function — a function that receives two arguments: resolve and reject.

const myPromise = new Promise((resolve, reject) => {
  // Simulate an async operation (e.g., a network request)
  const success = true;

  if (success) {
    resolve("Here is your data! ✅"); // Fulfills the promise
  } else {
    reject("Something went wrong ❌"); // Rejects the promise
  }
});

Think of the executor as the actual async work being done. When it succeeds, you call resolve(value). When it fails, you call reject(reason).

A Real-World Analogy

Imagine ordering a pizza:

You place your order — the Promise is pending
The pizza arrives at your door — the Promise is fulfilled (with the pizza as the value)
The restaurant calls to say they're closed — the Promise is rejected (with the reason as the error) You don't sit at the restaurant waiting. You go about your day and react when something happens. That's asynchronous programming — and that's Promises.

4. Handling Success and Failure

`.then()` — Handling Success

The .then() method is called when a Promise fulfills. It receives the resolved value as its argument.

const fetchUser = new Promise((resolve, reject) => {
  // Pretending to fetch from a server
  setTimeout(() => {
    resolve({ id: 1, name: "Alice" });
  }, 1000);
});

fetchUser.then(user => {
  console.log("Got user:", user.name); // "Got user: Alice"
});

`.catch()` — Handling Failure

The .catch() method is called when a Promise rejects. It receives the rejection reason (usually an error).

const fetchUser = new Promise((resolve, reject) => {
  setTimeout(() => {
    reject(new Error("User not found"));
  }, 1000);
});

fetchUser.catch(error => {
  console.error("Failed:", error.message); // "Failed: User not found"
});

`.finally()` — Always Runs

The .finally() method runs regardless of whether the Promise fulfilled or rejected — perfect for cleanup tasks like hiding a loading spinner.

fetchUser
  .then(user => console.log("User:", user))
  .catch(error => console.error("Error:", error))
  .finally(() => {
    console.log("Request complete — hide the spinner!");
  });

5. Promise Chaining: The Real Superpower

Promise chaining is where things get truly powerful. Because .then() always returns a new Promise, you can chain multiple .then() calls in sequence — each one receiving the result of the previous.

How Chaining Works

┌──────────┐   .then()   ┌──────────┐   .then()   ┌──────────┐
│ Promise  │ ──────────► │ Promise  │ ──────────► │ Promise  │
│    1     │             │    2     │             │    3     │
│(fetch    │             │(process  │             │(display  │
│  data)   │             │  data)   │             │  result) │
└──────────┘             └──────────┘             └──────────┘
                                                        │
                              ┌─────────────────────────┘
                              │   .catch() handles
                              ▼   errors from any step
                         ┌──────────┐
                         │  .catch  │
                         │ (errors) │
                         └──────────┘

A Practical Example

// Each .then() receives the return value of the previous step
fetch("https://api.example.com/users/1")
  .then(response => {
    // Step 1: Convert the raw response to JSON
    return response.json();
  })
  .then(user => {
    // Step 2: Use the user data to fetch their posts
    console.log("User found:", user.name);
    return fetch(`https://api.example.com/posts?userId=${user.id}`);
  })
  .then(response => {
    // Step 3: Convert posts response to JSON
    return response.json();
  })
  .then(posts => {
    // Step 4: Display the posts
    console.log("Posts:", posts);
  })
  .catch(error => {
    // One catch handles errors from ANY step above
    console.error("Something failed:", error.message);
  });

The key rules of chaining:

Whatever you return from a .then() becomes the input to the next .then()
If you return a Promise, the chain waits for it to settle before proceeding

- A single `.catch()` at the end handles errors bubbled up from any step in the chain

Callback Hell vs. Promise Chains: A Side-by-Side

CALLBACK HELL                    │  PROMISE CHAIN
─────────────────────────────────┼──────────────────────────────────
step1(data, function(r1) {       │  step1(data)
  if (err) handle(err);          │    .then(r1 => step2(r1))
  step2(r1, function(r2) {       │    .then(r2 => step3(r2))
    if (err) handle(err);        │    .then(r3 => step4(r3))
    step3(r2, function(r3) {     │    .catch(err => handle(err));
      if (err) handle(err);      │
      step4(r3, function(r4) {   │  ✅ Flat and readable
        if (err) handle(err);    │  ✅ One error handler
        // We're here now        │  ✅ Easy to add/remove steps
      });                        │  ✅ Each step is a clear action
    });                          │
  });                            │
});                              │
                                 │
❌ Deeply nested                 │
❌ Error handling repeated       │
❌ Hard to add steps             │
❌ Reads bottom-to-top           │

Quick Summary

Concept	What it means
Promise	An object representing a future value — it will either succeed or fail
Pending	The initial state; the async work is still happening
Fulfilled	The work succeeded; a resolved value is available
Rejected	The work failed; an error reason is available
`.then()`	Runs when the Promise fulfills; receives the resolved value
`.catch()`	Runs when the Promise rejects; receives the error
`.finally()`	Always runs after settled, regardless of outcome
Chaining	Linking `.then()` calls sequentially for multi-step async flows

What's Next?

Now that you understand the fundamentals of Promises, you're ready to explore:

async/await — syntactic sugar built on top of Promises that makes async code look even more like synchronous code
Promise.all() — run multiple Promises in parallel and wait for all to finish
Promise.race() — resolve or reject as soon as the first Promise settles
Promise.allSettled() — wait for all Promises to settle, even if some reject Promises are the foundation of modern JavaScript async programming. Master them here, and everything else — including async/await — will click into place naturally.

DEV Community: Akash Kumar

How ChatGPT Understands Your Questions?

1. What is an LLM?

What problems do LLMs solve?

Popular examples of LLMs

Common applications in daily life

2. What Happens When You Send a Message to ChatGPT?

Step 1 — Typing a prompt

Step 2 — Processing your message

Step 3 — Generating a response

Step 4 — Why responses aren't copied from the internet

3. Why Computers Don't Understand Human Language

Text vs numbers

Why computers need everything converted into numbers

Introduction to tokens

4. Tokenization

What tokens are

Why tokenization is needed

Simple example — full sentence

5. Transformers

What a Transformer is

Why it changed AI

How it helps understand language

Why almost every modern LLM uses Transformers

Putting It All Together — The Complete Workflow

Bonus concept: the context window

Bonus concept: temperature

Wrapping Up

Securing Apps: Password Hashing, RBAC, OAuth, and OpenID Connect

Introduction: How Does a Website Know Who You Are?

1. Why Application Security Matters

Common Security Risks in Web Applications

Authentication vs Authorization: Two Different Problems

The Cost of Insecure Systems

2. Password Hashing and Storage

Why Passwords Should Never Be Stored in Plain Text

What Hashing Is

The Problem with Simple Hashing: Rainbow Tables

How bcrypt Solves Both Problems

Password Verification Process

Best Practices for Password Storage

3. Authentication vs Authorization

What Authentication Means

What Authorization Means

Why Applications Need Both

Everyday Examples

4. Role-Based Access Control (RBAC)

What RBAC Is

Users, Roles, and Permissions

Role Hierarchy Example: Blog Platform

Implementing RBAC in Express

Scaling Permissions in Large Applications

5. OAuth 2.0 Explained

The Problem OAuth Solves

The Four Actors in OAuth

The Authorization Code Flow

Access Tokens and Scopes

Real-World Example: "Login with GitHub"

6. OpenID Connect (OIDC)

What OAuth 2.0 Is Missing

How OIDC Extends OAuth

The OIDC Flow

Authentication vs Authorization in OIDC

Why OIDC Matters for Modern Applications

7. Modern Authentication Architecture

From Traditional to Modern

Social Login

Single Sign-On (SSO)

Authentication in Modern SaaS Products

8. Security Best Practices

Strong Password Policies

Multi-Factor Authentication (MFA)

Token Expiration and Refresh Strategy

Principle of Least Privilege

Protecting Sensitive Routes

Secure Storage of Credentials

Security Layers in a Complete Application

Quick Reference

Key Takeaways

What's Next?