DEV Community: Janmejai Singh

Callbacks in JavaScript: Why They Exist

Janmejai Singh — Wed, 29 Jul 2026 17:31:31 +0000

Callbacks in JavaScript: Why They Exist

JavaScript treats functions like values. You can store them, pass them to another function, and call them later. That flexibility is the reason callbacks exist.

This article moves from simple function arguments to asynchronous programming and callback nesting.

Functions are values

function sayHello() {
  console.log("Hello!");
}

const greet = sayHello;
greet(); // Hello!

sayHello is the function itself. sayHello() runs it.

What is a callback?

A callback is a function passed into another function so that it can be run later.

function welcome(name, afterWelcome) {
  console.log(`Welcome, ${name}!`);
  afterWelcome();
}

function showMenu() {
  console.log("Here is today's menu.");
}

welcome("Vasu", showMenu);

flowchart LR
  A[Call welcome] --> B[Print greeting]
  B --> C[Run callback]
  C --> D[Show menu]

We pass showMenu, not showMenu(), because welcome decides when to call it.

Why callbacks are useful

Callbacks make code reusable. One function can provide data while another function decides what to do with it.

function processNumber(number, action) {
  return action(number);
}

console.log(processNumber(5, (value) => value * 2)); // 10
console.log(processNumber(5, (value) => value * value)); // 25

Common callback scenarios

Arrays

const prices = [100, 250, 80];

const discounted = prices.map((price) => price * 0.9);
const expensive = prices.filter((price) => price > 100);

map and filter call your callback for each array item.

Click events

button.addEventListener("click", () => {
  console.log("Button clicked");
});

The browser runs this callback only when a user clicks.

Timers

console.log("Order received");

setTimeout(() => {
  console.log("Food is ready");
}, 2000);

console.log("Preparing payment");

The timeout callback runs later, so JavaScript can continue with other work first.

Callbacks and asynchronous JavaScript

Slow tasks—network calls, timers, files, database work—should not freeze the app. JavaScript starts the task, keeps running other code, and executes a callback when the task finishes.

flowchart LR
  A[Start async task] --> B[Continue other work]
  B --> C[Task completes]
  C --> D[Callback runs]

Here is a classic Node.js-style callback:

readFile("notes.txt", "utf8", (error, content) => {
  if (error) {
    console.error(error);
    return;
  }

  console.log(content);
});

Many Node.js APIs use the “error-first” callback pattern: check the error first, then use the result.

The drawback: callback nesting

When several asynchronous steps depend on each other, callbacks can become deeply nested:

getUser(userId, (user) => {
  getOrders(user.id, (orders) => {
    getPaymentStatus(orders[0].id, (status) => {
      sendNotification(status, () => {
        console.log("All done");
      });
    });
  });
});

This is known as callback hell. The issue is readability, repeated error handling, and difficulty changing the flow—not that callbacks are inherently bad.

Modern JavaScript often uses Promises and async/await for these sequences:

async function notifyAboutFirstOrder(userId) {
  const user = await getUser(userId);
  const orders = await getOrders(user.id);
  const status = await getPaymentStatus(orders[0].id);
  await sendNotification(status);
}

Final takeaway

Callbacks let JavaScript say: “When this work is done, run this next function.” They power array methods, browser events, timers, and asynchronous APIs.

Learn callbacks first—the ideas behind Promises and async/await become much easier afterward.

Kafka Explained Like You're 5: Events, Partitions, and Consumer Groups

Janmejai Singh — Wed, 29 Jul 2026 17:27:39 +0000

Kafka Explained Like You're 5: Events, Partitions, and Consumer Groups

How does a large application process millions of events every day?

Picture a food-delivery app at dinner time. Customers place orders, restaurants accept them, riders get assigned, payments go through, users get alerts, and analytics teams measure everything—at the same time.

If each service had to call every other service directly, the app would become slow, fragile, and hard to grow. Apache Kafka gives every service a shared, reliable way to announce what happened and let the right systems react.

This guide explains Kafka through four ideas: events → topics → partitions → consumer groups.

Why systems need event streaming

Small apps often use request-response calls:

Checkout service → Payment service → Notification service

As the product grows, checkout may also need inventory, delivery assignment, fraud checks, analytics, email, SMS, and recommendations. Now it depends on all of them. That is tight coupling.

With event streaming, checkout only announces a fact: “An order was created.” Every interested service can react independently.

flowchart LR
  A[Checkout] -->|Order created| K[Kafka]
  K --> P[Payment]
  K --> N[Notifications]
  K --> I[Inventory]
  K --> X[Analytics]

