DEV Community: Janmejai Singh

What is Middleware in Express and How It Works

Janmejai Singh — Tue, 30 Jun 2026 16:59:04 +0000

What Is Middleware in Express, and How Does It Actually Work?

If you've spent any time with Express.js, you've probably written code like app.use(something) dozens of times without fully stopping to ask: what is that, exactly? It's not a route. It's not quite a controller. It just... sits there, quietly doing something to every request that passes through.

That "something" is middleware, and it's arguably the single most important concept to understand if you want Express to stop feeling like a black box. Once it clicks, you'll start seeing the entire framework differently — as a pipeline you control, one checkpoint at a time.

Middleware as a Checkpoint Between Request and Response

Here's the simplest way to picture it: imagine an airport. A passenger (the request) doesn't walk straight from the front door to their airplane seat (the response). They pass through a series of checkpoints along the way — check-in, security screening, passport control, boarding gate. Each checkpoint inspects, modifies, logs, or sometimes outright stops the passenger before letting them continue to the next one.

Middleware in Express is exactly that: a function sitting between the incoming request and the final response, given a chance to inspect or modify things, run some logic, and then either pass the request along to the next checkpoint or stop it right there.

Formally, an Express middleware function is just a function with this shape:

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

Three ingredients, every time: the request object, the response object, and a special function called next. That third one is doing more work than it looks like, and we'll come back to it shortly.

Where Middleware Sits in the Request Lifecycle

When a request hits your Express app, it doesn't go straight to a route handler. It travels through a pipeline — a sequence of middleware functions, registered in the order you defined them, each one getting a turn before the request (assuming it survives that long) finally reaches the route handler responsible for sending a response.

Picture the flow like this:

Incoming Request
      |
      v
 [ Middleware 1 ]  --(calls next())-->
      |
      v
 [ Middleware 2 ]  --(calls next())-->
      |
      v
 [ Route Handler ] --(sends response)
      |
      v
   Response sent back to client

This is why Express is often described as having a request pipeline — your request flows through a chain of functions, and each one gets to decide: keep going, stop here, or branch off entirely (say, by sending an error response early).

Types of Middleware in Express

Not all middleware is registered the same way or applies to the same scope. Express groups middleware into a few practical categories.

Application-Level Middleware

This is middleware attached directly to your main app object using app.use() or app.METHOD() (like app.get()). It applies broadly — often to every request that comes into your app, unless you scope it to a specific path.

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

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

This is your go-to for things that should happen on basically every request — logging, setting common headers, parsing request bodies, and so on.

Router-Level Middleware

Sometimes you don't want middleware applying app-wide — you want it scoped to a specific group of routes. That's where express.Router() comes in. You attach middleware to a router instance instead of the whole app, and it only runs for requests handled by that router.

const router = express.Router();

router.use((req, res, next) => {
  console.log('A request hit the /users router');
  next();
});

router.get('/users/:id', (req, res) => {
  res.send('User profile');
});

This is especially handy for feature-specific logic — like requiring authentication only on /admin routes, without affecting your public-facing pages at all.

Built-In Middleware

Express also ships with a small set of middleware functions out of the box, so you don't have to reinvent common functionality. The most commonly used one is express.json(), which parses incoming JSON request bodies and makes them available on req.body.

app.use(express.json());

There's also express.static(), which serves static files (images, CSS, client-side JS) directly from a folder, without you needing to write any custom file-serving logic yourself.

Execution Order of Middleware

This part trips up a lot of beginners, so it's worth saying plainly: middleware runs in the exact order you register it, top to bottom. Express doesn't reorder, prioritize, or guess — it simply walks down your stack of app.use() and route definitions, one at a time.

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

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

app.get('/dashboard', (req, res) => {
  console.log('3: Route handler');
  res.send('Welcome to your dashboard');
});

For a request to /dashboard, the console output will always read 1, then 2, then 3 — never out of order. This is exactly like the airport checkpoints: you can't reach passport control before you've gone through security, simply because of the order the checkpoints are physically placed in.

This ordering matters a lot in practice. If you register a body-parsing middleware after a route handler that depends on req.body, that route will see undefined — because the parser never got a chance to run first.

The Role of `next()`

Now, back to that mysterious third argument. The next() function is what makes the pipeline actually move. Calling next() tells Express: "I'm done with my part — pass this request on to whatever's next in line."

If a middleware function never calls next() (and never sends a response either), the request simply hangs forever. The client's browser or app sits there waiting, because nothing ever told Express to move on or respond.

This gives middleware real power, though — it can also choose not to call next(), and instead end the chain itself:

function requireAuth(req, res, next) {
  if (!req.headers.authorization) {
    return res.status(401).send('Unauthorized'); // chain stops here
  }
  next(); // only continues if authorized
}

This is the checkpoint analogy in its purest form: a security checkpoint that decides a passenger isn't allowed through simply doesn't let them proceed — it stops them right there, instead of waving them on to the gate.

Real-World Examples of Middleware in Action

Theory aside, here's where middleware earns its keep in almost every real Express app.

Logging

Tracking what's happening in your app — which routes are getting hit, by what method, when — is a textbook middleware job, since it needs to run on every request without cluttering up your actual route logic.

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

Authentication

Checking whether a user is logged in (or has the right permissions) before letting them reach a protected route is one of the most common real-world uses of middleware, exactly like the requireAuth example above. Instead of repeating that check inside every single route handler, you write it once and apply it wherever it's needed.

Request Validation

Before your route handler even touches incoming data, middleware can check that it's actually shaped the way you expect — required fields present, correct types, no garbage data sneaking through.

function validateSignup(req, res, next) {
  const { email, password } = req.body;
  if (!email || !password) {
    return res.status(400).send('Email and password are required');
  }
  next();
}

app.post('/signup', validateSignup, (req, res) => {
  res.send('Account created!');
});

Notice that last example — middleware doesn't only get registered with app.use(). You can also slot it directly into a single route's argument list, applying it to just that one path.

Visualizing It All Together

Put the pieces together, and a typical request through a well-structured Express app looks like a chain:

Request
  → Logging middleware (records the request)
  → express.json() (parses the body)
  → Auth middleware (checks if user is allowed through)
  → Validation middleware (checks the data shape)
  → Route handler (does the actual work, sends response)

Each link in that chain does exactly one job, calls next() when it's satisfied, and trusts the next link to handle its own responsibility. That's the real elegance of middleware — it lets you break a complex request-handling process into small, focused, reusable pieces instead of one giant tangled route handler trying to do everything at once.

Wrapping Up

Middleware is Express's way of turning request handling into a pipeline of checkpoints rather than one big monolithic function. Application-level middleware applies broadly, router-level middleware applies to a specific group of routes, and built-in middleware handles common needs out of the box — and all of it runs strictly in the order you register it, moving forward only when next() is called. Once you start thinking in terms of "what checkpoint does this logic belong at," patterns like logging, authentication, and validation stop feeling like separate, special-case features and start feeling like exactly what they are: just more middleware in the chain.

Curious about error-handling middleware, or how middleware works differently in newer frameworks built on Express? Drop a comment below — I read every one.

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

Janmejai Singh — Tue, 30 Jun 2026 16:52:31 +0000

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

Every app with a login page has to solve the same quiet little problem over and over: a user logs in once, but HTTP itself has no memory. Every request is a stranger knocking on the door, with no idea if it's the same person who knocked five seconds ago. So how does your app remember "yep, this is still that logged-in user" across dozens of requests?

That's the whole job of authentication systems built around sessions, cookies, and JWTs — three terms that get thrown around together so often that beginners (reasonably) assume they're competing options. They're not quite that simple. Let's untangle them one at a time, then see how they actually relate to each other.

What Cookies Are

Let's start with the simplest piece: a cookie is just a small piece of data that a server asks the browser to store, and the browser then automatically sends back with every future request to that same site.

Think of a cookie like a wristband at a festival. Once you get scanned at the entrance, staff snap a wristband on you. You don't have to show your ticket again at every stage — you just flash the wristband, and every checkpoint trusts it. The browser is the wrist wearing it, and it shows that wristband (the cookie) automatically on every request, without you doing anything manually.

Cookies themselves don't decide who you are — they're just a delivery mechanism. What actually goes inside that cookie is where sessions and JWTs come in.

What Sessions Are

A session is server-side memory about a logged-in user. When you log in successfully, the server creates a record — somewhere in its memory, a database, or a cache like Redis — that essentially says, "this specific session ID belongs to this specific user, and they're authenticated."

The server then sends a cookie back to the browser containing nothing more than that session ID — a random, meaningless-looking string. On every future request, the browser sends that cookie back, and the server looks up the ID in its own storage to figure out who's making the request.

Going back to the festival analogy: the wristband itself (the cookie) doesn't have your name printed on it. It just has a barcode. The festival staff (the server) scan that barcode and look it up in their own system to pull up your details. The wristband is meaningless without the server's internal records.

This is why session-based authentication is described as stateful — the server has to actively hold onto state (the session data) for every logged-in user.

What JWT Tokens Are

A JWT (JSON Web Token) takes a fundamentally different approach. Instead of the server storing user info and handing out a meaningless reference ID, a JWT packs the actual user information directly into the token itself — and then cryptographically signs it, so the server can later verify the token hasn't been tampered with, without needing to look anything up in storage.

A JWT typically looks like a long string with three dot-separated parts (header, payload, signature), and that payload often contains things like a user ID, role, or expiration time — readable information, not a random reference number.

Here's the analogy shift: instead of a wristband with a barcode the staff have to scan and look up, imagine a laminated ID badge that already has your name, your access level, and a tamper-proof hologram printed directly on it. Anyone with a badge scanner can verify it's authentic just by checking the hologram — no need to call back to a central database to ask "who is this, again?"

That's the core idea behind JWTs being stateless — the server doesn't need to store anything about your session. The token carries everything it needs, and the server just verifies the signature is valid.

Stateful vs Stateless Authentication

This stateful-vs-stateless distinction is really the heart of the whole comparison, so it's worth sitting with it directly.

Stateful authentication (the session approach) means the server is the source of truth, and it actively remembers every logged-in user. Want to instantly log someone out, everywhere, right now? Easy — just delete their session record from storage, and that session ID becomes worthless immediately.

Stateless authentication (the JWT approach) means the server doesn't remember anything between requests. Each token is self-contained proof of identity, verified purely through its cryptographic signature. This is great for scaling — any server in a cluster can verify a token without needing shared access to a central session store — but it comes with a trade-off: since the server isn't tracking active tokens, instantly revoking a single token before it naturally expires is genuinely awkward, and usually requires extra infrastructure (like a blocklist) that partially undoes the "stateless" benefit.

Session-Based Auth vs JWT: A Side-by-Side Comparison

	Session-Based Auth	JWT-Based Auth
Where user data lives	Stored server-side (memory, database, or cache)	Packed directly inside the token itself
What the cookie holds	A random session ID (meaningless on its own)	Often the full token, or a reference to it
State	Stateful — server actively tracks sessions	Stateless — server verifies, doesn't store
Scaling across multiple servers	Needs a shared session store (e.g., Redis) so every server can look up the same session	Easy — any server can verify the token's signature independently
Revoking access instantly	Simple — delete the session record	Harder — token stays valid until it expires, unless you add a blocklist
Typical size sent per request	Small (just an ID)	Larger (full encoded payload)
Common use case	Traditional web apps with server-rendered pages	APIs, mobile apps, microservices, single-page apps

When to Use Each Method

Neither approach is "better" in some absolute sense — they fit different shapes of application.

Reach for session-based authentication when:

You're building a traditional server-rendered web app (think: a classic Express + EJS/Handlebars app, or a monolith).
You need the ability to instantly revoke a user's access — banning a user, forcing a logout after a password change, etc.
Your app runs on infrastructure where setting up a shared session store (like Redis) isn't a big lift.

Reach for JWT-based authentication when:

You're building an API consumed by multiple clients — a mobile app, a single-page app, third-party integrations — where a shared session store would add friction.
Your backend is split across multiple independent services (microservices) that all need to verify identity without constantly calling back to one central auth server.
Instant revocation isn't a hard requirement, and short token expiration times (paired with refresh tokens) are an acceptable trade-off.

A lot of modern full-stack apps actually blend the two: short-lived JWTs for fast, stateless verification, paired with a refresh-token mechanism that behaves a lot like a session behind the scenes. Understanding why each piece exists makes those hybrid setups far less confusing the next time you encounter one in a real codebase.

Visualizing the Two Flows

It helps to picture both flows side by side:

Session authentication flow: User logs in → server creates a session record and stores it → server sends back a cookie containing just the session ID → on every future request, the browser sends that cookie → server looks up the ID in its storage → server confirms identity and responds.

JWT authentication flow: User logs in → server creates a signed token containing user info → server sends the token to the client → client stores it and attaches it to future requests (commonly via an Authorization header) → server verifies the token's signature directly, with no storage lookup needed → server trusts the payload and responds.

The key visual difference: the session flow has a constant "go check the storage" step on every request. The JWT flow skips that step entirely, trading a storage lookup for a cryptographic verification.

Wrapping Up

Cookies are just the delivery truck — they carry data between browser and server automatically. What rides inside that truck is the real decision: a meaningless session ID that points back to server-side memory (sessions, stateful), or a self-contained, signed token carrying its own proof of identity (JWT, stateless). Neither one is the "modern correct" choice over the other — they're tools suited to different architectures, and plenty of production systems lean on both at once.

Next time you're scaffolding auth for a new project, the real question isn't "sessions or JWT?" in the abstract — it's "does this app need a single source of truth the server can revoke instantly, or does it need to scale independently across services without a shared store?" That question alone will point you toward the right answer.

Curious about refresh tokens, or how OAuth fits into all of this? Drop a comment below — I read every one.

DNS Record Types Explained

Janmejai Singh — Tue, 30 Jun 2026 16:11:18 +0000

DNS Record Types Explained: The Phonebook Behind Every Website You Visit

Here's a question that sounds simple but trips up a lot of beginner developers: when you type example.com into your browser, how does it actually know which server, sitting in some data center halfway across the world, to talk to?

The answer is DNS — the Domain Name System — and once you understand it, a whole bunch of "mysterious" web dev concepts (deploying a site, setting up email, verifying a domain for Google or AWS) suddenly stop feeling like magic.

Let's walk through it slowly, one piece at a time.

What DNS Is (In Very Simple Terms)

Computers don't actually use names like example.com to find each other. Underneath everything, they use numbers — IP addresses — like 192.0.2.10. That's how machines on a network identify each other.

But humans are terrible at remembering strings of numbers, and great at remembering names. So DNS exists as a translation layer: you type a friendly name, and DNS quietly converts it into the numeric address a computer needs.