What is Kafka?

Apache Kafka is a distributed event-streaming platform. Think of it as a durable shared diary where applications write events and other applications read them.

Unlike a basic queue, Kafka retains events for a configured period. Several applications can read the same event stream, and an application can replay older events when needed.

Common uses include analytics pipelines, payment events, notifications, activity tracking, fraud detection, and communication between microservices.

Events: the smallest Kafka unit

An event is a record that says something happened.

{
  "eventType": "OrderCreated",
  "orderId": "ORD-1042",
  "customerId": "CUS-79",
  "createdAt": "2026-07-29T17:30:00Z"
}

A producer sends an event.
Kafka stores it.
A consumer reads and processes it.

For an order, the flow might be: a user places an order → the Order service produces OrderCreated → Kafka stores it → payment, inventory, notifications, and analytics consume it independently.

Topics: organized streams

A topic is a named stream of related events—like a labelled shelf in the event diary.

Topic	Example events
`orders`	created, cancelled, delivered
`payments`	initiated, completed, failed
`user-activity`	login, click, search
`notifications`	email, SMS, push requests

Multiple producers may write to one topic, and multiple consumers may read from it.

Partitions: how Kafka scales

One busy topic is split into partitions. Each partition is an ordered, append-only log.

flowchart TB
  P[Producer] --> T[orders topic]
  T --> A[Partition 0]
  T --> B[Partition 1]
  T --> C[Partition 2]

Partitions enable parallel processing and let Kafka spread work across brokers. Kafka guarantees order inside one partition, not across every partition in a topic.

Use a key such as orderId when related events must stay ordered. Events with the same key go to the same partition, preserving sequences like:

OrderCreated → PaymentCompleted → RiderAssigned → OrderDelivered

Why Kafka is fast

Kafka is designed for high throughput:

New events are written sequentially.
Partitions are append-only logs.
Sequential disk work is efficient.
Kafka batches reads and writes to reduce overhead.

This is why Kafka can handle large, continuous streams without treating every event like a slow, isolated database operation.

Consumer groups: teamwork without duplicate work

A consumer group is a team of consumers reading the same topic. In one group, each partition is assigned to only one consumer at a time.

flowchart LR
  P0[Partition 0] --> C1[Consumer 1]
  P1[Partition 1] --> C2[Consumer 2]
  P2[Partition 2] --> C3[Consumer 3]

This means a Billing service can run several instances without processing each order repeatedly. A separate Analytics consumer group can still read every order independently.

If a consumer fails, Kafka reassigns its partitions to healthy consumers. This is called rebalancing. Consumer groups track their reading position using offsets, so they can continue from the correct point.

More consumers than partitions do not increase active parallelism. A topic with three partitions can have at most three active consumers in one group.

Kafka architecture

Component	Purpose
Producer	Publishes events
Broker	Kafka server that stores data
Topic	Named event stream
Partition	Ordered, scalable slice of a topic
Consumer	Reads events
Consumer group	Shares partitions across consumers

flowchart LR
  PR[Producers] --> B[Kafka brokers]
  B --> TP[Topic partitions]
  TP --> CG[Consumer groups]
  CG --> CO[Consumers]

Kafka vs traditional queues

Capability	Traditional queue	Kafka
Main model	Give a job to a worker	Store a stream of facts
After reading	Often removed	Retained for a period
Replay	Usually limited	Built in with offsets
Multiple apps reading	Needs extra routing	Each group reads independently
Scaling	Add workers	Add partitions and consumers

Kafka can behave like a queue inside one consumer group, while still allowing other groups to consume the same retained data.

Real-world Kafka applications

E-commerce: order, inventory, shipment, and payment events.
Analytics: clicks, searches, and product views flowing into dashboards.
Notifications: emails and push messages triggered by business events.
Payments: reconciliation and fraud checks after payment events.
Recommendations: likes, views, and purchases becoming model signals.
Social platforms: posts, comments, follows, and feed activity.

For example, a PaymentCompleted event can trigger warehouse packing, a customer notification, revenue analytics, and a loyalty-points update—without the Payment service calling each system directly.

The five-year-old summary

Imagine a school notice board:

An event is a new notice: “Lunch is ready!”
A topic is the “Cafeteria” part of the board.
Partitions are several columns so many notices can be handled quickly.
A consumer group is a team of helpers, where each helper reads a different column.
Different teams can read the same notices for their own jobs.

Final takeaway

Kafka is a foundation for reliable, scalable event-driven systems:

Events describe what happened. Topics organize them. Partitions scale them. Consumer groups distribute the work.

What would you build with Kafka first—an order pipeline, notifications, analytics, or user activity tracking?

URL Parameters vs Query Strings in Express.js (With Real Examples)

Janmejai Singh — Wed, 29 Jul 2026 17:19:45 +0000

URL Parameters vs Query Strings in Express.js (With Real Examples)

If you've built more than one Express route, you've probably typed req.params and req.query without stopping to ask why one is used here and the other is used there. They both pull data out of a URL, so it's easy to treat them as interchangeable — until your API design falls apart because a "filter" is hard-coded into the route path, or a required resource ID is quietly optional.

This guide breaks down URL parameters and query strings from first principles, shows you exactly how to read them in Express, and gives you a simple rule for deciding which one to reach for.

The URL, Broken Down

Before comparing the two, look at where each one actually lives in a URL:

https://api.example.com/users/42/posts?sort=latest&limit=10
                         └──┬──┘             └───────┬───────┘
                    URL Parameter              Query String
                    (:id → "42")          (sort=latest&limit=10)

Everything before the ? is the path — and any dynamic piece of that path is a URL parameter (also called a route parameter).
Everything after the ? is the query string — a set of key-value pairs separated by &.

They sit in different parts of the URL because they serve different purposes.

What Are URL Parameters?

URL parameters (route parameters) are dynamic segments of the path itself. They identify a specific, named resource. In Express, you declare them in your route definition with a colon:

app.get('/users/:id', (req, res) => {
  res.send(`Fetching user with ID: ${req.params.id}`);
});

A request to /users/42 matches this route, and Express extracts 42 as req.params.id. Without that segment, the route doesn't match at all — there's no such thing as an "optional" URL parameter unless you explicitly design one.

Think of URL parameters as identifiers. They answer the question: which specific thing am I asking for?

/users/42 → the user whose ID is 42
/products/laptop-x200 → the product with that slug
/orders/9981/items/3 → item 3, inside order 9981

What Are Query Parameters?

Query parameters (the query string) come after the ? and are made up of key-value pairs. They don't identify a resource — they modify or filter the request you're already making.

app.get('/products', (req, res) => {
  const { category, sort, page } = req.query;
  res.send(`Category: ${category}, Sort: ${sort}, Page: ${page}`);
});

A request to /products?category=shoes&sort=price&page=2 gives you:

req.query
// { category: 'shoes', sort: 'price', page: '2' }

Think of query parameters as filters or modifiers. They answer the question: how do I want this data shaped, sorted, or narrowed down?

/products?category=shoes → filter products by category
/articles?sort=newest&limit=5 → sort and limit results
/search?q=express+js&page=2 → a search term plus pagination

The Core Difference

	URL Parameter	Query String
Location	Part of the path	After the `?`
Purpose	Identifies a specific resource	Filters, sorts, or modifies a request
Required?	Usually yes — the route won't match without it	Usually optional
Express access	`req.params`	`req.query`
Example	`/users/42`	`/users?role=admin&active=true`
Analogy	"Which record?"	"How do you want it?"

The distinction isn't just cosmetic. If something is essential to identifying what you're fetching, it belongs in the path as a parameter. If it's optional, or there could be several combined at once, it belongs in the query string.

Accessing Route Parameters in Express

Express makes this straightforward with req.params. You can define multiple parameters in a single route:

app.get('/users/:userId/posts/:postId', (req, res) => {
  const { userId, postId } = req.params;
  res.send(`User ${userId}, Post ${postId}`);
});

A request to /users/7/posts/103 gives you:

req.params
// { userId: '7', postId: '103' }

Note: all values in req.params are strings. If you're expecting a number, convert it explicitly:

const userId = parseInt(req.params.userId, 10);

Accessing Query Strings in Express

Query parameters are available on req.query, which Express parses automatically from the URL — no extra middleware required:

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

A request to /search?q=nodejs&page=2 returns:

{ "searchTerm": "nodejs", "page": 2, "limit": 10 }

Notice the default values for page and limit — this is standard practice, since query parameters are optional by nature. You should always assume a query parameter might not be there and handle that case gracefully.

When to Use Params vs Query

Here's the mental shortcut that removes the guesswork:

Use a URL parameter when the value identifies a specific resource, and the route is meaningless without it.

GET /users/:id          → one specific user
GET /orders/:orderId    → one specific order