Think of DNS as the phonebook of the internet. You don't memorize your friend's phone number — you look up their name in your contacts, and the phone handles dialing the actual number behind the scenes. DNS does exactly that, except the "contact" is a domain name and the "phone number" is an IP address.

Why DNS Records Are Needed

Knowing that DNS translates names to addresses is only half the picture. The next question is: translates to what, exactly?

A single domain isn't just "one address." A real website needs to answer several different questions at once:

Where do I send visitors who type this domain into a browser?
Where do I send emails addressed to this domain?
Who is allowed to manage this domain's settings?
How can a third-party service (like Google Search Console) verify I actually own this domain?

Each of these questions is answered by a different DNS record. A DNS record is a small instruction stored in a domain's configuration, written in a specific format, that tells the internet how to handle one particular kind of request for that domain.

A domain almost never has just one record — it has a small collection of them, each doing a specific job. Let's meet them one at a time.

NS Record: Who's Responsible for This Domain?

Before any other record matters, something has to answer the question: "Where do I even go to look up records for example.com?"

That's what an NS (Name Server) record does. It points to the specific servers that are authoritative for a domain — meaning, those servers hold the master copy of all the other DNS records for that domain.

A real-life comparison: think of NS records as the listing in a master directory that tells you which local post office handles mail for a particular street. Before the mailman can deliver anything, he first needs to know which post office is responsible for that address. NS records are that "which post office" answer for a domain.

When you buy a domain and connect it to a hosting provider or DNS service (like Cloudflare or Route 53), you're typically updating its NS records to point at that provider's name servers.

A Record: Domain → IPv4 Address

This is the record most people picture when they think "DNS." An A Record maps a domain name directly to an IPv4 address — something like 203.0.113.25.

Going back to the phonebook idea: if NS records tell you which post office handles a street, the A record is the actual house address on that street. It's the most direct, literal mapping: "this name = this numeric address, go here."

example.com.    A    203.0.113.25

When someone types example.com into their browser, this is very often the record that ultimately tells the browser which server to connect to.

AAAA Record: Domain → IPv6 Address

The internet originally ran on IPv4 addresses, but there are only so many of those to go around — about 4.3 billion, which sounds like a lot until you count every phone, laptop, server, and smart fridge on Earth. IPv6 was created as a much larger address space to solve that shortage.

An AAAA Record does exactly what an A record does, except it maps a domain to an IPv6 address instead — something like 2001:0db8:85a3::8a2e:0370:7334.

Think of it as having two valid addresses for the same house: an old-style address (IPv4/A record) and a newer-format one (IPv6/AAAA record). Modern networks increasingly prefer IPv6, so many websites maintain both an A and an AAAA record pointing to the same server, just in two different addressing formats.

CNAME Record: One Name Pointing to Another Name

Sometimes you don't want to give out a raw IP address at all — you just want to say "this name is really just another name, go look that one up instead." That's what a CNAME (Canonical Name) Record does.

A CNAME doesn't point to an IP address. It points to another domain name, which then gets resolved on its own (often eventually landing on an A or AAAA record).

A relatable analogy: imagine your friend has moved, and instead of giving everyone their new house address directly, they just say, "Mail addressed to my old house? Forward it to my new name in the system, and look that up instead." A CNAME is that forwarding instruction — one name redirecting to another name.

www.example.com.    CNAME    example.com.

This is incredibly common for things like www.example.com pointing to example.com, or a custom domain pointing to a service like myshop.shopify.com.

A common point of confusion: A record vs. CNAME. The simplest way to remember the difference is what's on the right-hand side of the record. An A record always points to an IP address (a number). A CNAME always points to another domain name (text). One is "go to this address," the other is "go ask this other name what its address is."

MX Record: How Emails Find Your Mail Server

Visiting a website and receiving an email for that domain are two completely separate jobs — and DNS handles them with two completely separate kinds of records. MX (Mail Exchange) Records are dedicated specifically to email routing: they tell the internet which mail server is responsible for accepting email sent to addresses at that domain.

Picture it like this: your house has a street address where guests come to visit (that's your A record), but your mail doesn't get handed directly to you at the door — it goes through a post office that's specifically responsible for sorting and delivering mail for your area. MX records are how the internet finds that post office for your domain.

example.com.    MX    10 mail.example.com.

That number before the mail server name (10 here) is a priority — if a domain lists multiple mail servers, lower numbers are tried first, with others as backups.

Another common point of confusion: NS vs. MX. NS records answer "who manages this domain's DNS settings overall?" MX records answer a much narrower question: "where should email for this domain be delivered?" A domain can have its DNS managed by one company (NS) while its email is hosted entirely somewhere else, like Google Workspace (MX) — they're independent of each other.

TXT Record: Extra Information and Verification

Not every DNS record is about routing traffic somewhere. Sometimes a domain just needs to say something — store a small piece of text that other systems can check. That's the job of a TXT (Text) Record.

TXT records are extremely flexible. The two most common real-world uses are:

Domain ownership verification — when you connect a domain to a service like Google Search Console, Vercel, or AWS, they'll often ask you to add a TXT record containing a specific code. This proves you actually control the domain's DNS settings, not just that you're claiming to.
Email security — records like SPF and DKIM, which are technically just specially formatted TXT records, help receiving mail servers verify that an email claiming to be from your domain is actually legitimate, cutting down on spoofing and spam.

Think of a TXT record as a sticky note pinned to the front door that says "yes, I really do live here" or "only trust mail that's been stamped this particular way." It's not directing traffic anywhere — it's just providing proof or extra context.

How All These Records Work Together for One Website

Here's where it all clicks into place. A single, fully functioning domain — say, a small business website with email — typically relies on all of these records working as a team:

NS records point to the name servers responsible for managing example.com's DNS settings.
A record maps example.com to the IPv4 address of the web server hosting the site.
AAAA record maps the same domain to an IPv6 address, for visitors on modern networks.
CNAME record makes www.example.com simply forward to example.com, so both versions of the URL work.
MX record tells the internet that email for @example.com should be delivered to a specific mail server (maybe Google Workspace or a custom mail host).
TXT records sit quietly in the background, proving domain ownership to third-party services and helping authenticate outgoing email.

None of these records "compete" with each other — each one answers a different question, and together they form the complete operating instructions for a domain. A browser visit uses the A/AAAA (and possibly CNAME) records. An incoming email uses the MX record. A third-party integration check uses a TXT record. And underneath it all, the NS record made sure everyone was looking in the right place to begin with.

Wrapping Up

DNS can feel intimidating because of all the acronyms, but at its core it's just a structured phonebook with a few specialized entry types: NS says who's in charge, A and AAAA give the literal address, CNAME forwards one name to another, MX routes email, and TXT holds extra proof or instructions. Once you can picture each record's specific job — rather than treating DNS as one big mysterious black box — configuring a domain, debugging a "website not loading" issue, or setting up email for a custom domain becomes a lot less scary.

Next time you register a domain and stare at a confusing DNS dashboard full of records, you'll know exactly what each row is actually doing — and why it's there.

Got a DNS record type you'd like explained next — SRV, CAA, or PTR maybe? Drop a comment below, I read every one.

Async Code in Node.js: Callbacks and Promises

Janmejai Singh — Tue, 30 Jun 2026 16:05:00 +0000

Async Code in Node.js: Callbacks and Promises (And Why You Should Care)

Picture this: you ask a friend to grab coffee while you keep working on your laptop. You don't freeze mid-sentence waiting for them to come back — you just keep typing, and when they return, you grab the cup. That's basically what Node.js does with slow operations like reading files, querying databases, or hitting an API. It doesn't sit around twiddling its thumbs. It keeps the line moving.

This is the heart of asynchronous programming in Node.js, and once it clicks, a lot of confusing behavior in your code suddenly makes sense.

Why Async Code Exists in Node.js

Node.js runs JavaScript on a single thread. That single thread is also responsible for handling every incoming request in your app. If that one thread ever got blocked — say, waiting three seconds for a file to load from disk — every other user of your app would also have to wait those three seconds, even if their request had nothing to do with that file.

That's a death sentence for a server.

So Node.js takes a different approach: instead of blocking the thread while waiting on a slow operation (disk I/O, network calls, timers, database queries), it hands the operation off to the system, keeps doing other work, and gets notified later when the result is ready. This is possible thanks to the event loop, which constantly checks: "Is there a task waiting to be picked back up?"

The result: a single Node.js process can juggle thousands of concurrent operations without spinning up thousands of threads. That's the whole reason async code exists — it's what makes Node.js fast and scalable despite being single-threaded.

Callback-Based Async Execution

Let's make this concrete with a classic scenario: reading a file from disk.

Reading a file isn't instant — the disk has to locate the data and stream it back. Node.js doesn't want your entire app to freeze while that happens, so the original solution baked into Node's core was the callback: a function you hand over and say, "run this once you're done."

const fs = require('fs');

fs.readFile('data.txt', 'utf8', (err, data) => {
  if (err) {
    console.error('Something went wrong:', err);
    return;
  }
  console.log('File contents:', data);
});

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

Walking through this step by step:

fs.readFile is called and immediately returns — it does not wait for the file.
Node hands the actual file-reading work off to the system and moves on to the next line.
'This runs before the file is read!' logs first, because the file read is still in progress.
Once the disk operation finishes, Node calls your callback function with either an error (err) or the result (data).

This pattern — (err, data) => {} — is so common in Node's core library that it has a name: the error-first callback convention. The error is always the first argument, so you can check for it before trusting the data.

The Problem with Nested Callbacks (a.k.a. "Callback Hell")

Callbacks work fine for one async step. The trouble starts when you need to chain several async operations together — read a file, then use that data to query a database, then write a result, then send a notification. Each step depends on the previous one finishing, so naturally, each callback gets nested inside the last.

fs.readFile('user.json', 'utf8', (err, userData) => {
  if (err) return console.error(err);

  const user = JSON.parse(userData);

  db.findOrders(user.id, (err, orders) => {
    if (err) return console.error(err);

    calculateTotal(orders, (err, total) => {
      if (err) return console.error(err);

      sendInvoiceEmail(user.email, total, (err) => {
        if (err) return console.error(err);
        console.log('Invoice sent successfully!');
      });
    });
  });
});

This staircase of nested functions is infamously known as callback hell (or the "pyramid of doom"). It's not just ugly — it creates real problems:

Hard to read — your eyes have to zigzag rightward with every new indentation level.
Hard to maintain — adding a new step means rewrapping everything inside another layer.
Error handling is repetitive — you end up writing the same if (err) return ... check at every level, and it's easy to forget one.
Hard to reason about control flow — what happens if two of these steps need to run in parallel instead of in sequence? With raw callbacks, that requires manual bookkeeping (counters, flags) that's easy to get wrong.

Callback hell isn't a sign you're "doing async wrong" — it's a structural limitation of the callback pattern itself once your async logic grows beyond one or two steps.

Promise-Based Async Handling

This is the problem Promises were designed to solve. A Promise is an object representing a value that doesn't exist yet but will at some point — either successfully (resolved) or unsuccessfully (rejected).

Instead of passing a callback deep into a function, you get back a Promise immediately and chain .then() calls onto it:

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

fs.readFile('user.json', 'utf8')
  .then(userData => {
    const user = JSON.parse(userData);
    return db.findOrders(user.id);
  })
  .then(orders => calculateTotal(orders))
  .then(total => sendInvoiceEmail(user.email, total))
  .then(() => console.log('Invoice sent successfully!'))
  .catch(err => console.error('Something failed:', err));

Notice what happened: the pyramid is gone. Each step is flat, chained with .then(), and there's a single .catch() at the end that handles errors from any step in the chain — no more repeating error checks at every level.

It gets even cleaner with async/await, which is just syntactic sugar over Promises:

async function sendInvoice() {
  try {
    const userData = await fs.readFile('user.json', 'utf8');
    const user = JSON.parse(userData);
    const orders = await db.findOrders(user.id);
    const total = await calculateTotal(orders);
    await sendInvoiceEmail(user.email, total);
    console.log('Invoice sent successfully!');
  } catch (err) {
    console.error('Something failed:', err);
  }
}

Read that out loud — it almost sounds like synchronous code, even though every awaited line is asynchronous under the hood. That's the magic of this pattern: it gives you the readability of sequential code with the performance of async execution.

Benefits of Promises Over Plain Callbacks

Bringing it all together, here's why Promises (and async/await) became the standard way to handle async code in modern Node.js:

Flat, readable structure — no more pyramid of doom, regardless of how many async steps you chain.
Centralized error handling — one .catch() (or one try/catch block) covers the whole chain instead of scattering checks everywhere.
Composability — Promises play well with utilities like Promise.all() (run several async tasks in parallel and wait for all of them) and Promise.race() (resolve as soon as the first one finishes), something that's painful to hand-roll with raw callbacks.
Predictable state — a Promise is always in one of three states (pending, fulfilled, or rejected) and, once settled, can never change state again. That predictability removes a whole class of bugs where a callback might accidentally fire twice or never fire at all.
Better stack traces and debugging — errors thrown inside an async function bubble up in a way that's far easier to trace back to its source than an error swallowed inside a deeply nested callback.

Visualizing the Difference

Two mental models are worth sketching out as you internalize this:

Callback execution chain — picture a row of dominoes, where each domino can only tip the next one inside its own falling motion. Every new async step has to be physically nested inside the previous one's callback, which is exactly why the code visually nests deeper and deeper.

Promise lifecycle flow — picture a single object moving through three clearly defined states: it starts out pending, and then moves to either fulfilled (success — your .then() runs) or rejected (failure — your .catch() runs). Once it lands in one of those two end states, it's locked in for good. Chaining .then() calls doesn't nest dominoes — it just passes the baton from one finished Promise to the next.

Wrapping Up

Async code is the backbone of what makes Node.js efficient: a single thread that never sits idle waiting on slow I/O. Callbacks were the original way to tap into that model, but they buckle under their own weight once your logic involves more than a step or two — leading straight into callback hell. Promises (and the async/await syntax built on top of them) fix that by flattening your code, centralizing error handling, and giving you predictable, composable building blocks for real-world async logic.

If you're just getting comfortable with Node.js, the path is usually: understand callbacks first (because you'll still see them in older code and core APIs), then lean on Promises and async/await for everything you write going forward.

Got questions about async patterns in Node.js, or want to see a follow-up on async generators or Node's EventEmitter? Drop a comment below — I read every one.

Expo Router vs React Navigation - Which One Should You Use in 2026?

Janmejai Singh — Tue, 30 Jun 2026 15:52:50 +0000

Expo Router vs React Navigation: Which One Should You Use in 2026?