Use a query string when the value filters, sorts, paginates, or optionally modifies a collection of results.

GET /users?role=admin&status=active
GET /orders?sortBy=date&limit=20

A useful test: if you removed this value, would the endpoint still make sense? If removing it breaks the entire meaning of the request (no user ID means no user to fetch), it's a parameter. If removing it just gives you the default, unfiltered view, it's a query string.

You'll often combine both in the same route:

app.get('/users/:id/orders', (req, res) => {
  const { id } = req.params;              // which user
  const { status, sort } = req.query;      // how to filter/sort their orders
  res.send(`Orders for user ${id}, filtered by ${status}, sorted by ${sort}`);
});

GET /users/42/orders?status=shipped&sort=newest — the user is identified by a parameter, while the filtering is handled entirely through the query string. This is exactly how well-designed REST APIs are structured.

Wrapping Up

URL parameters and query strings both extract data from a URL, but they're not interchangeable:

URL parameters (req.params) identify what resource you're working with. They live in the path and are usually required.
Query strings (req.query) describe how you want that resource — filtered, sorted, paginated. They live after the ? and are usually optional.

Once you internalize "params identify, query modifies," designing clean, predictable Express routes becomes second nature — and your API consumers will thank you for it.

Found this useful? Follow for more practical Node.js and Express.js breakdowns.

Getting Started with cURL: How to Talk to a Server From Your Terminal

Janmejai Singh — Wed, 29 Jul 2026 17:14:50 +0000

Getting Started with cURL: How to Talk to a Server From Your Terminal

If you've ever opened your browser's Network tab, seen a wall of requests flying back and forth, and wondered "how do people do this stuff without a browser?" — this article is for you.

By the end of this post, you'll understand what cURL is, why almost every backend developer keeps it open in a terminal tab, and you'll have made your very first request. No jargon-heavy detours, no 40-flag cheat sheets. Just the basics, explained the way they should have been explained to you the first time.

First, What Is a Server — and Why Do We Even Need to Talk to It?

Imagine a restaurant. You (the customer) don't walk into the kitchen and cook your own food. Instead, you tell a waiter what you want, the waiter carries that request to the kitchen, the kitchen prepares it, and the waiter brings the result back to your table.

A server is the kitchen. It's a computer somewhere (maybe down the hall, maybe on the other side of the planet) that stores data, runs logic, and hands back results when someone asks nicely.

Every time you open a website, check a weather app, or log into an account, your device is sending a request to a server and waiting for a response. Your browser has been playing waiter for you this whole time — quietly making these requests and rendering the results as a webpage so you never had to think about the conversation happening underneath.

cURL lets you become the waiter yourself.

What Is cURL, in Very Simple Terms

cURL (pronounced "curl", short for Client URL) is a command-line tool that lets you send requests to a server directly from your terminal, without needing a browser at all.

Think of it as a way to type out a message, address it to a server, hit send, and read the reply — all in plain text, right where you're already writing code.

curl https://example.com

That one line does exactly what your browser does when you type a URL into the address bar and hit Enter — except instead of rendering a pretty page, cURL just shows you the raw response.

Why Programmers Need cURL

You might be thinking: "I already have a browser. Why do I need this?"

Here's why cURL earns a permanent spot in every backend developer's toolkit:

Testing APIs without building a UI first. You can check if your backend endpoint works before a single line of frontend code exists.
Debugging in the exact environment your app runs in. Servers, CI pipelines, and Docker containers usually don't have browsers — but they almost always have cURL.
Precise control. You decide exactly what headers, data, and method get sent — nothing extra, nothing hidden.
Speed. No clicking through UI panels. Just one line in the terminal and you have your answer.
It's everywhere. cURL ships with most operating systems and is often the first tool used to verify "is my server even reachable?"

In short: cURL is how developers have a direct, no-nonsense conversation with a server.

The Big Picture: cURL → Server → Response

 ┌────────────┐        request         ┌────────────┐
 │            │ ─────────────────────► │            │
 │   cURL     │                        │   Server   │
 │ (terminal) │ ◄───────────────────── │            │
 └────────────┘        response        └────────────┘

That's really the whole story. You send something, the server processes it, and it sends something back. Everything else in this post is just filling in the details of that arrow.

Making Your First Request Using cURL

Let's keep this as simple as physically possible. Open your terminal (cURL comes pre-installed on macOS and most Linux distributions; on Windows 10+, it's built into PowerShell/CMD too) and type:

curl https://api.github.com

Hit Enter. You'll see a block of text scroll by — that's the server's response, written in a format called JSON. You just made your first request without touching a browser.

Want to see a normal webpage instead of JSON? Try:

curl https://example.com

You'll see raw HTML — the same HTML your browser would normally turn into a nicely styled page for you.

Understanding Request and Response

Every time you use cURL (or a browser, or an app), you're really sending a package with a few key parts, and getting a package back with a few key parts.

A request typically has:

A URL — where you're sending it (https://api.github.com/users/octocat)
A method — what kind of action you want (more on this below)
Headers — extra information about the request, like what format you want the response in
A body (sometimes) — data you're sending along, like a new user's name and email

A response typically has:

A status code — a short number telling you what happened (200 means success, 404 means "not found", 500 means the server had a problem)
Headers — metadata about the response
A body — the actual data or content you asked for

REQUEST                          RESPONSE
--------                         --------
Method:  GET                     Status:  200 OK
URL:     /users/octocat          Headers: Content-Type: application/json
Headers: Accept: application/json
Body:    (none for GET)          Body:    { "login": "octocat", ... }

You can see the status code and headers directly with cURL using the -i flag:

curl -i https://api.github.com

This is the single most useful habit to build early: whenever something goes wrong, check the status code first. It tells you, in one number, roughly whose fault it is — yours, or the server's.

Browser Request vs cURL Request (Conceptually)

A browser and cURL are doing the same fundamental thing — sending a request and receiving a response — they just differ in what happens to that response afterward.

        You type a URL
               │
               ▼
      ┌──────────────────┐
      │   Browser         │──► sends request ──► Server
      │  (renders result  │◄── gets response ───
      │   as a webpage)   │
      └──────────────────┘

      ┌──────────────────┐
      │   cURL             │──► sends request ──► Server
      │ (prints raw result │◄── gets response ───
      │   to terminal)     │
      └──────────────────┘

A browser takes the response and paints it as buttons, images, and text. cURL takes the same response and just prints it, raw, exactly as the server sent it. That's the whole difference — and it's precisely why cURL is so useful for developers: you see the real data, with nothing hidden behind styling.

Using cURL to Talk to APIs

Most real-world use of cURL isn't fetching webpages — it's talking to APIs (Application Programming Interfaces), which are servers designed specifically to exchange data, not pretty pages.

To keep things beginner-friendly, let's focus on just the two methods you'll use 90% of the time starting out:

GET — "Give me some data"

GET is for reading information. It's the default method cURL uses if you don't specify one.

curl https://api.github.com/users/octocat

This asks the GitHub API for public information about the user octocat and returns it as JSON.

POST — "Here's some data, please save it"

POST is for sending information — creating something new, submitting a form, logging in, and so on.

curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"name": "Ada", "role": "Developer"}'

Let's break that down:

-X POST tells cURL which method to use
-H "Content-Type: application/json" tells the server "the data I'm sending is JSON"
-d '...' is the actual data (the request body) you're sending

That's genuinely 90% of what you need to start exploring APIs confidently. GET to read, POST to send — everything else can wait until you actually need it.

Where cURL Fits in Backend Development

 Frontend            cURL (you, testing)         Backend API           Database
 ┌────────┐          ┌────────────────┐          ┌───────────┐        ┌──────────┐
 │  App /  │          │  Terminal       │          │  Server   │        │  Data     │
 │  Browser│          │  request/       │ ───────► │  (routes, │ ─────► │  storage  │
 │         │          │  response check │ ◄─────── │  logic)   │ ◄───── │           │
 └────────┘          └────────────────┘          └───────────┘        └──────────┘

Before your frontend ever touches an API, developers usually verify it with cURL first — is the endpoint live, does it accept the right data, does it return what's expected. It becomes your first line of defense against bugs, long before a UI is involved.

Common Mistakes Beginners Make With cURL

A few small stumbles trip up almost everyone early on — here's how to skip them:

Forgetting quotes around JSON data. Your shell can misinterpret special characters like {, }, and " if they aren't wrapped properly. Always wrap your -d payload in single quotes.
Sending JSON without the Content-Type header. If you send a JSON body but forget -H "Content-Type: application/json", many servers won't parse it correctly — and you'll get a confusing error that has nothing to do with your actual data.
Assuming GET when you meant POST (or vice versa). cURL defaults to GET. If you're trying to create or send data, you must explicitly add -X POST.
Ignoring the status code. A response with no visible error doesn't mean it worked. Always check the status with -i — a 404 or 500 buried in a big response body is easy to miss otherwise.
Not realizing HTTPS vs HTTP matters. Some servers reject plain http:// and expect https://. If your request silently fails, double-check the protocol.
Testing against the wrong environment. It's easy to accidentally hit a production API when you meant to test locally (localhost:3000). Always double-check your URL before running commands that send or modify data.