Every React Native developer eventually hits the same wall: the app has grown past a handful of screens, the navigation file is 300 lines long, and nobody on the team is quite sure which navigator owns which screen anymore. At that point, a question that used to be a footnote becomes a real architectural decision — Expo Router or React Navigation?

This isn't a "pick a side" article. It's a practical breakdown of what routing actually means on mobile, why navigation got complicated in the first place, how Expo Router fixes (and doesn't fix) those problems, and when each tool genuinely makes sense for your team in 2026.

1. What "Routing" Actually Means on Mobile

On the web, routing is simple: the URL changes, the browser fetches new HTML, the page updates. Mobile apps don't have that luxury — there's no browser, no automatic refresh, no window.location.

Instead, routing on mobile means moving between screens while preserving application state: what's on the navigation stack, what data a screen needs when you come back to it, what transition animation plays, and how a deep link from outside the app (a push notification, a shared link, a QR code) lands you on the right screen with the right state already loaded.

In short: routing decides what's visible, navigation decides how you got there and what happens when you leave. On mobile, these two concerns are tightly coupled — which is exactly why getting the architecture right matters so much.

2. Why Navigation Is a Big Deal in React Native

React Native deliberately ships without a built-in navigation solution — no storage, no camera, no navigation. These are left to the community. That's by design, but it also means navigation architecture is one of the first major decisions every React Native project makes, and one of the hardest to undo later.

A poorly structured navigation layer doesn't just look messy — it actively slows teams down. Onboarding new engineers takes longer because there's no obvious "front door" to the app's structure. Refactors become risky because navigators are tangled together. Deep linking and authentication flows turn into a maze of conditional logic. Navigation isn't cosmetic; it's the structural backbone of the app.

3. A Brief History of React Navigation

React Navigation has been the de facto standard since the early days of React Native. It evolved through several major eras:

v1–v2: Basic stack navigators, JS-driven transitions.
v3–v4: Better type safety, more navigator types (tabs, drawers).
v5–v6: A move to native-driven animations via react-native-screens, hitting consistent 60fps transitions.
v7: Full React 18 compatibility, stronger TypeScript inference, deeper native stack integration.
v8 (alpha, early 2026): Native bottom tabs by default on iOS and Android, deep linking enabled out of the box, and React 19 support — including the React.Activity API to pause inactive screens and cut unnecessary re-renders.

By 2023–2024, React Navigation was in essentially every serious React Native codebase, backed by a mature ecosystem of integrations and tutorials.

// 2017-era setup
<NavigationContainer>
  <Stack.Navigator>
    <Stack.Screen name="Home" component={HomeScreen} />
    <Stack.Screen name="Profile" component={ProfileScreen} />
    <Stack.Screen name="Settings" component={SettingsScreen} />
  </Stack.Navigator>
</NavigationContainer>

This looked manageable — for about twenty screens.

4. The Problems Developers Actually Ran Into

As apps scaled, recurring pain points showed up across teams:

Manual registration overhead — every screen had to be wired into a navigator by hand. Fifty screens meant fifty registrations to maintain.
Nested navigator sprawl — tabs inside stacks inside drawers turned into deeply nested configuration objects that were hard to reason about.
Structure mismatch — navigation config lived separately from the screens/ folder, so the visual file structure told you nothing about how the app actually flowed.
Deep linking friction — URL schemes and platform-specific linking config had to be set up and kept in sync by hand.
Onboarding difficulty — new engineers had no obvious map of the app; the navigation tree had to be reverse-engineered from scattered config files.

None of this meant React Navigation was bad — it meant the convention layer on top of it was missing.

5. Why Expo Router Was Introduced

Expo Router (2023) was built to solve exactly that gap: file-based routing conventions on top of React Navigation, directly inspired by Next.js's app/ directory model.

The most important thing to understand — and the thing most developers get wrong — is this:

Expo Router does not replace React Navigation. It's a structural layer built on top of it.

Screens are still pushed, popped, and animated by the same native-driven navigation engine. What changes is how you declare and organize routes.

2026 update: With the SDK 56 beta, Expo Router forked the specific parts of React Navigation it depends on — expo-router no longer lists @react-navigation/* as a direct dependency. The runtime API hasn't changed (<Stack>, <Tabs>, and file-based patterns work the same), but imports that used to come from @react-navigation/native-stack or @react-navigation/drawer now come from expo-router directly in Expo Router projects. You can still use React Navigation directly inside an Expo project — the two aren't mutually exclusive.

6. File-Based Routing, Explained Simply

The core idea: your folder structure is your routing table.

app/
├── index.tsx          → "/"
├── profile.tsx         → "/profile"
├── settings/
│   └── account.tsx     → "/settings/account"

Create a file inside app/, and it automatically becomes a route. Delete it, and the route disappears. There's no separate config file to keep in sync — the thing you see in your file explorer is the thing your users navigate through.

// React Navigation: edit config → register screen → add types → test
// Expo Router: create file → save → route works

That's a genuinely different workflow loop, not just a stylistic preference.

7. Nested Layouts and Shared Layouts

Expo Router uses special _layout.tsx files to define shared UI and navigator type for a segment of routes — the equivalent of a persistent header, tab bar, or drawer that wraps everything underneath it.

app/
├── _layout.tsx              ← root layout (e.g. Stack)
├── (tabs)/
│   ├── _layout.tsx          ← tab navigator
│   ├── home/
│   │   ├── index.tsx
│   │   └── details.tsx
│   ├── profile/
│   │   ├── index.tsx
│   │   └── edit.tsx
│   └── settings/
│       ├── account.tsx
│       └── privacy.tsx

Parentheses, like (tabs), create a route group — a folder that organizes routes without adding a segment to the URL. This is how Expo Router keeps deeply nested navigation (tabs inside stacks inside drawers) readable: the nesting in your file tree mirrors the nesting in your navigation tree, instead of living in a separate mental model entirely.

flowchart TD
    A["Root Layout (_layout.tsx)"] --> B["(tabs) layout"]
    B --> C["Home stack"]
    B --> D["Profile stack"]
    B --> E["Settings stack"]
    C --> C1["index.tsx"]
    C --> C2["details.tsx"]
    D --> D1["index.tsx"]
    D --> D2["edit.tsx"]
    E --> E1["account.tsx"]
    E --> E2["privacy.tsx"]

8. Protected Routes and Authentication Flows

Authentication is one of the most painful parts of any large React Native app, and it's where the two approaches diverge most visibly in workflow, even though the underlying mechanics are similar.

With React Navigation, you typically conditionally render an entire navigator tree — an AuthStack or an AppStack — based on auth state. It works, but it leans imperative and creates room for state-synchronization bugs between the auth check and the navigator that gets mounted.

With Expo Router, route groups express the same idea declaratively:

app/
├── (public)/
├── (auth)/
├── (dashboard)/
│   ├── analytics/
│   ├── billing/
│   ├── settings/
│   └── users/
├── _layout.tsx
└── +not-found.tsx

Auth state lives high in the tree (often in the root _layout.tsx), and redirects are handled declaratively using a redirect with useRootNavigationState or a custom hook — instead of conditionally swapping navigators.

flowchart TD
    A["App Launch"] --> B["Check Session"]
    B -->|"Logged In"| C["Protected Routes (dashboard)/"]
    B -->|"Guest"| D["Auth Flow (auth)/"]
    D -->|"Login Success"| C

This mental model — routes expressing app structure instead of navigators being conditionally swapped — scales noticeably better once auth flows get complicated (onboarding, multi-tenant access, role-based dashboards).

9. Performance Comparison

It's tempting to assume Expo Router is "faster" than React Navigation. That's the wrong frame. Since Expo Router is built on the same native navigation engine, raw transition performance is nearly identical — both rely on react-native-screens for native-driven, 60fps transitions.

Where the real differences show up:

Bundle Behavior

React Navigation: all screens are bundled together unless you manually code-split.
Expo Router: automatic route-based code splitting and deferred bundling — only the screens a user actually visits get pulled in, with lazy-loaded chunks for the rest. This is especially noticeable on web builds, where smaller initial bundles directly improve load time.

Navigation Transitions

Both are powered by the same native drivers, so transitions feel equivalent — smooth, native, gesture-ready. Expo Router doesn't add runtime overhead; it generates the same navigator config under the hood.

Developer Workflow

This is where the gap is real. React Navigation's loop is edit config → register screen → add types → test. Expo Router's loop is create file → save → route works, with typed routes inferred automatically from the filesystem. Teams that have used both consistently describe Expo Router as "feeling faster" — not because the engine is quicker, but because the iteration loop has fewer manual steps.

10. Developer Experience (DX) Comparison

	React Navigation	Expo Router
Adding a screen	Edit navigator config, import component, add types	Add a file to `app/`
Deep linking	Manual URL scheme + platform config	Automatic — every route is deep-linkable by default
Type safety	Manual type definitions per navigator	Types inferred from the filesystem
Web support	Requires extra setup for unified routing	Built-in universal routing across iOS, Android, web
Learning curve	Steeper — navigator composition is explicit	Gentler — mirrors familiar file-system routing (Next.js-like)
Flexibility	Maximum — full low-level control	High, but convention-guided

11. Scalability for Large Applications

For small apps, either approach works fine — the differences don't really bite until the app grows past a few dozen screens and more than one or two engineers are touching navigation code.

At that scale, Expo Router's biggest advantage is having one source of truth. With React Navigation, the navigation/ (or navigators/) directory has to be kept manually in sync with the screens/ directory — two parallel structures that can drift apart. With Expo Router, the app/ directory is the navigation structure; there's nothing else to keep in sync.

That said, "scalable" doesn't automatically mean "better for every large team." Enterprises with deeply customized navigation behavior, bespoke transitions, or legacy infrastructure often find React Navigation's lower-level control more valuable than Expo Router's conventions — more on that below.

12. Real-World Folder Structure Example

A production-grade Expo Router app commonly looks something like this:

app/
├── (public)/
│   ├── index.tsx
│   └── pricing.tsx
├── (auth)/
│   ├── login.tsx
│   └── signup.tsx
├── (dashboard)/
│   ├── _layout.tsx
│   ├── analytics/
│   │   └── index.tsx
│   ├── billing/
│   │   └── index.tsx
│   ├── settings/
│   │   └── account.tsx
│   └── users/
│       ├── index.tsx
│       └── [id].tsx
├── _layout.tsx
└── +not-found.tsx
components/
hooks/
services/

The equivalent React Navigation structure typically looks like:

src/
├── screens/
├── navigators/
├── stacks/
├── tabs/
├── drawers/
├── linking/
└── auth/

Both can be well-organized. But notice the difference: one structure is the navigation map, and the other describes it from a parallel directory that has to be manually kept in sync.

13. Which Approach Do Companies and Teams Actually Prefer?

Looking at new project creation, documentation defaults, and community discussion through 2026, the trend is clear without being absolute:

Startups and solo developers have moved quickly to Expo Router — reduced boilerplate and faster iteration are a real productivity win when engineering time is scarce.
New projects in general default to Expo Router — npx create-expo-app ships it out of the box, and the official Expo documentation is centered around it.
Larger enterprises with existing React Navigation investments are mixed. Some are migrating incrementally; many are staying put, especially where navigation behavior is deeply customized or migration risk outweighs the DX gains.

There's no "winner takes all" situation here — it's a genuine architecture-philosophy split, not a popularity contest.

14. When NOT to Use Expo Router

Expo Router is excellent, but it isn't the right default in every situation. Reach for React Navigation directly instead when:

You're working on a bare React Native app without the Expo ecosystem (note: React Native Navigation by Wix is also not compatible with Expo Go or expo-dev-client).
You need highly custom transitions or gestures that don't fit standard navigator patterns.
You're doing a brownfield integration — adding navigation to an existing native app where Expo's conventions don't map cleanly onto existing architecture.
You're migrating a large, mature codebase where the migration risk outweighs the DX improvement.
Your team is unfamiliar with filesystem-based routing conventions and route groups, and the learning curve would slow down a near-term deadline more than it helps long-term maintainability.

15. Situations Where React Navigation Still Makes More Sense

Maximum low-level control — when you need to reach directly into navigator internals for behavior Expo Router's conventions don't expose cleanly.
Legacy enterprise codebases — where the navigation architecture is already deeply established and stable, and there's no concrete pain point driving a migration.
Non-Expo projects — if you're not using the Expo toolchain at all, React Navigation is the more natural fit without taking on Expo Router's conventions for no benefit.
Teams that value explicit configuration over convention — some teams genuinely prefer seeing every navigator wired up explicitly in code, especially when onboarding engineers from a background that doesn't include file-based routing (e.g., teams without web/Next.js experience).

Architecture Comparison at a Glance

flowchart LR
    subgraph RN["React Navigation"]
        direction TB
        RN1["screens/"] --> RN2["navigators/ (manual config)"]
        RN2 --> RN3["NavigationContainer"]
    end
    subgraph ER["Expo Router"]
        direction TB
        ER1["app/ folder structure"] --> ER2["Generated React Navigation config"]
        ER2 --> ER3["NavigationContainer"]
    end

The key takeaway from this diagram: both approaches ultimately produce the same underlying navigation tree. The difference is entirely in how you author it — by hand, or by folder structure.

The Verdict for 2026

Expo Router doesn't replace React Navigation — it elevates it with conventions that make teams faster and code easier to maintain. For the majority of new, production-grade React Native apps built on Expo, that convention layer is worth adopting by default.

Choose Expo Router if: you're starting a new Expo project, your team values developer experience and onboarding speed over granular control, you need solid web parity, and your navigation patterns are fairly standard (stacks, tabs, drawers, auth-gated route groups).

Choose React Navigation directly if: you're on bare React Native, you need deeply custom transitions or gestures, you're integrating navigation into an existing native app, or you're maintaining a large legacy codebase where migration isn't worth the risk.

Make the call based on your constraints, not the hype cycle. But if you're starting fresh in 2026, Expo Router is the sensible default — and you're not giving up React Navigation's power to get there, you're just not configuring it by hand anymore.

If you're building a new React Native app this year, what's tipping your decision — developer experience, team size, or existing infrastructure? Drop your reasoning in the comments.

How WhatsApp Works Without Internet: Offline Messaging and Sync Explained

Janmejai Singh — Sun, 31 May 2026 15:43:09 +0000

You're on a train, signal drops to zero. You type a message and hit send. A single grey tick appears.

Then — the moment you exit the tunnel — two ticks appear.

How did that work? You were offline.

This isn't magic. It's offline-first architecture, and it's one of the most practical ideas in mobile engineering. Let's break it down.

The Scenario: Sending a Message in Airplane Mode

Imagine you toggle airplane mode and type:

"Just took off. Landing in 3 hours!"

WhatsApp doesn't show an error. It doesn't freeze. You see a message bubble with one grey tick.

Here's what actually happened:

The app saved your message to a local database on your phone
It added the message to an outgoing queue
It rendered the message immediately in the UI — no waiting
It set the internal status to PENDING

Your message never touched a server. The app made a promise to deliver it when connectivity returns. That promise — that optimistic local-first action — is the heart of offline-first design.

Local Storage and Message Persistence

Every message is first written to a local SQLite database on the device, before anything goes to the cloud.

WhatsApp uses SQLite. Android apps use Room. iOS apps use Core Data. In React Native, you'd reach for expo-sqlite or @op-engineering/op-sqlite.

A simplified message record looks like this:

CREATE TABLE messages (
  id              TEXT PRIMARY KEY,  -- Generated on device, not server
  conversation_id TEXT NOT NULL,
  content         TEXT NOT NULL,
  created_at      INTEGER NOT NULL,  -- Device timestamp
  status          TEXT DEFAULT 'PENDING',
  media_uri       TEXT,              -- Local file path for media
  server_ack_id   TEXT               -- Set after server confirms receipt
);

Two things worth noting:

The ID is generated on the device, so WhatsApp can display the message before the server even knows it exists.
Status starts as PENDING — honest, explicit, and essential for the queue system.

The UI reads from local storage. It never waits for the network.

The Message Queue

When a message is saved locally, it also enters an outgoing queue — a persistent list of things the app needs to send when it can.

┌──────────────────────────────────────┐
│         OUTGOING MESSAGE QUEUE       │
│  [msg_001] "Just took off..." PENDING│
│  [msg_002] "See you soon!" PENDING   │
│  [msg_003] photo.jpg       PENDING   │
└──────────────────────────────────────┘
         ↕  No internet — held on device

This queue is written to disk, not held in RAM. If the app crashes, the queue survives. When internet returns, the app processes messages in order, retrying failures with exponential backoff (1s → 2s → 4s → ...) to handle flaky connections gracefully.

Syncing When Connectivity Returns

The moment internet returns, the app fires off four steps almost simultaneously:

Internet returns
      │
      ▼
1. Flush outgoing queue  →  Send all pending messages to server
      │
      ▼
2. Pull missed messages  →  Fetch messages sent to YOU while offline
      │
      ▼
3. Reconcile local DB    →  Merge server state with local state
      │
      ▼
4. Update the UI         →  Ticks change, new messages appear

Step 1 — Each queued message is sent to WhatsApp's servers. The server acknowledges receipt and the status upgrades from PENDING to SENT.

Step 2 — People may have messaged you while you were offline. The app requests everything from the server since the last sync timestamp.

Step 3 — Local DB is updated with what came from the server.

Step 4 — Because the UI observes the local DB reactively, everything updates automatically. No manual refresh needed.

Delivery States: Sent, Delivered, Read

The tick system maps directly to a message state machine:

[PENDING] → [SENT] → [DELIVERED] → [READ]
  clock      1 grey    2 grey        2 blue
              tick      ticks         ticks
     └──────→ [FAILED] (retries exhausted)

State	What it means
Pending	Saved locally, not yet on server
Sent	Server received it
Delivered	Recipient's device has it
Read	Recipient opened the conversation
Failed	Couldn't deliver after all retries

State transitions are triggered by acknowledgements (acks) from the server or recipient's device via a persistent connection.

Why separate "Sent" from "Delivered"? Because the server having your message ≠ the recipient's phone having it. They could be offline too.

Handling Media While Offline

Text messages are tiny. Photos and videos are not. WhatsApp handles this with a decoupled upload strategy:

Capture & save locally — photo is stored on device
Queue the message with a local file reference (local://img_001.jpg)
Upload media in background when internet returns
Server returns a CDN URL — message record updates from local:// to https://mmg.whatsapp.net/...
Recipient downloads on demand — they get the URL and fetch media lazily

This is why you sometimes see a blurred thumbnail or "Waiting for media" — the text message arrived, but media hasn't been downloaded yet.

Conflict Resolution and Message Ordering

What happens when messages arrive out of order after going offline?

The problem: Device clocks are unreliable. Your phone might be 30 seconds off, or in the wrong timezone. If WhatsApp trusted device timestamps alone, messages could appear out of order.

The solution:

Server-assigned timestamps — when a message reaches the server, it gets a canonical timestamp used for ordering
Sequence numbers — monotonically increasing numbers break ties between messages with identical timestamps
Last-write-wins for status — message status can only move forward (SENT → DELIVERED, never backwards)

This is a simplified form of eventual consistency:

The system doesn't guarantee every device sees the same state at the same instant. But given time and connectivity, all devices converge on the same state.

For messaging, this is an acceptable tradeoff. A message appearing 200ms out of order is fine. A message that never appears is not.

Why Offline-First Matters

Traditional approach:

User action → Network request → Update UI (only if network works)

Offline-first approach:

User action → Update local DB → Update UI → Background sync to server

The difference in feel is enormous.

Traditional (online-first)	Offline-first
Broken without internet	Works fully offline
User waits on every action	Instant UI feedback
Lost actions on failure	Queue retries automatically
Spinner on every tap	Smooth always
Terrible on slow networks	Great on any network

The tradeoffs are real though:

Conflict resolution becomes your responsibility
Local data needs encryption (WhatsApp uses SQLCipher)
Testing network edge cases is harder
Storage management (when do you purge old queued messages?)

The Full Lifecycle in One Diagram

User types and hits send
        ↓
App generates local ID
        ↓
Saved to SQLite (PENDING)
        ↓
Added to outgoing queue
        ↓
UI renders immediately (optimistic update)
        ↓
─── [Internet returns] ───────────────────
        ↓
Queue flushed → sent to server
        ↓
Server acks → status: SENT (1 grey tick ✓)
        ↓
Recipient's device comes online → delivered
        ↓
Delivery ack → status: DELIVERED (2 grey ✓✓)
        ↓
Recipient opens chat → read receipt sent
        ↓
Read ack → status: READ (2 blue ✓✓) ✅

Building This in React Native

Here's the toolkit you'd reach for:

Need	Library
Local DB	`expo-sqlite` or `@op-engineering/op-sqlite`
Fast key-value (queue)	`react-native-mmkv`
Network state	`@react-native-community/netinfo`
Background sync	`expo-task-manager` + background fetch
Real-time acks	`socket.io-client` or Firebase RTDB

The pattern is always: local first → background sync → UI driven by local state.

Key Takeaways

WhatsApp never waits for the network — it writes locally and syncs later
The outgoing queue persists to disk and survives crashes
Delivery states (PENDING → SENT → DELIVERED → READ) are driven by server and device acks
Media uploads are decoupled from text — text queues fast, media uploads in background
Server-side timestamps and sequence numbers resolve ordering conflicts
Offline-first trades implementation complexity for much better UX

What to Explore Next

WatermelonDB — a React Native DB built specifically for offline-first at scale
CRDTs — the math behind conflict-free sync
Firebase Firestore offline persistence — a managed offline-first solution
XMPP / MQTT — the protocols behind real-time messaging

Next time you see those grey ticks turn blue on a plane with spotty Wi-Fi, you'll know exactly what just happened. 🛫

Found this useful? Drop a ❤️ and share it with your dev cohort!

How Instagram, WhatsApp, Uber & Netflix Would Be Built Today Using Expo Router

Janmejai Singh — Sun, 31 May 2026 14:21:55 +0000

You tap Record. You nail the take. You save as Draft. You close Instagram, reopen it — and your Reel is right there. What just happened under the hood?

This post traces that full journey: from your device's camera buffer to your follower's screen halfway across the world. We'll cover local storage, drafts, cloud uploads, media processing, caching, and CDNs — with diagrams at each stage.

Why Social Media Apps Need Efficient Media Storage

Photos and videos are the heaviest assets any mobile app handles. A single 60-second Reel captured at 1080p can be 200–400MB before any compression. Multiply that by a billion daily uploads and you begin to understand why media storage is not a solved problem — it's an ongoing engineering discipline.

Efficiency matters at three levels:

Device level — local storage is limited; apps can't balloon in size
Network level — large uploads over mobile connections are fragile and slow
Cloud level — storing, processing, and serving billions of files requires distributed systems

Instagram's architecture solves each of these with different tools, layered together.

How Photos and Videos Are Stored Before Upload

When you record a Reel, the app doesn't immediately try to upload it. Your device is the first storage layer.

The recording pipeline looks like this:

Camera Sensor
     ↓
In-Memory Frame Buffer  ← (active recording, fast but volatile)
     ↓
Local Temp Cache        ← (flushed from buffer, survives brief interruptions)
     ↓
User Decision Point
  ├── Discard → Delete temp files
  ├── Save Draft → Move to persistent storage
  └── Post → Enqueue for upload

Why local-first?

Three reasons:

Networks are unreliable — especially on cellular. Streaming raw video directly to a cloud server mid-recording is a recipe for data loss.
User intent is unknown — the app doesn't know you'll keep the clip until you decide.
Upload costs — uploading every test take wastes bandwidth, battery, and server resources.

Local storage on mobile comes in different tiers:

Tier	Speed	Persistence	Cleared by
RAM buffer	Fastest	Lost on kill	OS memory pressure
Cache directory	Fast	Semi-persistent	OS under storage pressure
Documents directory	Fast	Persistent	Only explicit delete

Active recordings live in the cache. Once you decide to keep them — as a draft or a post — they move to the documents directory.

What Happens When a User Saves a Draft

A draft isn't just a video file. It's a bundle of state that must survive app restarts:

The raw video clip(s)
Applied audio track (and timestamp offset)
Stickers, text overlays, and their screen positions
Trim start/end points
Filter and effect choices
Selected thumbnail frame

When you tap "Save Draft," Instagram performs a transactional write:

1. Write video file to documents directory
2. Write metadata record to local SQLite database
   (file path, audio, effects, trim points, etc.)
3. Confirm both writes succeeded
4. Show "Draft Saved" confirmation

Either both writes succeed or neither is surfaced to the user. This is critical — a draft pointing to a missing file, or a video file with no matching metadata record, is worse than no draft at all.

How drafts survive app restarts:

On launch, Instagram queries the SQLite database for all draft records. For each record, it reads the stored file path and reconstructs the preview. No network call needed. The entire drafts tray is built from local data.

App Launch
    ↓
Query SQLite: SELECT * FROM drafts ORDER BY updated_at DESC
    ↓
For each row: read video file at stored path → generate thumbnail
    ↓
Render Drafts tray

Local Storage vs. Cloud Storage

These two worlds have opposite strengths:

┌──────────────────────────┬──────────────────────────┐
│     LOCAL STORAGE        │     CLOUD STORAGE        │
├──────────────────────────┼──────────────────────────┤
│ ✅ Near-zero latency     │ ✅ Unlimited scale        │
│ ✅ Works offline         │ ✅ Durable (replicated)   │
│ ✅ No network dependency │ ✅ Accessible everywhere  │
│ ❌ Limited capacity      │ ❌ Network dependent      │
│ ❌ Lost if device lost   │ ❌ Slower (network I/O)   │
│ ❌ Single device only    │ ❌ Costs money at scale   │
└──────────────────────────┴──────────────────────────┘

Instagram's architecture uses both — local for speed and offline capability, cloud for durability and sharing. The transition point is the upload pipeline.

Uploading Large Media Files Efficiently

Uploading a 200MB video over cellular as one HTTP POST is a terrible idea. One dropped packet and you start over. Instagram avoids this with two techniques:

1. Chunked / Resumable Uploads

The file is split into small chunks (e.g., 5MB each). Each chunk is uploaded independently. If a chunk fails, only that chunk retries.

Full Video: 200MB
 ├── Chunk 01 (5MB) → ✅
 ├── Chunk 02 (5MB) → ✅
 ├── Chunk 03 (5MB) → ❌ (network drop)
 │       └── Retry Chunk 03 → ✅
 ├── Chunk 04 (5MB) → ✅
 └── ... 36 more chunks

Server-side, the chunks are tracked by upload session ID. Once all are received, the server reassembles them in order.

2. Background Uploads

After you tap Post, you don't have to wait in the app. The upload continues in the background using OS-level transfer APIs:

iOS: URLSession with .background configuration
Android: WorkManager or JobScheduler

These transfers are managed by the operating system, not the app. They survive the app being backgrounded or even force-quit, and resume automatically when connectivity returns.

The Upload Queue

A local queue tracks upload status for each piece of media:

PENDING → IN_PROGRESS → COMPLETED
              ↓
           PAUSED (network lost)
              ↓
           RETRYING
              ↓
           FAILED (max retries hit)

This queue state is persisted to SQLite, so if the app is killed mid-upload, it knows exactly where to resume.

Media Processing and Compression

Once your raw video lands in Instagram's cloud, it enters a processing pipeline before being stored for delivery.

Raw Upload Received
        ↓
Validation
(corrupt file check, content policy scan, format verification)
        ↓
Transcoding
(re-encode to H.264/H.265, normalize codec/container)
        ↓
Multi-Resolution Encoding
(1080p, 720p, 480p, 360p — for adaptive bitrate streaming)
        ↓
Audio Processing
(normalize levels, validate sync)
        ↓
Thumbnail Extraction
(keyframe analysis + ML quality scoring)
        ↓
Distribute to Storage + CDN

Compression Concepts

Raw uploads are transcoded to significantly smaller files without noticeable quality loss:

Codec efficiency: H.265 (HEVC) compresses ~40% better than H.264 at equal visual quality
Variable Bitrate (VBR): Static scenes get fewer bits; fast-moving scenes get more — no bits wasted
Perceptual encoding: Human vision is less sensitive to chroma (color) detail than luma (brightness), so color channels are compressed more aggressively

A 200MB raw Reel might become a 12–20MB streamable video after processing.

Thumbnail Generation and Previews

Thumbnails are more than decoration — they're a performance optimization.

A thumbnail is a single JPEG, typically under 50KB, that can be fetched and displayed in milliseconds. Without thumbnails, every feed scroll would require pre-buffering video before anything appeared on screen.

How Thumbnails Are Created

During the processing pipeline:

Multiple keyframes are extracted from the video at regular intervals
Each keyframe is scored by an ML model for visual quality (avoiding blurry, over-exposed, or mid-blink frames)
The highest-scoring frame is selected (or the creator's manually chosen frame is used if available)
The selected frame is saved as a separate JPEG in object storage

Low-Quality Image Placeholders (LQIP)

Instagram also generates a tiny blur placeholder — sometimes just 20x20 pixels encoded as a base64 string in the API response. This renders instantly (before any network request for the actual thumbnail) and gives the feed a fluid scrolling feel even on slow connections.

Feed item appears
     ↓
Base64 blur hash renders (immediate — no network)
     ↓
Full thumbnail fetched from CDN (50–200ms)
     ↓
Swap: blur → thumbnail
     ↓
User taps play → ABR video stream begins

Caching Frequently Viewed Content

Every content request has a cost: network latency, server load, battery usage. Caching short-circuits that cost by keeping a local copy of recently used content.

Multi-Level Cache Architecture

Request for content
        ↓
Memory cache (L1) → HIT → Render (~0ms)
        ↓ MISS
Disk cache (L2)   → HIT → Render + promote to L1 (~5–20ms)
        ↓ MISS
CDN Edge          → HIT → Render + store in L2 (~30–100ms)
        ↓ MISS
Origin Storage    → Fetch → Render + propagate to CDN + store in L2

What Gets Cached

Content Type	Cache Location	TTL
Profile pictures	Disk (long TTL)	Days
Feed thumbnails	Disk (medium TTL)	Hours
Active video buffers	Memory	Session only
Stories (viewed)	Disk (short TTL)	Until expiry
Prefetched posts	Disk	Minutes

Prefetching: Getting Ahead of the User

While you're watching post #3, Instagram is already fetching thumbnails and initial video buffers for posts #6–10 in your feed. This makes scrolling feel instantaneous — by the time your thumb reaches those posts, the content is already on your device.

Prefetching is throttled by connection quality: aggressive on Wi-Fi, conservative on 4G, minimal on 3G.

Cache Invalidation

Knowing when to throw away cached content is hard. Instagram's approach:

TTL (Time-to-Live): Cached items expire after a configured duration
Cache-Control headers: Server communicates max-age per content type
Versioned URLs: When content changes (e.g., profile photo update), the URL hash changes, forcing a fresh fetch

Content Delivery Using CDNs

Your followers in Tokyo, Lagos, and Berlin all load your Reel at similar speeds because Instagram doesn't serve media directly from a central data center — it uses a Content Delivery Network.

How CDN Delivery Works

User in Tokyo requests Reel video
           ↓
DNS resolves to nearest CDN edge node (Tokyo)
           ↓
Edge node checks local cache
  ├── HIT → Serve immediately (low latency)
  └── MISS → Fetch from origin → Cache locally → Serve
           ↓
Response travels <50ms vs ~200ms from US origin

Meta operates its own CDN infrastructure alongside partnerships with commercial CDN providers. Edge nodes are placed in internet exchange points worldwide to minimize the physical distance content must travel.

Adaptive Bitrate Streaming (ABR)

Instagram doesn't just serve one video file — it serves a manifest file (HLS or DASH format) that lists multiple quality variants. Your device's player selects the appropriate variant based on real-time network conditions:

Excellent connection → 1080p @ 8Mbps
Good connection      → 720p  @ 4Mbps
Fair connection      → 480p  @ 2Mbps
Poor connection      → 360p  @ 800Kbps

If your connection degrades mid-playback, the player seamlessly switches to a lower quality tier without rebuffering — you see slightly less detail, but playback continues uninterrupted.

Managing Storage, Performance, and User Experience

All of these systems involve tradeoffs. More aggressive caching = faster loads but higher device storage use. More compression = smaller files but potential quality loss. More CDN edge nodes = lower latency but higher infrastructure cost.

Device Storage Management

Instagram's client periodically runs cache eviction to prevent disk bloat:

LRU eviction: Least-recently-used content is removed first
Size caps: Cache directories are bounded to a maximum size
OS pressure response: When device storage is low, the OS may clear cache directories without asking

Drafts are immune to OS-level eviction because they live in the documents directory — only explicit deletion removes them.

Adaptive Behavior Based on Context

Condition	System Response
On Wi-Fi	Aggressive prefetch, high quality, run pending uploads
On cellular	Conservative prefetch, adaptive quality, throttle background work
Low battery	Pause non-critical background tasks
Storage low	Evict cache aggressively, warn user if drafts at risk
App in background	Continue uploads, pause prefetching

Full Architecture: End-to-End

Let's map the complete journey from recording to playback:

┌─────────────────────────────────────────────────────────────────┐
│  DEVICE                                                          │
│  Record → Frame Buffer → Temp Cache                             │
│  Edit/Draft → Documents Dir + SQLite                            │
│  Post → Upload Queue → Chunked Upload (background)             │
└────────────────────────────┬────────────────────────────────────┘
                              │ HTTPS chunks
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  INSTAGRAM CLOUD                                                 │
│  Ingest API → Reassemble → Validation → Processing Pipeline     │
│  Transcode + Compress + Multi-res → Thumbnails → Object Storage │
└────────────────────────────┬────────────────────────────────────┘
                              │ Push to edge
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  CDN EDGE NETWORK                                               │
│  Edge Node (Tokyo) │ Edge Node (London) │ Edge Node (São Paulo) │
└───────────┬─────────────────┬───────────────────┬──────────────┘
            │                 │                   │
            ▼                 ▼                   ▼
       Viewer (JP)       Viewer (UK)        Viewer (BR)
   ABR stream → cache   ABR stream → cache  ABR stream → cache

Key Takeaways for Mobile Developers

Building a React Native app with media features? Steal these patterns:

Local-first: Always write to local storage before assuming network success
Atomic draft saves: Video file + metadata must succeed together or both fail
Chunked uploads: Never send large files as single requests; build retry logic per chunk
Background transfers: Use OS-level APIs, not in-app timers
Queue your uploads: Persist queue state to SQLite; recover from kills gracefully
Multi-level caching: Memory + disk + prefetch = fast perceived performance
CDN for media, API for metadata: Your app servers shouldn't serve video files
Adaptive quality: Detect connection quality and degrade gracefully

Wrapping Up

What looks like a simple "save" or "post" action is actually a cascade of decisions made across every layer of the stack: memory buffers, SQLite databases, upload queues, processing pipelines, object storage, CDN edge networks, and device-side caches.

Understanding this architecture helps you build mobile apps that feel fast, handle failures gracefully, and respect your users' devices and data connections. Architecture and product thinking are inseparable — every engineering decision is ultimately a UX decision.

What would you like to explore next — building a resumable upload queue in React Native, implementing multi-level caching, or designing a local draft system? Let me know in the comments!

How React's Virtual DOM Works Under the Hood

Janmejai Singh — Thu, 21 May 2026 16:32:54 +0000

How React's Virtual DOM Works Under the Hood

You've heard it a hundred times: "React uses a Virtual DOM for performance."

But what does that actually mean?

In this article, we'll trace exactly what happens from the moment you call setState() to the moment you see pixels update on screen — no hand-waving, no magic, just the mental model that unlocks everything else in React.

Let's dig in. 🛠️

The Problem: Why Direct DOM Manipulation Is Slow

Before we understand the solution, we need to understand the problem.

The browser's DOM (Document Object Model) is a live, tree-shaped object that represents your HTML page. Whenever JavaScript changes a DOM node, the browser has to do expensive work:

Style recalculation — which CSS rules now apply?
Layout / Reflow — what is every element's new size and position?
Repaint — what pixels need to be redrawn?

Direct DOM Update:
─────────────────
JS writes to DOM
     │
     ▼
Style Recalc → Layout (Reflow) → Paint → Composite
                    ↑
               ALL of this, potentially,
               for a single text change 😬

This is fine for occasional updates. But modern web apps update the UI constantly — typed characters, live data feeds, animations. At high frequency, direct DOM manipulation becomes a bottleneck that shows up as janky, sluggish UIs.

The Solution: Virtual DOM as a Lightweight Proxy

React introduces the Virtual DOM: a plain JavaScript representation of the UI tree that exists purely in memory, completely decoupled from the browser's rendering engine.

// This is a Virtual DOM node. It's just a JS object.
{
  type: 'button',
  props: {
    className: 'btn-primary',
    onClick: handleClick,
    children: 'Click me'
  }
}

Creating this object costs almost nothing. No browser APIs. No layout. No paint. It's just memory allocation.

React's insight: compute changes cheaply in JS-land first, then apply the minimal real-DOM mutations in one go.

Step 1 — Initial Render

When your app first loads:

JSX / Components
      │
      │  (Babel compiles JSX to React.createElement calls)
      ▼
Virtual DOM Tree
(plain JS objects, built entirely in memory)
      │
      │  (React walks the tree and creates real nodes)
      ▼
Real DOM  ←  User sees the UI ✅

React calls your component functions, collects the returned JSX (which becomes React.createElement() calls), and assembles a full Virtual DOM tree. It then makes a single full pass to create and insert real DOM nodes.

This is the only time React builds the entire DOM from scratch.

Step 2 — State or Props Change

Something triggers an update:

const [count, setCount] = useState(0);

// Button clicked:
setCount(count + 1);  // 🔔 React queues a re-render

setCount doesn't immediately update the DOM. React schedules an update and may batch it with other pending updates for efficiency. Then it moves into the render phase.

Step 3 — New Virtual DOM Tree is Created

React re-runs your component function with the new state. The result is a brand new Virtual DOM tree in memory:

 OLD Virtual DOM          NEW Virtual DOM
 ───────────────          ───────────────
 <div>                    <div>
   <h1>Score</h1>   vs      <h1>Score</h1>
   <span>0</span>           <span>1</span>  ← CHANGED
   <button>+</button>       <button>+</button>
 </div>                   </div>

Both trees exist in memory simultaneously. React needs to figure out what's different.

Step 4 — Diffing (Reconciliation)

React's diffing algorithm compares the two trees node-by-node to produce a minimal change set.

Comparing node by node:

  <div>        ✅ Same type → keep, recurse into children
  <h1>Score</h1>  ✅ Same type, same props → NO CHANGE
  <span>       ✅ Same type → check props
    "0" → "1"  ❌ Text content changed → MARK FOR UPDATE
  <button>+</button>  ✅ Same type, same props → NO CHANGE

Change set: [ updateTextContent(spanNode, "1") ]

React uses two key heuristics to keep this efficient:

Different element types → rebuild the subtree

If a <div> becomes a <section> at the same position, React doesn't try to reuse it. It destroys the old subtree and builds a new one.

Keys → stable identity for list items

// ❌ Bad — React can't tell which item is which after reorder
{items.map(item => <li>{item.name}</li>)}

// ✅ Good — React can match, reuse, and correctly update items
{items.map(item => <li key={item.id}>{item.name}</li>)}

Keys let React correlate old list nodes with new ones. Without them, React might destroy and re-create nodes it could have reused — wasting work and losing local state (like focus or scroll position).

Step 5 — Commit Phase: Minimal Real DOM Updates

Once the diff is done, React enters the commit phase — the only point where it writes to the real DOM:

Change set from diff:
┌──────────────────────────────────────┐
│  • Update text of <span>: 0 → 1     │
│  (1 operation total)                 │
└──────────────────────────────────────┘
         │
         ▼
  Real DOM ← only the <span>'s text node is touched
  Everything else: untouched, no reflow triggered 🎯

Compare this to a naive approach that re-renders the entire list after every keystroke. With React, only the nodes that actually changed are touched.

Why This Improves Performance

Approach	What Happens on Update
Direct DOM manipulation	Write immediately → browser reflows everything potentially affected
React Virtual DOM	Diff in memory → write only changed nodes → minimal browser work

The Virtual DOM isn't magic. Creating JS objects has a cost too. The real win is batching and minimization: React figures out the cheapest path from the current UI to the desired UI, then executes it in one optimized burst.

The Full Lifecycle — Visual Summary

┌────────────────────────────────────────────────────────┐
│            REACT: RENDER → DIFF → COMMIT               │
│                                                        │
│  setState() / new props                                │
│       │                                                │
│       ▼                                                │
│  ┌─────────────────────────────────────┐               │
│  │         RENDER PHASE                │               │
│  │  Component functions run            │               │
│  │  New Virtual DOM tree built         │               │
│  └──────────────┬──────────────────────┘               │
│                 │                                      │
│                 ▼                                      │
│  ┌─────────────────────────────────────┐               │
│  │      RECONCILIATION (DIFF) PHASE    │               │
│  │                                     │               │
│  │  Old VDOM ◄──── compared ────► New VDOM             │
│  │  Minimal change set computed        │               │
│  └──────────────┬──────────────────────┘               │
│                 │                                      │
│                 ▼                                      │
│  ┌─────────────────────────────────────┐               │
│  │         COMMIT PHASE                │               │
│  │  Only changed nodes written to DOM  │               │
│  │  useLayoutEffect runs               │               │
│  └──────────────┬──────────────────────┘               │
│                 │                                      │
│                 ▼                                      │
│  Browser paints minimal changes ✅                     │
│  useEffect runs                                        │
└────────────────────────────────────────────────────────┘

Quick Reference: Key Concepts

Concept	What It Means
Virtual DOM	Plain JS object tree mirroring the UI — cheap to create
Re-render	React calling your component function again to get new VDOM
Diffing	Comparing old VDOM vs new VDOM to find changes
Reconciliation	The full process: diff + decide what to update
Commit	The moment React writes to the real DOM
Key	Stable identity hint for list items during diffing

Things to Know (But Out of Scope Here)

React Fiber — React's internal concurrent scheduler that adds priority lanes and time-slicing on top of this model
React 18 Concurrent Mode — useTransition and useDeferredValue let you mark updates as non-urgent
React.memo — skips re-render (and therefore skips VDOM creation) when props haven't changed

Wrapping Up

React's Virtual DOM is elegant in its simplicity: represent the UI as cheap JS objects, compare states, compute minimal mutations, apply them. The render → diff → commit pipeline is the foundation of React's performance story — and once you have this mental model, concepts like key, memo, and concurrent features all start making intuitive sense.

If this clicked for you, follow along — next up we're diving into React Keys deep dive and why index-as-key breaks your app in surprising ways.

Happy coding! ⚛️

Tagged: #react #javascript #webdev #beginners

How DNS Resolution Works: From `dig . NS` to Your Browser Loading Google

Janmejai Singh — Sat, 09 May 2026 09:24:28 +0000

Every time you type google.com into a browser, something remarkable happens in milliseconds — a global, distributed lookup system translates that human-readable name into a machine-readable IP address. No single server handles this. No central database stores it all.

This is DNS, and understanding how it works will make you a sharper developer, a better debugger, and a more informed system designer.

In this article, we'll use the dig command to inspect each layer of DNS resolution, building a mental model from the ground up.

Why Name Resolution Exists

Computers communicate using IP addresses — numerical labels like 142.250.195.78. Every server on the internet has one. But humans don't think in IP addresses. We think in names.

DNS (Domain Name System) solves this mismatch. It's the protocol and infrastructure that translates google.com → 142.250.195.78 so your browser knows where to send its request.

What makes DNS interesting (and worth understanding deeply) is its architecture:

Distributed — No single server holds all records. The system delegates responsibility across a global hierarchy.
Cached — Responses are stored at multiple levels to reduce latency.
Fault-tolerant — Each layer has multiple servers so no single failure breaks name resolution.

Meet `dig` — Your DNS Diagnostic Tool

dig (Domain Information Groper) is a command-line utility for querying DNS name servers. It ships with most Unix-like systems and is the go-to tool for DNS inspection.

Install it:

# macOS — usually pre-installed
dig --version

# Ubuntu / Debian
sudo apt install dnsutils

# CentOS / RHEL / Fedora
sudo yum install bind-utils

Basic syntax:

dig [domain] [record_type] [options]

Useful flags:

+short          # Concise output (just the answer)
+trace          # Full recursive trace from root down
@8.8.8.8        # Use a specific resolver
+norecurse      # Query the server directly without recursion

Now let's use dig to walk the DNS hierarchy from top to bottom.

The DNS Hierarchy at a Glance

Before commands, here's the architecture we're navigating:

                         ┌─────────────┐
                         │   Root NS   │  ← dig . NS
                         │  (. zone)   │
                         └──────┬──────┘
                                │ "Ask .com servers"
                         ┌──────▼──────┐
                         │   TLD NS    │  ← dig com NS
                         │ (.com zone) │
                         └──────┬──────┘
                                │ "Ask Google's servers"
                         ┌──────▼──────┐
                         │ Auth NS     │  ← dig google.com NS
                         │(google.com) │
                         └──────┬──────┘
                                │ "Here's the IP"
                         ┌──────▼──────┐
                         │  A Record   │  ← dig google.com
                         │142.250.x.x  │
                         └─────────────┘

DNS resolution is a top-down delegation chain. Each layer only knows how to refer you to the next. Let's explore each layer.

Layer 1: Root Name Servers — `dig . NS`

dig . NS

The . (dot) is the DNS root zone — the very top of the entire DNS hierarchy.

Output:

;; ANSWER SECTION:
.    518400  IN  NS  a.root-servers.net.
.    518400  IN  NS  b.root-servers.net.
.    518400  IN  NS  c.root-servers.net.
...
.    518400  IN  NS  m.root-servers.net.

There are 13 root name server names (a through m), but behind each name sit hundreds of physical servers globally — distributed via anycast routing. They're operated by a mix of organizations: ICANN, NASA, Verisign, Internet Systems Consortium, and others.

What they do: Root servers don't know the IP of google.com. They only know which servers are responsible for each Top-Level Domain (.com, .org, .net, .io, etc.).

The TTL of 518400 (6 days) tells you how stable these records are. Root server information almost never changes.

What NS records mean: An NS record points to the name server responsible for a DNS zone. Here, the root zone's NS records point to... the root servers themselves.

Layer 2: TLD Name Servers — `dig com NS`

dig com NS

Now we query the name servers for the .com TLD.

Output:

;; ANSWER SECTION:
com.    172800  IN  NS  a.gtld-servers.net.
com.    172800  IN  NS  b.gtld-servers.net.
...
com.    172800  IN  NS  m.gtld-servers.net.

These are Verisign's gTLD (Generic Top-Level Domain) servers — responsible for the entire .com namespace. Over 160 million domain names fall under their jurisdiction.

What they do: When a recursive resolver asks "Who is authoritative for google.com?", the gTLD servers respond with Google's name server hostnames. They do not know Google's IP address directly — they only know who to ask next.

System Design Insight: This delegation model is what allows DNS to scale to billions of domains. No single database. No central authority below the root. Responsibility is partitioned and delegated hierarchically.

Layer 3: Authoritative Name Servers — `dig google.com NS`

dig google.com NS

Now we find the servers that actually own Google's DNS records.

Output:

;; ANSWER SECTION:
google.com.    21600  IN  NS  ns1.google.com.
google.com.    21600  IN  NS  ns2.google.com.
google.com.    21600  IN  NS  ns3.google.com.
google.com.    21600  IN  NS  ns4.google.com.

These are Google's own authoritative name servers. Unlike the layers above them, these servers hold the actual DNS records:

Record Type	Purpose
`A`	IPv4 address
`AAAA`	IPv6 address
`MX`	Mail server
`CNAME`	Canonical alias
`TXT`	Verification, SPF, DKIM

Google runs its own infrastructure here. Many companies delegate this to DNS providers like Cloudflare, AWS Route 53, or Namecheap instead.

The TTL of 21600 (6 hours) is shorter than root/TLD records because these records can change — for example, when rotating infrastructure or updating configs.

The Full Resolution — `dig google.com`

dig google.com

This is the query your browser ultimately needs: "What's the IP address for google.com?"

Output:

;; QUESTION SECTION:
;google.com.                    IN  A

;; ANSWER SECTION:
google.com.    300    IN  A    142.250.195.78

;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

Breaking It Down

Field	Explanation
`IN A`	Internet class, A (IPv4) record type
`142.250.195.78`	The actual IP address your browser connects to
`300`	TTL of 5 minutes — Google rotates IPs frequently for load balancing
`Query time: 12 msec`	Fast because this was cached by `8.8.8.8`
`SERVER: 8.8.8.8`	Google's public DNS answered this query

The Step-by-Step Flow (Uncached)

1. You type google.com
   ↓
2. Browser checks its DNS cache → miss
   ↓
3. OS checks /etc/hosts + system cache → miss
   ↓
4. Query sent to recursive resolver (8.8.8.8)
   ↓
5. Resolver asks Root NS: "Who handles .com?"
   ← "Ask a.gtld-servers.net"
   ↓
6. Resolver asks gTLD NS: "Who handles google.com?"
   ← "Ask ns1.google.com"
   ↓
7. Resolver asks ns1.google.com: "What's the A record for google.com?"
   ← "142.250.195.78, TTL 300"
   ↓
8. Resolver returns IP to your OS, caches it for 300 seconds
   ↓
9. Browser opens TCP connection to 142.250.195.78:443
   ↓
10. TLS handshake → HTTP request → Page loads ✓

The whole chain (steps 5–7) typically completes in under 100ms.

Recursive Resolvers: The Unsung Heroes

A recursive resolver is the server that does the work of traversing the hierarchy on your behalf. When you configure DNS on your router or device, you're pointing to a recursive resolver.

Your Device
    │
    ▼
Recursive Resolver (8.8.8.8)
    │  Checks its cache first...
    │  If miss, walks the chain:
    ├──► Root NS      → referral
    ├──► TLD NS       → referral
    └──► Auth NS      → answer ✓
         Caches the result
         Returns to you

Why Caching Matters

Every DNS response includes a TTL (Time to Live). Recursive resolvers cache answers for that duration before querying again.

Root NS TTLs      → ~2 days   (very stable)
TLD NS TTLs       → ~2 days   (very stable)
Auth NS TTLs      → hours     (occasionally updated)
A record TTLs     → seconds to hours (varies by domain)

This is why DNS changes take time to "propagate" — resolvers worldwide are still serving cached responses until TTLs expire. When you update a DNS record, it's fully live for everyone only after the old TTL has expired everywhere.

Popular Public Recursive Resolvers

8.8.8.8      → Google Public DNS
1.1.1.1      → Cloudflare DNS (fastest globally, strong privacy)
9.9.9.9      → Quad9 (security-focused, blocks malware domains)
208.67.222.222 → OpenDNS (Cisco)

Mapping `dig` Commands to DNS Stages

Here's a quick reference connecting each command to its role in the resolution flow:

dig . NS            # Stage 1: Who are the root name servers?
dig com NS          # Stage 2: Who manages the .com TLD?
dig google.com NS   # Stage 3: Who is authoritative for google.com?
dig google.com      # Stage 4: What's the actual IP address?

Or run them all at once with the trace flag:

dig +trace google.com

+trace makes dig itself walk the full hierarchy — from root to authoritative — and print every step. It's the most educational single command for understanding DNS resolution.

DNS in the Context of Real Browser Requests

When you visit https://google.com, DNS is step zero of the entire connection:

DNS Resolution       → ~1ms (cached) to ~100ms (fresh)
TCP Handshake        → ~10–50ms
TLS Handshake        → ~20–100ms
HTTP Request         → ~10–50ms
Page Render          → varies

DNS is often the fastest part once cached — but a cold DNS lookup on first visit adds real latency. This is why modern browsers implement:

DNS prefetching — Pre-resolving domains found in <link rel="dns-prefetch"> or in page links
Connection pre-warming — Opening TCP/TLS connections before the user clicks
HTTP/3 with QUIC — Reduces connection overhead after DNS

And infrastructure teams use:

Low TTLs (60–300s) on CDN records to route users to the nearest edge node
DNS-based load balancing — Returning different IPs based on geography or health
DNS-over-HTTPS (DoH) — Encrypting DNS queries so ISPs can't snoop on which sites you visit

Quick Reference Card

# The resolution hierarchy
dig . NS                    # Root name servers
dig com NS                  # .com TLD name servers
dig google.com NS           # Authoritative name servers
dig google.com              # Final A record (IPv4)

# Other record types
dig google.com AAAA         # IPv6 address
dig google.com MX           # Mail servers
dig google.com TXT          # TXT records (SPF, DKIM, verification)
dig google.com CNAME        # Canonical name alias

# Diagnostic flags
dig +short google.com       # Just the IP
dig +trace google.com       # Full resolution trace from root
dig @1.1.1.1 google.com    # Force a specific resolver
dig +norecurse @a.root-servers.net google.com  # Direct root query

Key Takeaways

DNS is hierarchical and distributed. No single server knows everything — each layer delegates to the next.
Root servers (. NS) point to TLD servers. There are 13 names, backed by hundreds of anycast servers.
TLD servers (e.g., com NS) point to authoritative servers for each domain.
Authoritative servers hold the actual records — A, MX, TXT, CNAME, etc.
Recursive resolvers traverse the full chain on your behalf and cache results using TTLs.
dig +trace is the fastest way to see the entire resolution chain in one command.

Resources

If this helped you build a clearer mental model of DNS, share it with your cohort. Understanding the infrastructure beneath the web makes you a better engineer at every layer of the stack.

Template Literals in JavaScript — From Messy Concatenation to Clean, Modern Strings

Janmejai Singh — Sat, 09 May 2026 09:16:32 +0000

Template Literals in JavaScript — From Messy Concatenation to Clean, Modern Strings

JavaScript strings used to be a chore. Between escaped quotes, awkward \n newlines, and chains of + operators, writing dynamic strings felt like assembling furniture with the wrong tools.

ES6 template literals changed all of that in 2015. A decade later, they're still one of the most impactful readability improvements in modern JavaScript — and they're still underused by developers who haven't fully made the switch.

This guide covers everything: the problem, the solution, the syntax, real use cases, and the advanced tricks most tutorials skip.

The Problem with String Concatenation

Let's start honest. Here's what string-building looked like before template literals:

const firstName = "Ananya";
const lastName = "Sharma";
const score = 98;
const subject = "JavaScript";

// 😩 Traditional approach
const report = "Student: " + firstName + " " + lastName + 
               "\nSubject: " + subject + 
               "\nScore: " + score + "/100" +
               "\nStatus: " + (score >= 60 ? "Pass" : "Fail");

console.log(report);

This works. But it's:

Hard to read (you have to mentally track + and " pairs)
Easy to mess up (a missing space inside quotes? typo city)
Painful to maintain (adding a new line means touching the whole chain)
Ugly for multi-line output (\n inside strings is visual noise)

The more complex your string, the worse this gets.

The Solution: Template Literal Syntax

Template literals use backticks (`) instead of quotes.

// That's it. This is a template literal.
const greeting = `Hello, World!`;

But the real power comes from two features packed inside: string interpolation and native multi-line support.

String Interpolation: `${}` Is Your New Best Friend

Embed any variable or expression using ${expression} inside the backticks:

const firstName = "Ananya";
const lastName = "Sharma";
const score = 98;
const subject = "JavaScript";

// ✅ Template literal approach
const report = `Student: ${firstName} ${lastName}
Subject: ${subject}
Score: ${score}/100
Status: ${score >= 60 ? "Pass" : "Fail"}`;

console.log(report);
// Student: Ananya Sharma
// Subject: JavaScript
// Score: 98/100
// Status: Pass

Same output. Completely different experience writing and reading it.

The `${}` Placeholder Accepts Any Expression

const a = 10;
const b = 5;

console.log(`Sum: ${a + b}`);         // Sum: 15
console.log(`Power: ${a ** b}`);      // Power: 100000
console.log(`Max: ${Math.max(a, b)}`); // Max: 10

// Functions inline
const shout = str => str.toUpperCase();
console.log(`Shout: ${shout("hello")}`); // Shout: HELLO

// Arrays
const fruits = ["Mango", "Papaya", "Guava"];
console.log(`Fruits: ${fruits.join(", ")}`); // Fruits: Mango, Papaya, Guava

// Objects
const user = { name: "Rahul", tier: "Pro" };
console.log(`User ${user.name} is on the ${user.tier} plan.`);
// User Rahul is on the Pro plan.

Multi-line Strings: Just Press Enter

No more \n. No more string concatenation across lines. With template literals, line breaks are literal:

// ❌ Old approach
const oldEmail = "Dear Vikram,\n\n" +
  "Thank you for joining Web Dev Cohort 2026.\n" +
  "Your first session starts on March 16.\n\n" +
  "Best regards,\nThe Team";

// ✅ New approach
const email = `Dear Vikram,

Thank you for joining Web Dev Cohort 2026.
Your first session starts on March 16.

Best regards,
The Team`;

The template literal version looks exactly like the output — no translation required.

Building HTML Fragments

This is where multi-line template literals really shine:

const product = {
  name: "Mechanical Keyboard",
  price: 3499,
  inStock: true,
  rating: 4.7
};

// ✅ Clean HTML template
const card = `
  <div class="product-card">
    <h3>${product.name}</h3>
    <p class="price">₹${product.price.toLocaleString("en-IN")}</p>
    <span class="badge ${product.inStock ? "in-stock" : "out-of-stock"}">
      ${product.inStock ? "In Stock" : "Out of Stock"}
    </span>
    <p>⭐ ${product.rating}/5</p>
  </div>
`.trim();

document.querySelector("#app").innerHTML = card;

Before vs After: The Visual Comparison

Here's a side-by-side that shows just how dramatic the improvement is:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  BEFORE: String Concatenation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  "Welcome, " + user + "! You have " + count
  + " message" + (count !== 1 ? "s" : "") + "."

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  AFTER: Template Literal
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  `Welcome, ${user}! You have ${count}
  message${count !== 1 ? "s" : ""}.`

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Same logic. The template literal version is scannable at a glance.

Nested Template Literals

Template literals can be nested — useful for generating lists from arrays:

const students = ["Arjun", "Priya", "Karan"];

const html = `
  <ul class="student-list">
    ${students.map(name => `<li>${name}</li>`).join("\n    ")}
  </ul>
`;

console.log(html);
// <ul class="student-list">
//   <li>Arjun</li>
//   <li>Priya</li>
//   <li>Karan</li>
// </ul>

Tagged Templates: The Advanced Feature

Tagged templates let you intercept template literal processing with a function. The tag function receives the static string parts and the interpolated values separately.

// Syntax: tagFunction`string ${value} more string`

function currencyINR(strings, ...values) {
  return strings.reduce((result, str, i) => {
    const value = values[i - 1];
    const formatted = typeof value === "number"
      ? `₹${value.toLocaleString("en-IN")}`
      : value;
    return result + (formatted ?? "") + str;
  });
}

const price = 149999;
const item = "MacBook Pro";

console.log(currencyINR`The ${item} costs ${price} after GST.`);
// The MacBook Pro costs ₹1,49,999 after GST.

Where Tagged Templates Are Used in the Wild

styled-components.com

// styled-components — CSS-in-JS
const Button = styled.button`
  background: ${props => props.primary ? "#0070f3" : "white"};
  color: ${props => props.primary ? "white" : "#0070f3"};
  padding: 0.5rem 1.25rem;
  border-radius: 6px;
`;

// GraphQL (Apollo / urql)
const GET_USER = gql`
  query GetUser($id: ID!) {
    user(id: $id) {
      name
      email
    }
  }
`;

// Lit HTML
const template = html`<p>Hello, ${name}!</p>`;

Tagged templates are one of the most powerful and underrated features in modern JavaScript.

String.raw — A Built-in Tag

JavaScript ships with String.raw, a built-in tag that prevents escape sequence processing:

// Regular template literal
console.log(`C:\new\folder`);
// C:
// ew
// older   ← \n and \f were interpreted!

// String.raw — preserves backslashes
console.log(String.raw`C:\new\folder`);
// C:\new\folder  ← exactly as written

Handy for Windows file paths, regex patterns, and LaTeX strings.

Real-World Use Cases Cheat Sheet

// 1. API endpoint construction
const getUser = (id) => `${API_BASE}/users/${id}/profile`;
const search = (q, page) => `${API_BASE}/search?q=${encodeURIComponent(q)}&page=${page}`;

// 2. Dynamic class names (React / Vanilla JS)
const btnClass = `btn ${isLoading ? "btn--loading" : ""} ${variant}`.trim();

// 3. Structured log messages
const log = (level, msg) =>
  `[${new Date().toISOString()}] [${level}] ${msg}`;

// 4. Error messages with context
throw new Error(`Expected type "string" but got "${typeof value}" at key "${key}".`);

// 5. SQL query building (static parts only — always parameterize user input!)
const query = `
  SELECT id, name, email
  FROM users
  WHERE role = 'admin'
  ORDER BY created_at DESC
  LIMIT ${pageSize} OFFSET ${page * pageSize}
`;

// 6. SVG generation
const circle = (cx, cy, r, color) =>
  `<circle cx="${cx}" cy="${cy}" r="${r}" fill="${color}" />`;

Common Pitfalls to Avoid

1. Unintended leading/trailing whitespace

const msg = `
  Hello
`;
// msg starts with \n and has trailing \n
// Use .trim() if you need to remove them

2. Nested backticks need escaping

// ❌ Syntax error
const str = `Click the `Run` button`;

// ✅ Escaped backtick
const str = `Click the \`Run\` button`;

3. XSS risk with innerHTML

// ⚠️ Don't do this with untrusted user input
element.innerHTML = `<p>${userInput}</p>`;

// ✅ Use textContent for plain text
element.textContent = userInput;

// ✅ Or sanitize with DOMPurify for HTML
element.innerHTML = DOMPurify.sanitize(`<p>${userInput}</p>`);

Feature Comparison Table

Feature	Old Concatenation	Template Literals
Syntax	`"" + var + ""`	`${var}`
Readability	❌ Cluttered	✅ Clean
Multi-line	❌ `\n` hacks	✅ Natural
Expressions	❌ Awkward `+`	✅ Inside `${}`
Nested structures	❌ Very messy	✅ Composable
Advanced processing	❌ Not possible	✅ Tagged templates
Raw strings	❌ Manual escape	✅ `String.raw`
Performance	Same	Same
Browser support	All	ES6+ / all modern

TL;DR — Everything in One Block

// ── Basic ─────────────────────────────────────
const name = "Dev";
const msg = `Hello, ${name}!`;

// ── Expression ────────────────────────────────
const tax = `Total: ₹${(price * 1.18).toFixed(2)}`;

// ── Multi-line ────────────────────────────────
const html = `
  <h1>${title}</h1>
  <p>${body}</p>
`;

// ── Ternary ───────────────────────────────────
const status = `${online ? "🟢 Online" : "🔴 Offline"}`;

// ── Nested ────────────────────────────────────
const list = `<ul>${items.map(i => `<li>${i}</li>`).join("")}</ul>`;

// ── Tagged ────────────────────────────────────
const safe = sanitize`User said: ${input}`;

// ── Raw ───────────────────────────────────────
const path = String.raw`C:\Users\Dev\Documents`;

Conclusion

Template literals aren't a gimmick — they solve a genuine pain point in JavaScript. Every time you use them, you're writing code that's cleaner, safer, and easier for others (including future you) to understand.

The switch from + concatenation is almost zero effort, and the payoff is immediate. If you're building anything with strings — and you always are — template literals belong in your default toolkit.

Found this helpful? Drop a ❤️, save it for reference, and share it with someone who's still typing "Hello " + name + "!".

Part of the Web Dev Cohort 2026 series — new JavaScript fundamentals every week.

Discussion

What's the most creative use of tagged templates you've seen in production?
Do you use template literals by default now, or do you still reach for quotes sometimes?

Let's talk in the comments 👇

Flattening Arrays in JavaScript — The Complete Visual Guide

Janmejai Singh — Sat, 09 May 2026 09:06:51 +0000

🪆 Flattening Arrays in JavaScript — The Complete Visual Guide

Imagine a Russian nesting doll. You open one, find another. Open that, find another. That's a nested array. Our job? Unpack them all into one flat row.

📦 What Are Nested Arrays?

A nested array is simply an array that contains other arrays as its elements. Arrays inside arrays. Boxes inside boxes.

// Simple flat array
const flat = [1, 2, 3, 4, 5];

// Nested array — arrays inside arrays
const nested = [1, [2, 3], [4, [5, 6]], [[[7]]]];

Visualizing the layers:

[1, [2, 3], [4, [5, 6]], [[[7]]]]
 ^   ^^^^^   ^^^^^^^^^^   ^^^^^^
 |   |        |            |
 |   depth 1  depth 1+2    depth 1+2+3
 depth 0 (top level)

These show up all the time in real code:

🌐 API responses — deeply nested JSON objects
🗃️ Database results — grouped or paginated data
📁 File system trees — folders containing folders
🧮 Matrix math — rows and columns
🗺️ Category trees — parent/child hierarchies

🤔 Why Flatten at All?

Here's the problem with nested arrays:

const scores = [[85, 92], [78, 95], [88, 71]];

// ❌ .includes() won't work as expected
scores.includes(85); // false — it's looking for [85, 92]

// ❌ .length is misleading
scores.length; // 3 — but there are 6 actual scores

// ❌ Can't sort all values directly
scores.sort(); // sorts sub-arrays, not values

After flattening:

const flat = scores.flat();
// → [85, 92, 78, 95, 88, 71]

flat.includes(85);  // ✅ true
flat.length;        // ✅ 6
flat.sort((a, b) => a - b); // ✅ [71, 78, 85, 88, 92, 95]

🧠 The Core Concept

Flattening = pulling all values out of their nested containers into a single flat array.

BEFORE:                        AFTER:
┌──────────────────────┐       ┌────────────────────────────┐
│ [                    │       │                            │
│   1,                 │       │  [ 1, 2, 3, 4, 5, 6, 7 ]  │
│   [2, 3],            │  ──►  │                            │
│   [4, [5, 6]],       │       └────────────────────────────┘
│   [[[7]]]            │
│ ]                    │
└──────────────────────┘

The key variable: how deep do you need to flatten?

Depth	What it does
`1`	Unwraps only the outermost arrays
`2`	Unwraps two levels
`Infinity`	Fully flattens everything

🛠️ Every Method, Explained

1️⃣ `Array.flat()` — The Native, Modern Way

flat() was introduced in ES2019 and is the most readable, idiomatic solution.

const arr = [1, [2, 3], [4, [5, 6]], [[[7]]]];

arr.flat();           // depth 1 (default)
// → [1, 2, 3, 4, [5, 6], [[[7]]]]

arr.flat(2);          // depth 2
// → [1, 2, 3, 4, 5, 6, [[[7]]]]

arr.flat(Infinity);   // flatten everything
// → [1, 2, 3, 4, 5, 6, 7]

Step-by-step for flat(1):

Input: [1, [2, 3], [4, [5, 6]]]

1         → not an array → keep: 1
[2, 3]    → array at depth 1 → unwrap: 2, 3
[4, [5,6]]→ array at depth 1 → unwrap: 4, [5,6]
                                     ↑ still nested (depth 2)

Output: [1, 2, 3, 4, [5, 6]]

✅ Use when: Working in modern codebases. Clean, expressive, handles depth.

2️⃣ `flatMap()` — Map + Flatten in One Pass

flatMap() maps each element and then flattens one level. It's like a supercharged .map().

const words = ["Hello World", "JS is great"];

words.map(w => w.split(" "));
// → [["Hello", "World"], ["JS", "is", "great"]]

words.flatMap(w => w.split(" "));
// → ["Hello", "World", "JS", "is", "great"]

Real-world: extract all tags from a blog array:

const posts = [
  { title: "Async Await", tags: ["js", "async"] },
  { title: "CSS Grid",    tags: ["css", "layout"] },
  { title: "Node.js",     tags: ["node", "js"] },
];

const allTags = posts.flatMap(p => p.tags);
// → ["js", "async", "css", "layout", "node", "js"]

const uniqueTags = [...new Set(allTags)];
// → ["js", "async", "css", "layout", "node"]

✅ Use when: You need to transform + flatten simultaneously. Only goes 1 level deep.

3️⃣ `reduce()` — The Foundational Approach

Before flat() landed in ES2019, reduce() was the standard approach. Still great to know.

const arr = [1, [2, 3], [4, 5]];

const flat = arr.reduce((acc, val) => acc.concat(val), []);
// → [1, 2, 3, 4, 5]

Step-by-step accumulation:

Initial:  acc = []

Item 1:   val = 1       → [].concat(1)        = [1]
Item 2:   val = [2, 3]  → [1].concat([2,3])   = [1, 2, 3]
Item 3:   val = [4, 5]  → [1,2,3].concat([4,5]) = [1, 2, 3, 4, 5]

For deep flattening with reduce — use recursion:

function deepFlatReduce(arr) {
  return arr.reduce((acc, val) =>
    Array.isArray(val)
      ? acc.concat(deepFlatReduce(val))
      : acc.concat(val),
  []);
}

deepFlatReduce([1, [2, [3, [4]]]]);
// → [1, 2, 3, 4]

✅ Use when: You want custom logic while flattening (filter, transform, accumulate).

4️⃣ Recursive Flatten — The Interview Essential

This is the approach you must be able to write from scratch in interviews.

function flatten(arr) {
  const result = [];

  for (const item of arr) {
    if (Array.isArray(item)) {
      result.push(...flatten(item)); // recurse deeper
    } else {
      result.push(item);             // base case
    }
  }

  return result;
}

flatten([1, [2, [3, [4, [5]]]]]);
// → [1, 2, 3, 4, 5]

Call stack diagram for flatten([1, [2, [3]]]):

flatten([1, [2, [3]]])
├─ item = 1          → push 1
└─ item = [2, [3]]   → recurse:
      flatten([2, [3]])
      ├─ item = 2        → push 2
      └─ item = [3]      → recurse:
            flatten([3])
            └─ item = 3    → push 3
            return [3]
      return [2, 3]
   push ...2, 3
return [1, 2, 3]

✅ Use when: Interviews, learning, or environments without ES2019 support.

5️⃣ Iterative Stack — Recursion-Safe 🔐

Deep recursion can cause stack overflow for extremely nested arrays. This stack-based approach avoids that:

function flattenSafe(arr) {
  const stack = [...arr];
  const result = [];

  while (stack.length) {
    const item = stack.pop();

    if (Array.isArray(item)) {
      stack.push(...item); // push elements back to process
    } else {
      result.unshift(item); // prepend to maintain order
    }
  }

  return result;
}

flattenSafe([1, [2, [3, [4, [5]]]]]);
// → [1, 2, 3, 4, 5]

✅ Use when: Handling user-generated or untrusted deeply nested data.

📊 Quick Comparison

Method	Depth Control	ES Version	Best For
`flat()`	✅ Configurable	ES2019	Most use cases
`flatMap()`	1 level only	ES2019	Map + flatten
`reduce()`	With recursion	ES5	Custom logic
Recursion	✅ Full	ES5	Interviews
Stack iterative	✅ Full	ES5	Very deep nesting

🎯 Interview Questions You'll Actually Face

❓ "Write your own implementation of `flat()`"

Array.prototype.myFlat = function(depth = 1) {
  const result = [];

  function walk(arr, d) {
    for (const item of arr) {
      if (Array.isArray(item) && d > 0) {
        walk(item, d - 1);
      } else {
        result.push(item);
      }
    }
  }

  walk(this, depth);
  return result;
};

[1, [2, [3]]].myFlat(1);        // [1, 2, [3]]
[1, [2, [3]]].myFlat(Infinity); // [1, 2, 3]

❓ "Flatten and remove duplicates"

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

[...new Set(arr.flat(Infinity))];
// → [1, 2, 3, 4]

❓ "Flatten only arrays, keep objects intact"

function flattenArraysOnly(arr) {
  return arr.reduce((acc, val) => {
    if (Array.isArray(val)) {
      acc.push(...flattenArraysOnly(val));
    } else {
      acc.push(val); // objects, strings, numbers — kept as-is
    }
    return acc;
  }, []);
}

flattenArraysOnly([1, [2, { a: 3 }], [[4]]]);
// → [1, 2, { a: 3 }, 4]

❓ "Find the max nesting depth"

function maxDepth(arr) {
  return Array.isArray(arr)
    ? 1 + Math.max(0, ...arr.map(maxDepth))
    : 0;
}

maxDepth([1, [2, [3, [4]]]]);
// → 4

❓ "Flatten and extract values from objects in an array"

const data = [
  { name: "Alice", hobbies: ["reading", "coding"] },
  { name: "Bob",   hobbies: ["gaming", "cooking"] },
];

data.flatMap(person => person.hobbies);
// → ["reading", "coding", "gaming", "cooking"]

🧾 Cheat Sheet

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

// ── Native flat ──────────────────────────────
arr.flat()            // [1, 2, [3, [4]]]     (depth 1)
arr.flat(2)           // [1, 2, 3, [4]]       (depth 2)
arr.flat(Infinity)    // [1, 2, 3, 4]         (full)

// ── flatMap ──────────────────────────────────
[[1,2],[3,4]].flatMap(x => x)  // [1, 2, 3, 4]

// ── reduce ───────────────────────────────────
arr.reduce((a,v) => a.concat(v), [])
// [1, 2, [3, [4]]]  (depth 1)

// ── recursive ────────────────────────────────
function df(a) {
  return a.reduce((acc, v) =>
    acc.concat(Array.isArray(v) ? df(v) : v), []);
}
df(arr)  // [1, 2, 3, 4]

🏆 Key Takeaways

🥇 flat(Infinity) is the cleanest way to fully flatten in modern JS
⚡ flatMap() is perfect when you're transforming data at the same time
🧠 Recursive flatten is a must-know for interviews — understand it cold
🔒 Iterative/stack approach is safest for arbitrarily deep or unknown nesting
🤔 Always ask yourself: "How many levels deep do I actually need?"

💻 Try It!

// Flatten, deduplicate, and sort
const challenge = [[5, 3], [1, [9, 2]], [[[8, 4]]]];

const result = [...new Set(challenge.flat(Infinity))]
  .sort((a, b) => a - b);

console.log(result);
// → [1, 2, 3, 4, 5, 8, 9]

If this helped, drop a ❤️ and share it with a fellow dev!

JavaScript Modules Explained: Import, Export, and Why Your Code Will Thank You

Janmejai Singh — Sat, 09 May 2026 07:31:54 +0000

Stop writing 1,400-line JavaScript files.

I've been there. You come back to a project after three weeks. One file. Everything in it. Functions calling other functions. Variables defined on line 847, used on line 12. You scroll up. You scroll down. You question your career choices.

That's the problem ES Modules solve. And they do it elegantly.

Let's get into it.

Why Modules Exist (The Problem First)

Before ES Modules were standard, JavaScript files shared a single global scope via <script> tags:

<script src="utils.js"></script>
<script src="cart.js"></script>
<script src="app.js"></script>

Every variable from every file lived in the same global bucket. The consequences were predictable:

// utils.js
var discount = 0;

// cart.js — loaded after utils.js
var discount = 0.15; // 💥 silently overwrote utils.js's variable

// app.js
console.log(discount); // 0.15 — but was this intentional?

This is global scope pollution. Files had no walls. Anything could overwrite anything. Debugging was archaeology.

The "solution" some teams used was dumping everything into one giant file. That solved collisions but created a different nightmare: no separation of concerns, no reusability, and merge conflict hell when multiple people edited it.

ES Modules fix both problems at once.

What Is an ES Module?

An ES Module is just a JavaScript file that uses import and export statements. Each module file gets its own private scope — variables and functions defined inside don't leak out unless you explicitly export them.

Before modules:               After modules:

  Global Scope                  file-a.js (own scope)
  ┌────────────────┐            ┌──────────────────┐
  │ var a = 1;     │            │ const a = 1;     │
  │ var b = 2;     │            │ export { a }     │
  │ function c(){} │            └──────────────────┘
  │ function d(){} │
  └────────────────┘            file-b.js (own scope)
    ↑ everything from           ┌──────────────────┐
      all files lands here      │ const b = 2;     │
                                │ export { b }     │
                                └──────────────────┘

Exporting: Making Things Available

Named Exports

Named exports let you share multiple things from a single file:

// math.js

export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

export const PI = 3.14159;

Or declare everything first, then export at the bottom (cleaner for larger files):

// math.js

function add(a, b) { return a + b; }
function subtract(a, b) { return a - b; }
const PI = 3.14159;

export { add, subtract, PI };

Both styles do the same thing.

Default Exports

Default exports are for when a file has one primary thing to offer:

// UserCard.js

export default function UserCard({ name, avatar }) {
  return `<div class="card">${name}</div>`;
}

A module can only have one default export. It represents "what this file is about."

Mixing Both

You can have one default and multiple named exports in the same file:

// api.js

export default async function fetchUser(id) {
  const res = await fetch(`/users/${id}`);
  return res.json();
}

export const BASE_URL = "https://api.example.com";
export function handleError(err) {
  console.error(err.message);
}

Importing: Pulling What You Need

Named Imports (curly braces, exact names)

import { add, PI } from './math.js';

console.log(add(2, 3)); // 5
console.log(PI);         // 3.14159

Use aliases to avoid name conflicts:

import { add as addNumbers } from './math.js';

Default Imports (no curly braces, any name)

import UserCard from './UserCard.js';

// You can name it anything — it's the default export
import Card from './UserCard.js';
import MyCard from './UserCard.js';

Both at Once

import fetchUser, { BASE_URL, handleError } from './api.js';

Import Everything as a Namespace

import * as MathUtils from './math.js';

MathUtils.add(1, 2);  // 3
MathUtils.PI;          // 3.14159

Default vs Named: The Decision Framework

This trips people up. Here's when to use which:

Scenario	Export type
File represents one thing (component, class, main function)	Default
File provides multiple utilities	Named
You want better editor autocomplete	Named (IDEs resolve these more reliably)
You're building a shared library	Named (enables tree shaking)
React component files	Default (community convention)

A simple test: if you'd describe a file as "the ___ module" (singular), use default. If you'd say "a collection of ___ utilities," use named.

// ✅ Default — this file IS the AuthService
export default class AuthService { ... }

// ✅ Named — this file PROVIDES multiple string utils
export function capitalize(str) { ... }
export function truncate(str, len) { ... }
export function slugify(str) { ... }

⚠️ Red flag: if you write export default { util1, util2, util3 } — switch to named exports.

File Dependency Diagram

Here's what a modular project's dependency graph looks like:

main.js
  ├── App.js
  │     ├── Header.js
  │     │     └── logo.js
  │     ├── Cart.js
  │     │     ├── CartItem.js
  │     │     └── formatCurrency.js  ◄──────────────┐
  │     └── Checkout.js                              │
  │           ├── validateForm.js                    │
  │           └── formatCurrency.js  ────────────────┘
  └── router.js
        └── routes.js

formatCurrency.js is imported by two separate files. Written once, used everywhere, no duplication. That's the payoff of modular code.

Module Import/Export Flow

┌───────────────────────────────────────────┐
│               math.js                      │
│                                           │
│  function add(a, b) { return a + b }      │
│  function subtract(a, b) { return a-b }   │
│  const PI = 3.14159                       │
│                                           │
│  export { add, subtract, PI }  ←── public API
└───────────────────────────────────────────┘
                      │
                      │ module system resolves path
                      ▼
┌───────────────────────────────────────────┐
│               app.js                       │
│                                           │
│  import { add, PI } from './math.js'      │
│                                           │
│  // subtract stays private in math.js     │
│  // only add and PI cross the boundary    │
└───────────────────────────────────────────┘

You decide what's public. Everything else is encapsulated by default.

Benefits of Modular Code

1. Encapsulation
Implementation details stay private. Internal helper functions in calculateTax.js don't pollute global scope.

2. Reusability
Write formatDate.js once, import it in ten projects. No copy-pasting, no drift between versions.

3. Maintainability
When something breaks in payment processing, you open payment.js. Not a 3,000-line monolith. You know where to look.

4. Testability
Modules are isolated, which makes them easy to unit test:

// calculateTax.test.js
import { calculateTax } from './calculateTax.js';

test('applies 18% tax correctly', () => {
  expect(calculateTax(100, 0.18)).toBe(118);
});

5. Team Scalability
Two developers can work on Cart.js and Checkout.js simultaneously without touching the same file.

6. Tree Shaking
Bundlers like Vite analyze named imports and remove unused code from production builds. This only works with ES Module named exports — another reason to prefer them for libraries.

Using Modules in the Browser

No bundler required for simple projects. Just add type="module":

<script type="module" src="main.js"></script>

Key behaviors with type="module":

Runs in strict mode automatically
Deferred by default — won't block HTML parsing
Each file has its own scope (that's the whole point)
Requires a local server during dev — can't run from file://

Real-World Example: E-Commerce Cart

Let's put it all together:

// utils/currency.js
export function formatCurrency(amount, currency = 'USD') {
  return new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency
  }).format(amount);
}

export function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price * item.qty, 0);
}

// utils/tax.js
export const TAX_RATES = {
  standard: 0.18,
  reduced: 0.05
};

export function applyTax(amount, rate = TAX_RATES.standard) {
  return amount + amount * rate;
}

// Cart.js
import { formatCurrency, calculateTotal } from './utils/currency.js';
import { applyTax } from './utils/tax.js';

export default class Cart {
  constructor() {
    this.items = [];
  }

  add(item) {
    this.items.push(item);
  }

  getTotal() {
    const subtotal = calculateTotal(this.items);
    const withTax = applyTax(subtotal);
    return formatCurrency(withTax);
  }
}

// main.js
import Cart from './Cart.js';

const cart = new Cart();
cart.add({ name: 'Mechanical Keyboard', price: 89.99, qty: 1 });
cart.add({ name: 'USB-C Hub', price: 34.99, qty: 2 });

console.log(cart.getTotal()); // "$189.48"

Each file has exactly one job. currency.js formats money. tax.js handles tax logic. Cart.js manages cart state. main.js wires it together.

Quick Reference Cheat Sheet

// ─── EXPORTS ──────────────────────────────────

export const name = 'value';              // named inline
export function doThing() {}              // named inline
export { name, doThing };                 // named grouped
export { doThing as performAction };      // named with alias
export default function mainThing() {}    // default


// ─── IMPORTS ──────────────────────────────────

import { name, doThing } from './mod.js';         // named
import { doThing as action } from './mod.js';      // named with alias
import mainThing from './mod.js';                  // default
import mainThing, { name } from './mod.js';        // default + named
import * as Mod from './mod.js';                   // namespace
import './setup.js';                               // side-effect only

Key Takeaways

Every JS file can be a module — it just needs import/export
Named exports → multiple things from one file (use curly braces to import)
Default exports → one main thing per file (no curly braces when importing)
Modules give files private scope by default — nothing leaks unless you export it
Modular code is easier to test, debug, maintain, and reuse
No bundler required for modern browsers — just type="module" on your script tag

The shift from global-scope chaos to modular code is one of the best investments you can make in a codebase. Start small — pick one responsibility, extract it into its own file, export it, import it where needed. Repeat until your codebase has a shape you're proud of.

If this clicked for you, consider leaving a ❤️ or sharing it with someone learning JavaScript. Got questions or a different way you organize your modules? Drop a comment below — I'd love to hear your approach.

DEV Community: Janmejai Singh

What is Middleware in Express and How It Works

What Is Middleware in Express, and How Does It Actually Work?

Middleware as a Checkpoint Between Request and Response

Where Middleware Sits in the Request Lifecycle

Types of Middleware in Express

Application-Level Middleware

Router-Level Middleware

Built-In Middleware

Execution Order of Middleware

The Role of next()

Real-World Examples of Middleware in Action

Logging

Authentication

Request Validation

Visualizing It All Together

Wrapping Up

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

What Cookies Are

What Sessions Are

What JWT Tokens Are

Stateful vs Stateless Authentication

Session-Based Auth vs JWT: A Side-by-Side Comparison

When to Use Each Method

Visualizing the Two Flows

Wrapping Up

DNS Record Types Explained

DNS Record Types Explained: The Phonebook Behind Every Website You Visit

What DNS Is (In Very Simple Terms)

Why DNS Records Are Needed

NS Record: Who's Responsible for This Domain?

A Record: Domain → IPv4 Address

AAAA Record: Domain → IPv6 Address

CNAME Record: One Name Pointing to Another Name

MX Record: How Emails Find Your Mail Server

TXT Record: Extra Information and Verification

How All These Records Work Together for One Website

Wrapping Up

Async Code in Node.js: Callbacks and Promises

Async Code in Node.js: Callbacks and Promises (And Why You Should Care)

Why Async Code Exists in Node.js

Callback-Based Async Execution

The Problem with Nested Callbacks (a.k.a. "Callback Hell")

Promise-Based Async Handling

Benefits of Promises Over Plain Callbacks

Visualizing the Difference

Wrapping Up

Expo Router vs React Navigation - Which One Should You Use in 2026?

Expo Router vs React Navigation: Which One Should You Use in 2026?

1. What "Routing" Actually Means on Mobile

2. Why Navigation Is a Big Deal in React Native

3. A Brief History of React Navigation

4. The Problems Developers Actually Ran Into

5. Why Expo Router Was Introduced

6. File-Based Routing, Explained Simply

7. Nested Layouts and Shared Layouts

8. Protected Routes and Authentication Flows

9. Performance Comparison

Bundle Behavior

Navigation Transitions

Developer Workflow

10. Developer Experience (DX) Comparison

11. Scalability for Large Applications

12. Real-World Folder Structure Example

13. Which Approach Do Companies and Teams Actually Prefer?

14. When NOT to Use Expo Router

15. Situations Where React Navigation Still Makes More Sense

Architecture Comparison at a Glance

The Verdict for 2026

How WhatsApp Works Without Internet: Offline Messaging and Sync Explained

The Scenario: Sending a Message in Airplane Mode

Local Storage and Message Persistence

The Message Queue

Syncing When Connectivity Returns

Delivery States: Sent, Delivered, Read

Handling Media While Offline

Conflict Resolution and Message Ordering

Why Offline-First Matters

The Full Lifecycle in One Diagram

The Role of `next()`

Meet `dig` — Your DNS Diagnostic Tool

Layer 1: Root Name Servers — `dig . NS`

Layer 2: TLD Name Servers — `dig com NS`

Layer 3: Authoritative Name Servers — `dig google.com NS`

The Full Resolution — `dig google.com`

Mapping `dig` Commands to DNS Stages

String Interpolation: `${}` Is Your New Best Friend