Wrapping Up

cURL isn't complicated — it just looks unfamiliar the first time you see it. At its core, it's nothing more than a way to send a message to a server and read what comes back, the exact same conversation your browser has been having on your behalf all along.

Start with plain GET requests. Get comfortable reading status codes. Then move on to POST. Everything else — headers, authentication tokens, file uploads — builds naturally on this same request-and-response foundation.

The next time someone says "just cURL the endpoint," you'll know exactly what they mean — and exactly how to do it.

Found this helpful? Try running a few of these commands yourself right now — the best way to get comfortable with cURL is to break something with it and figure out why.

Where RAG Fails: Understanding the Limitations of Retrieval-Augmented Generation

Janmejai Singh — Sun, 19 Jul 2026 10:07:34 +0000

Where RAG Fails: Understanding the Limitations of Retrieval-Augmented Generation

If you've built anything with large language models in the last two years, you've almost certainly run into RAG — Retrieval-Augmented Generation. It's become the default answer to "how do I make my LLM know about my data?"

But here's the part that doesn't get talked about enough: RAG fails a lot more often than the tutorials suggest. Not because it's a bad idea, but because most teams treat it like a plug-and-play feature instead of a system with real engineering trade-offs.

This article walks through what RAG actually is, why it exists, how it works under the hood, and — most importantly — where and why it breaks down in practice.

The Problem RAG Was Built to Solve

Large language models are trained on a fixed snapshot of data. Once training ends, the model's knowledge is frozen. This creates two very real problems:

Staleness — the model has no idea about anything that happened after its training cutoff, and no idea about your company's internal documents, product specs, or support tickets.
Hallucination under uncertainty — when an LLM doesn't know something, it doesn't reliably say "I don't know." It often generates a fluent, confident-sounding answer that's simply wrong.

Imagine asking a brilliant new employee a question about your company's refund policy on their very first day, with no access to the employee handbook. They might guess intelligently based on general business knowledge — but they'd likely get specifics wrong. That's an LLM without external knowledge.

You could try to fix this by cramming your entire knowledge base into the prompt every time. But that's expensive, slow, and quickly runs into a hard wall: the model's context window — the maximum amount of text it can consider at once. This is exactly the gap RAG was designed to close.

What Is RAG, Really?

Retrieval-Augmented Generation (RAG) is a technique that gives an LLM access to relevant external information before it generates an answer — instead of relying purely on what it memorized during training.

Rather than asking the model to answer from memory, you:

Search a knowledge base for information relevant to the user's question.
Insert that information into the prompt as context.
Ask the LLM to answer using that context.

Think of it like an open-book exam instead of a closed-book one. The model isn't smarter — it just has the right page open in front of it.

How a Basic RAG Pipeline Works

A simple RAG system has four moving parts: the user's question, a retrieval step, the LLM, and the final response.

┌─────────────┐      ┌───────────────┐      ┌─────────────┐      ┌──────────────┐
│  User Query │ ───▶ │   Retrieval    │ ───▶ │     LLM     │ ───▶ │   Response   │
│ "What's our │      │ (search a      │      │ (reads query │      │ (grounded,   │
│  refund     │      │  vector DB /   │      │  + retrieved │      │  hopefully   │
│  policy?"   │      │  document      │      │  chunks)     │      │  accurate)   │
│             │      │  store)        │      │              │      │              │
└─────────────┘      └───────────────┘      └─────────────┘      └──────────────┘

Behind the "Retrieval" box, a few things usually happen:

Your documents are split into smaller pieces, called chunks.
Each chunk is converted into a numeric representation, called an embedding, that captures its meaning.
These embeddings are stored in a vector database.
When a query comes in, it's also converted into an embedding, and the system finds the chunks whose embeddings are most similar — i.e., most semantically relevant.

Those top-matching chunks are inserted into the prompt, and the LLM generates its answer using that grounded context instead of guessing from memory.

Where RAG Works Really Well

Before we get into the failure modes, it's worth being clear about where RAG genuinely shines:

Customer support bots answering from a product's help docs.
Internal knowledge assistants searching company wikis, Slack exports, or Notion pages.
Legal or research assistants pulling relevant clauses or papers before summarizing.
Code assistants referencing a specific codebase or internal API documentation.

In all these cases, the answer exists somewhere in a document, the documents are reasonably well-structured, and the question maps fairly directly to a chunk of text. This is RAG's sweet spot.

The trouble starts when any of those assumptions break down — which, in the real world, happens constantly.

Why RAG Sometimes Gives Incorrect Answers

RAG improves the odds of a correct answer. It does not guarantee one. Every step in the pipeline — retrieval, chunking, context assembly, and generation — is a place where things can quietly go wrong, and the failure is often invisible until a user catches it.

Let's go through the biggest culprits.

1. Poor Retrieval and Missing Context

The entire system depends on one assumption: that the retrieval step finds the right information. If it doesn't, everything downstream is built on sand.

Good Retrieval                          Poor Retrieval
───────────────                         ───────────────
Query: "cancellation fee                Query: "cancellation fee
for annual plans"                       for annual plans"

Retrieved chunks:                       Retrieved chunks:
✅ "Annual plan cancellation             ❌ "Monthly plan billing cycle"
    incurs a 10% fee..."                ❌ "How to cancel a free trial"
✅ "Fees are prorated based             ❌ "General refund process
    on remaining months..."                 overview"

Result: Accurate, specific              Result: LLM answers using
answer grounded in the                  loosely related or generic
right policy.                           info — or guesses to fill
                                         the gap.

Retrieval can fail for mundane reasons: the user's phrasing doesn't semantically match the document's wording, the embedding model isn't great at your domain (legal, medical, code), the knowledge base has duplicate or conflicting documents, or the top-k results simply don't contain the answer at all. When that happens, the LLM is left generating a response from incomplete or irrelevant context — and it usually won't tell you that's what happened.

2. Poor Chunking and Its Impact on Responses

How you split documents matters more than most people expect. Chunk too small, and you lose surrounding context. Chunk too large, and you dilute relevance and waste context window space.

Original paragraph:
"Refunds are available within 30 days of purchase.
However, annual subscribers are only eligible for a
prorated refund, and enterprise customers must contact
their account manager directly."

Bad chunking (cuts mid-thought):
Chunk A: "Refunds are available within 30 days of purchase.
          However, annual subscribers are only eligible"
Chunk B: "for a prorated refund, and enterprise customers
          must contact their account manager directly."

Good chunking (preserves complete ideas):
Chunk A: "Refunds are available within 30 days of purchase."
Chunk B: "Annual subscribers are only eligible for a
          prorated refund."
Chunk C: "Enterprise customers must contact their account
          manager directly for refunds."

In the "bad chunking" example, a query about annual refunds might retrieve only Chunk A or only Chunk B — each missing half the relevant sentence. The model then has to guess at the missing piece, and it often guesses wrong, confidently.

3. Context Window Limitations

Even with perfect retrieval, there's a ceiling on how much information you can hand the model at once.

Context Window (fixed size)
┌────────────────────────────────────────────────┐
│  System prompt                                  │
│  ────────────────────────                       │
│  Retrieved chunk 1                               │
│  Retrieved chunk 2                               │
│  Retrieved chunk 3                               │
│  ...                                             │
│  Retrieved chunk N   ◄── may get cut off or      │
│                          crowd out other chunks  │
│  ────────────────────────                        │
│  User question                                   │
└────────────────────────────────────────────────┘
        ▲
        └── Fixed capacity. More chunks ≠ better,
            past a certain point — relevant info
            can get buried or squeezed out entirely.

Stuffing in more chunks "just in case" doesn't reliably help. Models can lose track of information buried in the middle of a long context (a well-documented effect sometimes called "lost in the middle"), and irrelevant chunks can actively distract the model from the ones that matter. More context isn't automatically better context.

4. Hallucinations Even With RAG

This surprises a lot of people: RAG reduces hallucination, but it doesn't eliminate it. The LLM can still:

Blend retrieved information with its own pretrained assumptions.
Fill gaps between two retrieved chunks with a plausible-sounding but invented connection.
Misread the retrieved context and state something the source doesn't actually say.
Answer confidently even when the retrieved chunks don't actually contain the answer.

Giving the model the right book doesn't guarantee it reads the right page carefully. Grounding lowers the risk of hallucination — it doesn't remove it.

5. Keeping the Knowledge Base Up to Date

RAG is only as good as the data it retrieves from. If your knowledge base isn't maintained, you get confidently wrong answers instead of vague ones:

Outdated documents get retrieved and treated as current fact.
Deleted or superseded policies still sit in the vector store unless explicitly removed.
New information isn't available until someone re-runs the ingestion pipeline.
Conflicting versions of the same document can cause the retriever to pull contradictory chunks for the same query.

Unlike a static LLM, a RAG system needs ongoing operational care — re-indexing, deduplication, versioning — or its accuracy quietly decays over time.

When RAG Is Not the Right Solution

RAG is a fantastic tool, but it's not universal. It tends to struggle when:

The answer requires reasoning across many documents at once, not just retrieving a few relevant snippets (e.g., "summarize trends across our last 12 months of tickets").
The knowledge base is small enough to just fit in the context window — in that case, RAG adds complexity without much benefit.
The task is computational or logical rather than knowledge-based — RAG won't help an LLM do arithmetic or multi-step planning correctly.
Precision requirements are extremely high, such as medical or legal advice, where a single retrieval miss can be genuinely harmful — these cases usually need stricter verification layers on top of RAG, not RAG alone.
Data changes faster than your ingestion pipeline can keep up with, making "up-to-date" retrieval unreliable by design.

In these situations, alternatives like fine-tuning, structured tool calls to live systems (databases, APIs), or hybrid approaches combining RAG with reasoning agents often serve better than RAG on its own.

Wrapping Up

RAG solves a real and important problem: it gives LLMs access to knowledge beyond their training data, grounded in your actual documents. Used well, it's the difference between a chatbot that guesses and one that can point to a source.

But RAG is a pipeline of independent, fallible steps — retrieval, chunking, context assembly, and generation — and a weak link anywhere in that chain produces a wrong answer that still sounds right. Understanding where it breaks — poor retrieval, bad chunking, context window limits, residual hallucination, and stale knowledge bases — is what separates a RAG system that's genuinely trustworthy from one that just looks impressive in a demo.

The goal isn't to avoid RAG. It's to know exactly what you're trusting it to do, and to design around its limits rather than being surprised by them.

If you're building RAG systems in JavaScript or exploring GenAI tooling, I'd love to hear what failure modes you've run into — drop a comment below.

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!

DEV Community: Janmejai Singh

Callbacks in JavaScript: Why They Exist

Callbacks in JavaScript: Why They Exist

Functions are values

What is a callback?

Why callbacks are useful

Common callback scenarios

Arrays

Click events

Timers

Callbacks and asynchronous JavaScript

The drawback: callback nesting

Final takeaway

Kafka Explained Like You're 5: Events, Partitions, and Consumer Groups

Kafka Explained Like You're 5: Events, Partitions, and Consumer Groups

Why systems need event streaming

What is Kafka?

Events: the smallest Kafka unit

Topics: organized streams

Partitions: how Kafka scales

Why Kafka is fast

Consumer groups: teamwork without duplicate work

Kafka architecture

Kafka vs traditional queues

Real-world Kafka applications

The five-year-old summary

Final takeaway

URL Parameters vs Query Strings in Express.js (With Real Examples)

URL Parameters vs Query Strings in Express.js (With Real Examples)

The URL, Broken Down

What Are URL Parameters?

What Are Query Parameters?

The Core Difference

Accessing Route Parameters in Express

Accessing Query Strings in Express

When to Use Params vs Query

Wrapping Up

Getting Started with cURL: How to Talk to a Server From Your Terminal

Getting Started with cURL: How to Talk to a Server From Your Terminal

First, What Is a Server — and Why Do We Even Need to Talk to It?

What Is cURL, in Very Simple Terms

Why Programmers Need cURL

The Big Picture: cURL → Server → Response

Making Your First Request Using cURL

Understanding Request and Response

Browser Request vs cURL Request (Conceptually)

Using cURL to Talk to APIs

GET — "Give me some data"

POST — "Here's some data, please save it"

Where cURL Fits in Backend Development

Common Mistakes Beginners Make With cURL

Wrapping Up

Where RAG Fails: Understanding the Limitations of Retrieval-Augmented Generation

Where RAG Fails: Understanding the Limitations of Retrieval-Augmented Generation

The Problem RAG Was Built to Solve

What Is RAG, Really?

How a Basic RAG Pipeline Works

Where RAG Works Really Well

Why RAG Sometimes Gives Incorrect Answers

1. Poor Retrieval and Missing Context

2. Poor Chunking and Its Impact on Responses

3. Context Window Limitations

4. Hallucinations Even With RAG

5. Keeping the Knowledge Base Up to Date

When RAG Is Not the Right Solution

Wrapping Up

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

The Role of `next()`