DEV Community: Aryan Gupta

How MongoDB Finds Your Data

Aryan Gupta — Mon, 05 Oct 2026 05:32:31 +0000

In the previous part of Under the Hood, we explored how Express middleware processes an incoming request before it reaches the route handler.

We ended with an important question:

When our application asks MongoDB for a user, how does MongoDB actually find that data?

You may have written code like this:

const user = await User.findOne({
    email: "aryan@example.com"
});

It looks simple.

We give MongoDB an email and it gives us a user.

But imagine a collection containing:

10 documents
100 documents
10,000 documents
1,000,000 documents
100,000,000 documents

Does MongoDB check every document one by one?

If it did, database queries would become extremely slow as our application grew.

So what actually happens?

How does MongoDB decide what to search?

What is an index?

Why is an indexed query usually faster?

And how can we check whether MongoDB actually used an index?

Let's go Under the Hood.

1. Where MongoDB Fits in Our Application

Before looking inside MongoDB, let's connect it with what we learned in the previous parts.

Suppose a client sends:

GET /users/123

The request travels through our application:

Client
  ↓
HTTP Request
  ↓
Node.js
  ↓
Express
  ↓
Middleware
  ↓
Route Handler
  ↓
MongoDB
  ↓
Query Result
  ↓
Route Handler
  ↓
HTTP Response
  ↓
Client

For example:

app.get("/users/:id", async (req, res) => {

    const user = await User.findOne({
        _id: req.params.id
    });

    res.json(user);
});

The Express route receives the request.

Then our application asks the database for a document.

But there is an important detail.

Our Node.js application does not directly manipulate MongoDB's internal data structures.

It communicates with MongoDB through a MongoDB driver.

For Node.js applications, MongoDB provides an official Node.js driver for connecting to MongoDB and performing database operations.

If we use Mongoose, Mongoose sits between our application and the MongoDB driver.

Conceptually:

Express Route
      ↓
Mongoose
      ↓
MongoDB Node.js Driver
      ↓
MongoDB Server

So when we write:

User.findOne(...)

there is much more happening underneath.

2. What Is a MongoDB Document?

MongoDB is a document database.

Instead of storing data primarily as rows and columns, MongoDB stores data as documents inside collections.

A document looks similar to JSON:

{
    _id: ObjectId("..."),
    name: "Aryan",
    email: "aryan@example.com",
    age: 21
}

MongoDB actually stores documents as BSON, which is a binary representation of JSON with additional data types.

A collection can contain many documents:

users
 ├── Document 1
 ├── Document 2
 ├── Document 3
 ├── Document 4
 └── ...

For example:

{
    _id: 1,
    name: "Aryan",
    email: "aryan@example.com"
}

and:

{
    _id: 2,
    name: "Rahul",
    email: "rahul@example.com"
}

MongoDB can then query these documents using its Query API.

3. What Happens When We Run `findOne()`?

Consider:

const user = await User.findOne({
    email: "aryan@example.com"
});

At a high level, the process looks like this:

Application
    ↓
Mongoose
    ↓
MongoDB Driver
    ↓
MongoDB Server
    ↓
Query
    ↓
Query Planner
    ↓
Index or Collection Scan
    ↓
Matching Document
    ↓
Result
    ↓
Application

The interesting part is:

Query
  ↓
Query Planner
  ↓
How should MongoDB find this data?

MongoDB doesn't simply receive the query and blindly scan everything.

The server interprets the query and builds a query plan describing how it should retrieve the data.

4. What Is a Query?

A query tells MongoDB what data we want.

For example:

{
    email: "aryan@example.com"
}

means:

Find documents where the email field equals "aryan@example.com".

In MongoDB:

db.users.find({
    email: "aryan@example.com"
});

Or if we only want one document:

db.users.findOne({
    email: "aryan@example.com"
});

We can also query using conditions.

For example:

db.users.find({
    age: {
        $gt: 18
    }
});

This means:

Find users whose age is greater than 18.

MongoDB's Query API supports CRUD operations as well as aggregation pipelines for more complex data processing.

But knowing what we want is only half the problem.

MongoDB also needs to figure out:

What is the most efficient way to find it?

That's where the query planner comes in.

5. The Query Planner

Imagine we have one million users.

Our query is:

db.users.findOne({
    email: "aryan@example.com"
});

MongoDB has multiple possible ways to find the document.

For example:

Option 1:
Check every document

Option 2:
Use an index on email

Option 3:
Use another available index

MongoDB's query optimization process determines a suitable plan for executing the query.

Conceptually:

Query
  ↓
Query Planner
  ↓
Choose a Plan
  ↓
Execute Plan
  ↓
Return Results

The plan might involve:

Index
  ↓
Find matching keys
  ↓
Fetch documents

Or it might involve:

Collection
  ↓
Check documents
  ↓
Find matches

The second approach is called a collection scan.

6. What Is a Collection Scan?

Suppose we have these documents:

Document 1 → email: user1@gmail.com
Document 2 → email: user2@gmail.com
Document 3 → email: user3@gmail.com
Document 4 → email: aryan@example.com
Document 5 → email: user5@gmail.com

And we run:

db.users.findOne({
    email: "aryan@example.com"
});

Without a useful index, MongoDB may need to inspect documents to find the matching one.

Conceptually:

Document 1 → ❌
Document 2 → ❌
Document 3 → ❌
Document 4 → ✅

With a large collection, this can require examining many documents.

MongoDB's explain output represents this kind of operation with a COLLSCAN stage.

The problem becomes obvious:

Small collection
    ↓
Not a big problem

Huge collection
    ↓
Potentially expensive

So how can we avoid searching through the entire collection?

7. Enter Indexes

An index is a separate data structure that helps MongoDB locate documents more efficiently.

Think about a book.

Suppose you want to find information about:

MongoDB

You could read every page from beginning to end.

Or you could use the index at the back of the book.

The index might tell you:

MongoDB → Page 142

You can immediately jump closer to the information you need.

Database indexes work with the same basic idea:

Without Index

Collection
   ↓
Document
   ↓
Document
   ↓
Document
   ↓
Document
   ↓
Search...

With an index:

Query
  ↓
Index
  ↓
Find matching key
  ↓
Locate document
  ↓
Return result

MongoDB stores index values separately from the collection so that read operations can use the index to identify relevant documents instead of scanning the entire collection.

8. Creating an Index

Suppose our application frequently searches users by email.

We can create an index:

db.users.createIndex({
    email: 1
});

Here:

email

is the indexed field.

And:

means ascending index order.

We can then run:

db.users.findOne({
    email: "aryan@example.com"
});

MongoDB can use the email index to locate matching documents.

MongoDB recommends creating indexes for fields used frequently in queries, while also considering the cost indexes add to write operations.

9. Why Don't We Index Everything?

If indexes make queries faster, it might seem like we should create an index for every field.

But that isn't a good idea.

Indexes have a cost.

Imagine a document:

{
    name: "Aryan",
    email: "aryan@example.com",
    age: 21,
    city: "Jaipur"
}

If we create indexes on:

name
email
age
city

MongoDB now has more index structures to maintain.

When we insert or update data, the database may also need to update the relevant indexes.

So:

More indexes
     ↓
Potentially faster reads
     +
More work during writes
     +
More storage

MongoDB's documentation specifically notes that indexes improve read performance but add overhead to writes because indexes also need to be updated.

The goal isn't:

Create as many indexes as possible.

The goal is:

Create indexes that support the queries your application actually performs.

10. What Happens When MongoDB Uses an Index?

Let's return to:

db.users.findOne({
    email: "aryan@example.com"
});

Suppose we have:

Users Collection

1,000,000 documents

And:

Index on email

Conceptually, MongoDB can do something like:

                Query
                  ↓
        email = "aryan@example.com"
                  ↓
             Email Index
                  ↓
        Matching index entry
                  ↓
          Corresponding document
                  ↓
               Result

Instead of checking every document:

Document 1
Document 2
Document 3
Document 4
...
Document 1,000,000

the index helps narrow down where MongoDB needs to look.

The exact execution plan can vary depending on the query, available indexes, data distribution, and MongoDB's query optimizer.

That's why we shouldn't assume an index was used just because one exists.

We can check.

11. How Do We Know If MongoDB Used the Index?

MongoDB provides explain() for examining query plans and execution statistics.

For example:

db.users
    .find({
        email: "aryan@example.com"
    })
    .explain("executionStats");

The output contains information about how MongoDB executed the query.

We can inspect things such as:

Execution time
Documents examined
Index keys examined
Indexes used
Query stages

MongoDB's documentation specifically recommends explain("executionStats") for understanding whether a query used an index and how many documents or index keys were examined.

12. `COLLSCAN` vs `IXSCAN`

Two important terms you may see in an explain plan are:

COLLSCAN

and:

IXSCAN

`COLLSCAN`

Means MongoDB performed a collection scan.

Conceptually:

Collection
   ↓
Scan documents
   ↓
Check conditions
   ↓
Return matches

`IXSCAN`

Means MongoDB used an index scan.

Conceptually:

Index
  ↓
Scan relevant index entries
  ↓
Locate matching data
  ↓
Return results

MongoDB's explain documentation uses COLLSCAN for collection scans and IXSCAN when an index is selected by the query planner.

So if you run:

db.users
    .find({
        email: "aryan@example.com"
    })
    .explain("executionStats");

and see:

COLLSCAN

MongoDB performed a collection scan.

If you see:

IXSCAN

an index scan was involved.

13. A Simple Experiment

Let's make this concrete.

Suppose we have:

db.users.insertMany([
    {
        name: "Aryan",
        email: "aryan@example.com"
    },
    {
        name: "Rahul",
        email: "rahul@example.com"
    },
    {
        name: "Priya",
        email: "priya@example.com"
    }
]);

Now query:

db.users.find({
    email: "aryan@example.com"
});

Before creating an email index, we can inspect the query:

db.users
    .find({
        email: "aryan@example.com"
    })
    .explain("executionStats");

We may see a collection scan:

COLLSCAN

Now create an index:

db.users.createIndex({
    email: 1
});

Run the query again:

db.users
    .find({
        email: "aryan@example.com"
    })
    .explain("executionStats");

The plan may now contain:

IXSCAN

The exact explain output depends on the MongoDB version and query, but the important idea is that explain() lets us inspect what MongoDB actually did rather than guessing.

14. `totalDocsExamined` vs `nReturned`

One useful part of executionStats is:

nReturned

and:

totalDocsExamined

Imagine our query returns:

nReturned = 1

but MongoDB examined:

totalDocsExamined = 1,000,000

That tells us something important.

We only needed one document, but MongoDB examined a huge number of documents to find it.

With a suitable index, we might see a much smaller number of documents examined.

MongoDB's explain output exposes these execution statistics specifically so developers can understand how efficiently a query was executed.

15. What Is a Compound Index?

Sometimes we don't query using only one field.

For example:

db.users.find({
    city: "Jaipur",
    age: 21
});

We could create a compound index:

db.users.createIndex({
    city: 1,
    age: 1
});

This index contains multiple fields.

Conceptually:

Compound Index

city
  ↓
age
  ↓
Document location

Compound indexes can support queries involving the indexed fields and their index prefixes. The order of fields in a compound index matters.

For example:

{
    city: 1,
    age: 1
}

can support queries using:

city

or:

city + age

But the index is not equivalent to having an index beginning with age.

This is why index design matters.

16. MongoDB Doesn't Just "Search the Database"

A common mental model is:

Application
     ↓
MongoDB
     ↓
Search database
     ↓
Return result

But a better mental model is:

     Application
         ↓
       Query
         ↓
    MongoDB Server
         ↓
    Query Planner
         ↓
 Choose Execution Plan
         ↓
┌──────────────────┐
│                  │
Index            Collection
Scan               Scan
│                  │
└────────┬─────────┘
         ↓
   Matching Documents
         ↓
       Results
         ↓
    Application

This is much closer to what happens conceptually.

MongoDB's server interprets the query, builds a plan, executes it, and returns the results.

17. Where Does Mongoose Fit?

If you're building a MERN application, you may not write MongoDB queries directly using db.users.find().

You might use Mongoose.

For example:

const user = await User.findOne({
    email: "aryan@example.com"
});

Here:

Your Code
   ↓
Mongoose
   ↓
MongoDB Driver
   ↓
MongoDB

Mongoose provides a higher-level developer experience with models and schemas.

But eventually, the database still needs to process a MongoDB query.

So this:

User.findOne({
    email: "aryan@example.com"
});

doesn't mean Mongoose itself searches through one million users.

The actual database operation is performed by MongoDB.

18. What Happens During a Real API Request?

Let's put everything together.

Suppose the client sends:

GET /users/123

Our Express route:

app.get("/users/:id", async (req, res) => {

    const user = await User.findOne({
        _id: req.params.id
    });

    res.json(user);
});

The complete flow looks like this:

                 Client
                    ↓
             HTTP Request
                    ↓
                Node.js
                    ↓
                Express
                    ↓
               Middleware
                    ↓
              Route Handler
                    ↓
             Mongoose Query
                    ↓
            MongoDB Driver
                    ↓
             MongoDB Server
                    ↓
             Query Planner
                    ↓
             Choose Plan
                    ↓
              Index / Scan
                    ↓
           Matching Document
                    ↓
              Query Result
                    ↓
               Mongoose
                    ↓
              Route Handler
                    ↓
             HTTP Response
                    ↓
                 Client

Now our previous parts connect together.

19. Why `_id` Is Special

Every MongoDB document has an _id field that uniquely identifies the document within its collection.

For example:

{
    _id: ObjectId("..."),
    name: "Aryan",
    email: "aryan@example.com"
}

MongoDB automatically creates a unique index on _id for a collection.

So a query such as:

db.users.findOne({
    _id: someId
});

can efficiently locate the document using the _id index.

This is one reason IDs are commonly used when retrieving a specific document.

20. What About Sorting?

Suppose we want the newest users:

db.users
    .find({})
    .sort({
        createdAt: -1
    });

If this operation is common, an index involving createdAt may help support the query and sorting.

For more complex queries, index field order becomes important.

For example:

db.users.createIndex({
    city: 1,
    createdAt: -1
});

can support query patterns involving the index's prefix and can also help with sorting depending on the query shape.

This is why indexes aren't simply:

"Make an index on everything."

They should be designed around the queries the application actually performs. MongoDB's indexing guidance recommends mapping application query patterns to appropriate indexes.

21. Indexes Are Not Magic

An index does not automatically make every query fast.

For example, a query might match a very large percentage of a collection.

In that situation, using an index may not provide much benefit.

MongoDB considers query selectivity when determining how useful an index is. Highly selective queries eliminate many possible documents and can benefit strongly from indexes.

So:

Good index
    +
Good query
    +
Appropriate data distribution
    ↓
Better performance

The important lesson is:

Indexes should be designed around real query patterns, not added blindly.

22. What Happens When Data Changes?

There is another side to indexes.

Suppose we have:

db.users.createIndex({
    email: 1
});

Now we insert:

{
    name: "Aryan",
    email: "aryan@example.com"
}

MongoDB has to store the document.

But it also has to maintain the index.

Conceptually:

Insert Document
      ↓
Store Document
      +
Update Index

This is why indexes improve many reads but add overhead to writes.

So database performance is always about trade-offs.

23. A Practical Backend Example

Imagine we are building a login API:

POST /login

The client sends:

{
    "email": "aryan@example.com",
    "password": "..."
}

Our Express route might look like:

app.post("/login", async (req, res) => {

    const { email, password } = req.body;

    const user = await User.findOne({
        email: email
    });

    if (!user) {
        return res.status(401).json({
            message: "Invalid credentials"
        });
    }

    // Password verification...

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

Now think about the database query.

If the application has millions of users and frequently searches by:

email

an appropriate index can be extremely important.

We could create:

db.users.createIndex({
    email: 1
});

Then MongoDB can use the index to efficiently locate candidate documents for the query.

This is a simple example of how application-level decisions and database-level decisions are connected.

24. How to Think About Database Performance

When a query becomes slow, don't immediately think:

"MongoDB is slow."

Instead, ask:

What query are we running?
        ↓
How many documents does it examine?
        ↓
Is an appropriate index available?
        ↓
Which execution plan was selected?
        ↓
How many documents are returned?
        ↓
Is the query selective?

MongoDB provides tools such as explain() to investigate these questions.

This is much more useful than simply adding random indexes.

25. Common Mistakes

❌ Creating an index on every field

More indexes aren't automatically better.

Indexes consume storage and can add write overhead.

❌ Assuming an index is always used

Creating an index doesn't mean every query will use it.

Use:

.explain("executionStats")

to inspect the actual query plan.

❌ Ignoring query patterns

Indexes should be based on how your application actually queries data.

For example, if your application frequently searches:

{
    email: "..."
}

then an index on email makes more sense than an index on a field that is rarely queried.

❌ Thinking MongoDB simply searches every document

MongoDB has a query planning and execution process.

It can use indexes or perform collection scans depending on the query and available plans.

❌ Adding indexes without measuring

Instead of guessing, inspect your queries using:

.explain("executionStats")

Look at:

nReturned
totalDocsExamined
totalKeysExamined
executionTimeMillis

These statistics help us understand what MongoDB actually did.

26. The Mental Model

If you remember only one thing from this article, remember this:

    Application
         ↓
       Query
         ↓
      MongoDB
         ↓
    Query Planner
         ↓
   Execution Plan
         ↓
┌─────────────────┐
│                 │
Index          Collection
Scan              Scan
│                 │
└────────┬────────┘
         ↓
Matching Documents
         ↓
       Results
         ↓
    Application

And when we use an index:

Query
  ↓
Index
  ↓
Find relevant entries
  ↓
Retrieve documents
  ↓
Return results

The key idea is:

MongoDB doesn't just "look for your data." It chooses a way to find it.

27. The Bigger Picture

Let's connect the first five parts of Under the Hood.

Part 1
What Happens When You Enter a URL?
        ↓
Part 2
How HTTP Requests Work
        ↓
Part 3
How Node.js Handles Requests
        ↓
Part 4
How Express Middleware Works
        ↓
Part 5
How MongoDB Finds Your Data

Now we can understand the journey much better:

Browser
   ↓
URL
   ↓
HTTP Request
   ↓
Node.js
   ↓
Express
   ↓
Middleware
   ↓
Route Handler
   ↓
MongoDB Query
   ↓
Query Planner
   ↓
Index / Collection Scan
   ↓
Document
   ↓
HTTP Response
   ↓
Browser

Each part is responsible for a different stage of the journey.

28. Conclusion

MongoDB queries may look simple from our application code:

const user = await User.findOne({
    email: "aryan@example.com"
});

But behind that single line, several things happen.

The application sends a query through the MongoDB driver.

MongoDB receives and interprets the query.

The query planner determines an execution plan.

MongoDB may use an index to locate relevant documents or perform a collection scan.

The matching documents are then returned to the application.

The most important concepts to remember are:

MongoDB stores data as BSON documents.
Applications communicate with MongoDB through drivers.
Mongoose provides a higher-level way to work with MongoDB from Node.js applications.
MongoDB uses a query planning process to determine how to execute a query.
A collection scan checks documents in the collection.
An index provides a separate data structure that can help locate relevant documents.
IXSCAN indicates index scanning in an explain plan.
COLLSCAN indicates a collection scan.
explain("executionStats") helps us understand how a query was executed.
Indexes improve many reads but add overhead to writes.

The bigger picture is now:

Client
  ↓
HTTP Request
  ↓
Node.js
  ↓
Express
  ↓
Middleware
  ↓
Route Handler
  ↓
MongoDB Query
  ↓
Query Planner
  ↓
Index / Collection Scan
  ↓
Document
  ↓
HTTP Response
  ↓
Client

But finding the user is only one part of building a real application.

The next question is:

How does our application know whether the user making the request is actually allowed to access that data?

That's where authentication comes in.

That's what we'll explore in the next part of Under the Hood.

References

How Express Middleware Works

Aryan Gupta — Sun, 04 Oct 2026 07:35:44 +0000

In the previous part of Under the Hood, we explored how Node.js handles incoming requests using the event loop, asynchronous I/O, and non-blocking operations.

But most Node.js applications don't handle every request directly with Node's built-in HTTP module.

Instead, we commonly use Express.

And Express introduces one of the most important concepts in backend development:

Middleware

You have probably written code like this:

app.use(express.json());

or:

app.use((req, res, next) => {
    console.log("Request received");
    next();
});

But what actually happens when a request passes through middleware?

Why do we need next()?

What happens if middleware doesn't call next()?

And how does Express decide which middleware should run?

Let's go Under the Hood.

1. What Is Express?

Express is a web framework built on top of Node.js.

It provides a simpler way to build web servers and APIs by giving us features such as:

Routing
Middleware
Request and response handling
Error handling
JSON parsing
Static file serving

Without Express, we could create a server using Node's built-in http module:

const http = require("http");

const server = http.createServer((req, res) => {
    res.end("Hello World");
});

server.listen(3000);

Express gives us a more structured way to organize the same kind of application.

For example:

const express = require("express");

const app = express();

app.get("/", (req, res) => {
    res.send("Hello World");
});

app.listen(3000);

But one of the biggest ideas Express adds is its middleware system.

2. What Is Middleware?

A middleware function is a function that runs during the lifecycle of a request.

A typical middleware function looks like this:

app.use((req, res, next) => {

    console.log("Request received");

    next();

});

It receives three important things:

req
res
next

`req`

Contains information about the incoming request.

For example:

URL
HTTP method
headers
query parameters
body
route parameters

`res`

Used to send a response back to the client.

For example:

res.send("Hello");

`next`

A function that tells Express:

"I'm finished. Continue to the next middleware."

This simple function is the foundation of the Express middleware system.

3. The Middleware Chain

Imagine we have three middleware functions:

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

app.use((req, res, next) => {
    console.log("Middleware 2");
    next();
});

app.use((req, res, next) => {
    console.log("Middleware 3");
    next();
});

When a request arrives, Express processes them in order.

Request
   ↓
Middleware 1
   ↓
Middleware 2
   ↓
Middleware 3
   ↓
Route Handler
   ↓
Response

This is called a middleware chain.

Each middleware can:

Modify the request
Modify the response
Perform some operation
End the request
Pass control to the next middleware

4. Why Do We Need `next()`?

Consider:

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

There is no next().

What happens?

The request reaches this middleware and execution stops there.

Express doesn't automatically know that this middleware has finished.

So the request can remain hanging unless the middleware sends a response.

Compare that with:

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

Now Express knows:

Middleware 1
      ↓
   next()
      ↓
Next Middleware

So next() is essentially how middleware passes control forward.

5. Middleware Can End the Request

Middleware doesn't always need to call next().

It can also send a response.

For example:

app.use((req, res, next) => {

    res.send("Request handled");

});

The request ends here.

The flow becomes:

Request
   ↓
Middleware
   ↓
Response
   ↓
Request Ends

There is no reason to call next() because there is nothing else that needs to handle the request.

This is useful for things such as:

Blocking unauthorized requests
Returning cached responses
Handling specific conditions
Returning maintenance messages

6. Middleware Can Modify the Request

One powerful feature of middleware is that it can add information to the request object.

For example:

app.use((req, res, next) => {

    req.userRole = "admin";

    next();

});

Later middleware can access:

console.log(req.userRole);

The flow becomes:

Incoming Request
       ↓
Authentication Middleware
       ↓
req.userRole = "admin"
       ↓
Next Middleware
       ↓
Route Handler

This allows information to be passed through different stages of request processing.

7. A Real Authentication Example

Imagine an API endpoint:

GET /profile

We want only authenticated users to access it.

We could create middleware:

function authenticate(req, res, next) {

    const token = req.headers.authorization;

    if (!token) {
        return res.status(401).json({
            message: "Unauthorized"
        });
    }

    next();
}

Then use it:

app.get("/profile", authenticate, (req, res) => {

    res.json({
        message: "Profile data"
    });

});

The flow is:

      Client
        ↓
   GET /profile
        ↓
   authenticate()
        ↓
   Token exists?
        ↓
 ┌───────────────┐
 │               │
No              Yes
 │               │
 ↓               ↓
401           next()
Response         ↓
              Route
                ↓
             Response

This is one of the reasons middleware is so useful.

Instead of putting authentication logic inside every route, we can create it once and reuse it.

8. Types of Middleware

Express applications commonly use different types of middleware.

Application-level middleware

Applied to the application:

app.use((req, res, next) => {
    console.log("Request received");
    next();
});

This can run for many or all requests depending on how it is configured.

Router-level middleware

Middleware can also be attached to a router.

const router = express.Router();

router.use((req, res, next) => {
    console.log("Router middleware");
    next();
});

This is useful when an application has multiple groups of routes.

For example:

/users
/products
/orders

We can have different middleware for different routers.

Built-in middleware

Express also provides built-in middleware.

For example:

app.use(express.json());

This allows Express to parse incoming JSON request bodies.

If the client sends:

{
    "name": "Aryan"
}

the parsed data can be accessed through:

req.body

Error-handling middleware

Express also supports special middleware for handling errors.

It has four parameters:

(err, req, res, next)

For example:

app.use((err, req, res, next) => {

    console.error(err);

    res.status(500).json({
        message: "Something went wrong"
    });

});

The four parameters are important because they identify this function as error-handling middleware.

9. How Express Knows the Order

Middleware order matters.

Consider:

app.use((req, res, next) => {
    console.log("A");
    next();
});

app.use((req, res, next) => {
    console.log("B");
    next();
});

app.get("/", (req, res) => {
    console.log("C");
    res.send("Hello");
});

A request to / produces:

A
B
C

Express processes middleware and routes according to their order in the application.

This means that changing the order can change the behavior of your application.

For example:

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

app.use((req, res, next) => {
    console.log("Middleware");
    next();
});

The middleware won't run for that request because the route already handled it.

This is why middleware placement is important.

10. Middleware as a Pipeline

A useful mental model is to think of middleware as a pipeline.

Imagine an incoming request:

                Request
                   ↓
          ┌─────────────────┐
          │ Logging         │
          └────────┬────────┘
                   ↓
          ┌─────────────────┐
          │ JSON Parser     │
          └────────┬────────┘
                   ↓
          ┌─────────────────┐
          │ Authentication  │
          └────────┬────────┘
                   ↓
          ┌─────────────────┐
          │ Authorization   │
          └────────┬────────┘
                   ↓
          ┌─────────────────┐
          │ Route Handler   │
          └────────┬────────┘
                   ↓
                Response

Each stage can inspect or modify the request before passing it forward.

This pipeline model makes complex backend applications easier to understand.

11. What Happens If Middleware Sends a Response?

Suppose:

app.use((req, res, next) => {

    if (!req.headers.authorization) {
        return res.status(401).send("Unauthorized");
    }

    next();

});

If there is no authorization header:

Request
   ↓
Authentication Middleware
   ↓
No Token
   ↓
401 Response
   ↓
Request Ends

The route handler never runs.

This is useful because middleware can stop invalid requests before they reach the business logic.

12. Why `return` Is Often Used

You will often see:

return res.status(401).json({
    message: "Unauthorized"
});

The return makes sure the function exits immediately after sending the response.

For example, without careful control flow:

if (!token) {
    res.status(401).json({
        message: "Unauthorized"
    });
}

next();

The code could continue and call next() after attempting to send the response.

A safer pattern is:

if (!token) {
    return res.status(401).json({
        message: "Unauthorized"
    });
}

next();

The key idea is:

Once middleware has ended the request, it should not continue the normal middleware chain.

13. Error Handling in Middleware

Errors can occur anywhere in an application.

For example:

app.get("/users", async (req, res, next) => {

    try {

        const users = await User.find();

        res.json(users);

    } catch (error) {

        next(error);

    }

});

Instead of handling the error inside every part of the application, we can pass it to error-handling middleware.

app.use((err, req, res, next) => {

    console.error(err);

    res.status(500).json({
        message: "Internal Server Error"
    });

});

The flow becomes:

Request
   ↓
Route
   ↓
Database Operation
   ↓
Error
   ↓
next(error)
   ↓
Error Middleware
   ↓
Error Response

This gives applications a centralized way to handle errors.

14. `next()` vs `next(error)`

There is an important difference.

`next()`

Means:

Continue normally.

next();

Flow:

Middleware
    ↓
next()
    ↓
Next Middleware

`next(error)`

Means:

Something went wrong. Pass this error forward.

next(error);

Flow:

Middleware
    ↓
Error
    ↓
next(error)
    ↓
Error Handler

This distinction is fundamental to Express error handling.

15. Middleware Can Be Reused

One of the biggest benefits of middleware is reusability.

For example:

function logger(req, res, next) {

    console.log(req.method, req.url);

    next();
}

We can use it globally:

app.use(logger);

Or for a specific route:

app.get("/profile", logger, (req, res) => {

    res.send("Profile");

});

Instead of repeating the same logic in multiple routes, we define it once.

16. A Complete Example

Let's combine several concepts.

const express = require("express");

const app = express();

app.use(express.json());

app.use((req, res, next) => {

    console.log(req.method, req.url);

    next();

});

function authenticate(req, res, next) {

    const token = req.headers.authorization;

    if (!token) {
        return res.status(401).json({
            message: "Unauthorized"
        });
    }

    next();
}

app.get("/profile", authenticate, (req, res) => {

    res.json({
        message: "Profile data"
    });

});

app.use((err, req, res, next) => {

    console.error(err);

    res.status(500).json({
        message: "Internal Server Error"
    });

});

app.listen(3000);

Now imagine a request:

GET /profile

The simplified flow is:

                    Request
                       ↓
                express.json()
                       ↓
                    Logger
                       ↓
                  authenticate
                       ↓
                 Token exists?
                   /       \
                 No         Yes
                 ↓           ↓
             401 Response   Route
                             ↓
                          Response

This is the Express middleware pipeline in action.

17. What Happens Under the Hood?

At a high level, when a request enters an Express application, Express maintains a stack of middleware and route handlers.

Conceptually:

Express Application
        ↓
   Middleware Stack
        ↓
 ┌──────┴──────┐
 ↓             ↓
Middleware   Middleware
 ↓             ↓
 └──────┬──────┘
        ↓
   Route Handler
        ↓
     Response

Each matching layer gets a chance to process the request.

Calling:

next();

moves processing forward.

Sending a response ends the request.

Calling:

next(error);

moves the request into error-handling flow.

This simple mechanism is what allows Express applications to build complex request-processing pipelines.

18. Common Mistakes

❌ Forgetting `next()`

app.use((req, res, next) => {
    console.log("Hello");
});

The request may hang because neither the middleware nor the next handler completes the request.

❌ Sending a response and continuing

if (!token) {
    res.status(401).send("Unauthorized");
}

next();

Prefer:

if (!token) {
    return res.status(401).send("Unauthorized");
}

next();

❌ Putting middleware in the wrong order

Middleware that needs to run before a route must be registered appropriately before that route.

Order matters.

❌ Putting all logic into middleware

Middleware should generally handle cross-cutting request-processing concerns such as:

Logging
Authentication
Validation
Parsing
Authorization
Error handling

Business logic is often better kept inside appropriate services or route/controller layers.

19. The Mental Model

If you remember only one thing from this article, remember this:

Request
   ↓
Middleware
   ↓
Middleware
   ↓
Middleware
   ↓
Route Handler
   ↓
Response

Each middleware can:

Inspect
   ↓
Modify
   ↓
Continue
   ↓
OR
   ↓
End Request

And when something goes wrong:

Error
  ↓
next(error)
  ↓
Error Middleware
  ↓
Error Response

That's the core idea behind Express middleware.

20. Conclusion

Express middleware gives us a structured way to process requests before they reach the final route handler.

Instead of putting authentication, logging, validation, error handling, and other common operations inside every route, we can separate them into reusable middleware functions.

The most important concepts to remember are:

Middleware runs during the request-response lifecycle.
next() passes control to the next middleware.
Middleware can modify req and res.
Middleware can end a request by sending a response.
Middleware order matters.
next(error) passes errors to error-handling middleware.
Middleware can be reused across multiple routes.

The bigger picture is:

Client
  ↓
HTTP Request
  ↓
Node.js
  ↓
Express
  ↓
Middleware Pipeline
  ↓
Route Handler
  ↓
Database / Business Logic
  ↓
HTTP Response
  ↓
Client

Now we know how a request reaches Express and how it moves through the application.

But eventually, the route handler needs data.

So the next question is:

When our application asks MongoDB for a user, how does MongoDB actually find that data?

That's what we'll explore in the next part of Under the Hood.

References

How Node.js Handles Requests

Aryan Gupta — Sat, 03 Oct 2026 08:51:09 +0000

In the previous part of Under the Hood, we looked at how HTTP requests work.

But once an HTTP request reaches our server, another question appears:

What actually happens inside Node.js when a request arrives?

If multiple users send requests at the same time, does Node.js create a new thread for every request?

If one request is waiting for a database response, does the entire server stop?

The answer lies in how Node.js handles JavaScript execution, asynchronous operations, the event loop, and I/O.

Let's go under the hood.

1. What is Node.js?

Node.js is a JavaScript runtime that allows us to execute JavaScript outside the browser.

Normally, JavaScript runs inside environments such as a browser.

With Node.js, we can run JavaScript on a server and build:

Web servers
REST APIs
Backend applications
Real-time applications
Command-line tools
Network services

Node.js uses the V8 JavaScript engine to execute JavaScript.

V8 is the same JavaScript engine originally developed for Google Chrome.

But Node.js is more than just V8.

It also provides APIs for things such as:

File systems
Networking
Timers
HTTP
Streams
Processes

A simplified view looks like this:

Your JavaScript Code
        ↓
      Node.js
        ↓
       V8
        ↓
   Machine / OS

But this doesn't explain how Node.js handles many requests efficiently.

For that, we need to understand its execution model.

2. What Happens When a Request Arrives?

Suppose we create a simple Node.js server:

const http = require("http");

const server = http.createServer((req, res) => {
    res.end("Hello World");
});

server.listen(3000);

When a client requests:

GET / HTTP/1.1

Node.js receives the request and executes the callback:

(req, res) => {
    res.end("Hello World");
}

The simplified flow is:

Client
   ↓
HTTP Request
   ↓
Node.js
   ↓
Request Handler
   ↓
Response
   ↓
Client

But there is an important question:

What happens when another request arrives while the first request is being processed?

This is where the event loop becomes important.

3. Is Node.js Single-Threaded?

You will often hear:

"Node.js is single-threaded."

This statement is useful for beginners, but it is an oversimplification.

The JavaScript code that we write normally runs on a single main thread.

That means Node.js does not normally create a new JavaScript thread for every incoming request.

Instead, Node.js uses an event-driven, non-blocking I/O model.

This allows the main JavaScript thread to keep handling other work while certain operations are being handled asynchronously.

A simplified picture:

             Node.js
                |
        JavaScript Thread
                |
           Event Loop
                |
      -------------------
      |        |        |
   Network   File I/O  Timers

This is one of the most important ideas behind Node.js.

4. What is the Event Loop?

The event loop is a mechanism that allows Node.js to handle asynchronous operations without blocking the main JavaScript thread.

Consider:

console.log("Start");

setTimeout(() => {
    console.log("Timer finished");
}, 1000);

console.log("End");

The output is:

Start
End
Timer finished

Why?

Because Node.js doesn't stop executing JavaScript for one second.

Instead, the timer is registered, and Node.js continues executing the rest of the code.

Later, when the timer is ready, its callback can be executed.

Simplified:

Start
  ↓
Register Timer
  ↓
Continue JavaScript
  ↓
End
  ↓
Wait for Timer
  ↓
Execute Callback

This is the basic idea of asynchronous execution.

5. Blocking vs Non-Blocking Code

Understanding blocking and non-blocking operations is extremely important when working with Node.js.

Blocking

A blocking operation prevents the JavaScript thread from continuing with other JavaScript work.

For example:

const fs = require("fs");

const data = fs.readFileSync("data.txt");

console.log(data);

readFileSync() waits until the file has been completely read.

During that time, the JavaScript execution cannot continue past that statement.

Non-Blocking

Node.js also provides asynchronous APIs:

const fs = require("fs");

fs.readFile("data.txt", (err, data) => {
    console.log(data);
});

console.log("Server is still running");

Now Node.js can continue executing other JavaScript while the file operation is being handled.

The simplified flow is:

JavaScript
    ↓
Start File Operation
    ↓
Continue Executing
    ↓
Other Requests
    ↓
File Operation Completes
    ↓
Callback Executes

This is why asynchronous I/O is so important for Node.js applications.

6. What is I/O?

I/O means Input/Output.

Examples include:

Reading a file
Writing a file
Sending data over a network
Receiving data from a database
Making an external API request

These operations can involve waiting.

For example:

Node.js
   ↓
Database Query
   ↓
Waiting for Response
   │
   └──→ Node.js handles other work
                ↓
        Database Response

If Node.js simply blocked the JavaScript thread every time it had to wait for I/O, handling many requests would become inefficient.

Instead, Node.js can continue working on other tasks.

7. A Real HTTP Example

Consider this server:

const http = require("http");

const server = http.createServer((req, res) => {

    setTimeout(() => {
        res.end("Response");
    }, 2000);

});

server.listen(3000);

Suppose three users send requests:

User A → Request
User B → Request
User C → Request

Node.js doesn't necessarily need to completely finish A before it can begin handling B and C.

Conceptually:

Request A ────────┐
                  │
Request B ────────┼──→ Event Loop
                  │
Request C ────────┘

The asynchronous work can complete later, and the corresponding callback can be executed.

This is one reason Node.js is commonly used for applications that handle many I/O-heavy operations.

8. Where Does libuv Come In?

There is another important piece underneath Node.js:

libuv

libuv is a library used by Node.js that provides asynchronous I/O capabilities and the event-loop implementation.

A simplified architecture looks like:

JavaScript Application
         ↓
       Node.js
         ↓
        V8
         ↓
       libuv
         ↓
 Operating System

libuv helps Node.js deal with asynchronous operations such as networking and certain file-system operations.

It also provides a thread pool for some operations that cannot be handled directly through the operating system's asynchronous interfaces.

So saying:

"Node.js has one thread and therefore can only do one thing at a time"

is misleading.

The more accurate explanation is:

JavaScript execution normally happens on a single main thread, while Node.js uses asynchronous I/O mechanisms and, for some operations, a thread pool to handle work outside that main JavaScript execution path.

9. What is the Thread Pool?

libuv maintains a thread pool that can be used for certain expensive or blocking operations.

For example, some file-system operations and cryptographic operations may use the thread pool.

A simplified view:

                 Node.js
                    |
             JavaScript Thread
                    |
                Event Loop
                    |
             ----------------
             |              |
        Async I/O       Thread Pool
                            |
                     Worker Threads

The important point is:

The thread pool is not the same thing as creating one thread per HTTP request.

Node.js still executes your JavaScript callbacks on the main JavaScript thread.

10. What Happens During a Database Request?

Imagine an API:

app.get("/users", async (req, res) => {

    const users = await User.find();

    res.json(users);

});

When the database query is started, the JavaScript execution does not simply sit there doing nothing until the database responds.

The operation is asynchronous.

Conceptually:

HTTP Request
     ↓
Express Route
     ↓
Database Query
     ↓
Waiting for Database
     │
     └────→ Node.js can handle other work
                    ↓
              Database responds
                    ↓
              Continue execution
                    ↓
              Send HTTP Response

This is one reason async/await is so useful.

It makes asynchronous code easier to read without turning it into blocking code.

11. What Does `await` Actually Mean?

Consider:

const users = await User.find();

A common misconception is:

"await blocks Node.js."

It doesn't block the entire Node.js process in the same way a synchronous blocking operation would.

Instead, await pauses the execution of that particular asynchronous function until the Promise settles.

Other work can continue through the event loop.

Conceptually:

Request A
   ↓
await Database Query
   ↓
Function pauses
   ↓
Node.js handles other work
   ↓
Database responds
   ↓
Function continues

This distinction is extremely important.

12. What Happens When You Make a CPU-Heavy Operation?

Node.js works particularly well for I/O-heavy applications.

But there is an important limitation.

Consider:

let total = 0;

for (let i = 0; i < 10000000000; i++) {
    total += i;
}

This is CPU-intensive work.

Because JavaScript execution is happening on the main thread, a long-running CPU-heavy task can prevent the event loop from processing other JavaScript work efficiently.

The result can look like:

Heavy CPU Task
      ↓
Main Thread Busy
      ↓
Event Loop Delayed
      ↓
Other Requests Wait

So Node.js being non-blocking does not mean every type of work is automatically non-blocking.

CPU-heavy work needs different strategies, such as:

Worker Threads
Child Processes
Moving computation to another service
Queue-based processing

13. The Complete Request Journey

Let's put everything together.

Suppose a browser sends:

GET /users

The simplified journey is:

                 Client
                    |
                    ↓
              HTTP Request
                    |
                    ↓
                Node.js
                    |
                    ↓
               Event Loop
                    |
                    ↓
             Express Handler
                    |
                    ↓
              Database Query
                    |
                    ↓
             Async Waiting
                    |
          ┌─────────┴─────────┐
          ↓                   ↓
   Other Requests        Database
          |               Response
          |                   |
          └─────────┬─────────┘
                    ↓
             Continue Code
                    |
                    ↓
             HTTP Response
                    |
                    ↓
                 Client

This is the basic idea behind how a Node.js backend handles asynchronous requests.

14. Why Node.js Works Well for Web Applications

Node.js is particularly useful for applications that perform a lot of I/O operations.

Examples include:

REST APIs
Real-time applications
Chat applications
Streaming applications
Web servers
API gateways

The reason isn't simply:

"Node.js is fast."

The more useful explanation is:

Node.js can efficiently handle many I/O-bound operations by avoiding unnecessary blocking of the main JavaScript execution thread.

15. Common Misconceptions

❌ "Node.js creates one thread for every request."

Not normally.

Node.js primarily uses a single JavaScript execution thread rather than creating a dedicated JavaScript thread for every request.

❌ "Node.js can never use multiple threads."

Not true.

Node.js and its underlying components can use additional threads, including libuv's thread pool and mechanisms such as Worker Threads.

❌ "`await` blocks the entire server."

No.

await pauses the current asynchronous function while allowing other work to continue.

❌ "Non-blocking means nothing ever waits."

No.

Operations such as network and database requests still involve waiting for external systems.

The difference is that Node.js can use that time to handle other work.

16. The Mental Model

If you remember only one thing from this article, remember this:

             Node.js
                |
        ┌───────┴────────┐
        ↓                ↓
 JavaScript          Async I/O
    Thread               |
        ↓                ↓
   Event Loop         OS / APIs
        |                |
        └───────┬────────┘
                ↓
          Callbacks /
           Promises

Node.js doesn't make waiting disappear.

It makes it possible to handle waiting without unnecessarily blocking the main JavaScript execution thread.

17. Conclusion

When a request reaches a Node.js server, there is much more happening than simply running a function.

Node.js uses a JavaScript execution thread, event loop, asynchronous I/O, and libuv to handle work efficiently. Instead of blocking the main thread while waiting for operations such as network or database requests, Node.js can continue handling other work and return to the original operation when it is ready.

The key idea to remember is:

Node.js doesn't eliminate waiting. It avoids unnecessarily blocking the main JavaScript execution thread while waiting.

However, this model also has limits. CPU-heavy JavaScript can keep the main thread busy and delay other requests, which is why techniques such as Worker Threads, Child Processes, and background processing can be useful for CPU-intensive tasks.

Understanding this request-handling model gives us a much better picture of what happens inside a Node.js backend.

And we're not done yet.

18. What's Next?

So far, we have followed the request from the browser to Node.js.

But most Node.js applications don't handle every request using raw Node.js APIs.

They use frameworks such as Express.

And Express introduces another important concept:

Middleware

When a request enters an Express application, it can pass through multiple pieces of middleware before reaching the final route handler.

So the next question is:

What exactly happens when a request passes through Express middleware?

That's what we'll explore in the next part of Under the Hood.

References

How HTTP Requests Work?

Aryan Gupta — Fri, 02 Oct 2026 05:08:21 +0000

Have you ever wondered what actually happens when you click a button on a website and data appears on the screen?

For example, you open an e-commerce website and click "View Products".

Behind the scenes, your frontend might send a request like:

GET /api/products

The backend receives this request, processes it, may communicate with a database, and finally sends a response back.

But how does this actually work?

What is inside an HTTP request?

What are headers?

What is the difference between GET, POST, PUT, and DELETE?

What are query parameters and URL parameters?

And how does all of this connect to a MERN application?

Let's understand HTTP requests step by step.

1. What is HTTP?

HTTP stands for HyperText Transfer Protocol.

It is a protocol that allows clients and servers to communicate with each other over a network.

A client can be:

Web browser
React application
Mobile application
API testing tool
Another server

A server can be:

Node.js server
Express server
Java backend
Python backend
Any application that can handle HTTP requests

The basic communication looks like this:

Client
   |
   | HTTP Request
   ↓
Server
   |
   | HTTP Response
   ↓
Client

The client asks for something, and the server responds.

This is called the request-response model.

2. A Simple HTTP Request

Suppose we have an API for getting products.

The client sends:

GET /api/products HTTP/1.1
Host: example.com
Accept: application/json

The server might respond:

HTTP/1.1 200 OK
Content-Type: application/json

[
    {
        "id": 1,
        "name": "Keyboard",
        "price": 2000
    }
]

There are several important parts here.

The request contains:

HTTP Method
URL / Path
Headers
Body

The response contains:

Status Code
Headers
Body

Let's understand each part.

3. Anatomy of an HTTP Request

An HTTP request can contain four important parts:

Method
URL
Headers
Body

For example:

POST /api/products HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer token123

{
    "name": "Keyboard",
    "price": 2000
}

Let's break it down.

Method

POST

This tells the server what operation the client wants to perform.

URL / Path

/api/products

This tells the server which resource the client wants to access.

Headers

Content-Type: application/json
Authorization: Bearer token123

Headers provide additional information about the request.

Body

{
    "name": "Keyboard",
    "price": 2000
}

The body contains the actual data being sent to the server.

4. HTTP Methods

HTTP methods tell the server what the client wants to do.

The most commonly used methods are:

Method	Purpose	Example
GET	Read data	Get products
POST	Create data	Create a product
PUT	Replace/update data	Replace a product
PATCH	Partially update data	Update product price
DELETE	Delete data	Delete a product

Let's understand them one by one.

GET

GET is used to retrieve data.

Example:

GET /api/products

Express:

app.get("/api/products", (req, res) => {
    res.json({
        message: "Products fetched successfully"
    });
});

The server returns the requested data.

POST

POST is generally used to create new data.

Example:

POST /api/products

The client can send product information in the request body:

{
    "name": "Keyboard",
    "price": 2000
}

Express:

app.post("/api/products", (req, res) => {
    res.status(201).json({
        message: "Product created successfully"
    });
});

PUT

PUT is generally used to replace an existing resource.

Example:

PUT /api/products/10

The client may send the complete updated resource.

{
    "name": "Mechanical Keyboard",
    "price": 3500
}

PATCH

PATCH is generally used to partially update a resource.

For example, if we only want to change the price:

PATCH /api/products/10

Body:

{
    "price": 3500
}

We don't need to send the entire product.

DELETE

DELETE is used to delete a resource.

Example:

DELETE /api/products/10

Express:

app.delete("/api/products/:id", (req, res) => {
    res.json({
        message: "Product deleted successfully"
    });
});

5. GET vs POST

One of the most common questions when learning backend development is:

What is the difference between GET and POST?

GET

Used to retrieve data.

GET /api/products

POST

Used to send data to the server, commonly to create a resource.

POST /api/products

For example:

{
    "name": "Keyboard",
    "price": 2000
}

A simple way to remember:

GET  → Give me data

POST → Here is some data

6. What are HTTP Headers?

Headers provide additional information about an HTTP request or response.

For example:

Content-Type: application/json
Authorization: Bearer token123
Accept: application/json

Headers follow this format:

Name: Value

For example:

Content-Type: application/json

means that the content being sent is JSON.

7. Important HTTP Headers

There are many HTTP headers, but some are especially important for web developers.

Content-Type

Tells the server what type of data is being sent.

Content-Type: application/json

For example:

{
    "name": "Keyboard"
}

Accept

Tells the server what type of response the client expects.

Accept: application/json

Authorization

Commonly used for authentication.

Authorization: Bearer token123

We will explore authentication and JWT in later parts of this series.

Cookie

Cookies can be sent from the browser to the server.

Cookie: sessionId=abc123

Cookies are commonly used for sessions, authentication, preferences, and other browser-related data.

Cache-Control

Used to control caching behavior.

Cache-Control: max-age=3600

We will discuss caching in a later part of this series.

8. What is the Request Body?

The request body contains data sent from the client to the server.

For example, when creating a product:

POST /api/products
Content-Type: application/json

{
    "name": "Mechanical Keyboard",
    "price": 3500
}

The JSON object is the request body.

In Express, we can access it using:

req.body

First, we need to enable JSON parsing:

const express = require("express");

const app = express();

app.use(express.json());

app.post("/api/products", (req, res) => {
    console.log(req.body);

    res.json({
        message: "Product received"
    });
});

If the client sends:

{
    "name": "Mechanical Keyboard",
    "price": 3500
}

then:

req.body

contains:

{
    name: "Mechanical Keyboard",
    price: 3500
}

9. Query Parameters

Query parameters are values added to the URL.

For example:

/api/products?category=keyboard

Here:

category=keyboard

is a query parameter.

We can have multiple query parameters:

/api/products?category=keyboard&sort=price

In Express:

app.get("/api/products", (req, res) => {
    console.log(req.query);

    res.json(req.query);
});

For:

/api/products?category=keyboard&sort=price

we get:

{
    category: "keyboard",
    sort: "price"
}

Query parameters are commonly used for:

Searching
Filtering
Sorting
Pagination

For example:

/api/products?search=keyboard

or:

/api/products?page=2&limit=10

10. URL Parameters

URL parameters are values included directly in the URL path.

For example:

/api/products/123

Here:

can represent the product ID.

In Express:

app.get("/api/products/:id", (req, res) => {
    console.log(req.params.id);

    res.json({
        productId: req.params.id
    });
});

If we request:

/api/products/123

then:

req.params.id

will contain:

URL parameters are commonly used when accessing a specific resource.

11. Query Parameters vs URL Parameters vs Request Body

These three concepts are commonly confused when learning backend development.

Query Parameter

/api/products?category=keyboard

Used for:

Filtering
Searching
Sorting
Pagination

Access using:

req.query

URL Parameter

/api/products/123

Used to identify a specific resource.

Access using:

req.params

Request Body

{
    "name": "Keyboard",
    "price": 2000
}

Used to send data to the server.

Access using:

req.body

A simple way to remember:

Query Parameter → Filter or modify the request

URL Parameter   → Identify a resource

Request Body    → Send data

12. HTTP Status Codes

After processing the request, the server sends a response.

One important part of the response is the HTTP status code.

For example:

HTTP/1.1 200 OK

Here:

is the status code.

HTTP status codes are divided into five categories:

1xx → Informational
2xx → Success
3xx → Redirection
4xx → Client Error
5xx → Server Error

You don't need to memorize every status code.

Let's look at the important ones.

13. Common 2xx Status Codes

200 OK

The request was successful.

res.status(200).json({
    message: "Products fetched successfully"
});

201 Created

A new resource was successfully created.

res.status(201).json({
    message: "Product created successfully"
});

This is commonly used after a successful POST request.

204 No Content

The request was successful, but the server does not return a response body.

It can be useful when an operation succeeds but there is nothing to return.

14. Common 4xx Status Codes

These usually indicate a problem with the client's request.

400 Bad Request

The request is invalid.

res.status(400).json({
    message: "Invalid product data"
});

401 Unauthorized

Authentication credentials are missing or invalid.

res.status(401).json({
    message: "Authentication required"
});

403 Forbidden

The server understands the request, but the user does not have permission.

For example:

Normal User
     ↓
Admin-only resource
     ↓
403 Forbidden

404 Not Found

The requested resource does not exist.

For example:

GET /api/products/999

If product 999 doesn't exist:

res.status(404).json({
    message: "Product not found"
});

15. Common Server Error Status Codes

These indicate that something went wrong on the server.

500 Internal Server Error

Something unexpected happened while processing the request.

res.status(500).json({
    message: "Internal server error"
});

A simple way to remember:

4xx → Problem with the request

5xx → Problem on the server

16. What Does an HTTP Response Look Like?

An HTTP response can contain:

Status Code
Headers
Body

Example:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "message": "Products fetched successfully"
}

Here:

200 OK

is the status code.

Content-Type: application/json

is a response header.

And:

{
    "message": "Products fetched successfully"
}

is the response body.

17. HTTP and JSON

Modern web applications commonly use JSON to exchange data.

JSON stands for:

JavaScript Object Notation

Example:

{
    "id": 1,
    "name": "Keyboard",
    "price": 2000
}

An Express server can send JSON using:

res.json({
    id: 1,
    name: "Keyboard",
    price: 2000
});

The frontend can then read the response.

const response = await fetch("/api/products");

const data = await response.json();

console.log(data);

18. Sending HTTP Requests with JavaScript

The browser provides the fetch() API for making HTTP requests.

For example:

const response = await fetch("/api/products");

const data = await response.json();

console.log(data);

The flow is:

JavaScript
    ↓
fetch()
    ↓
HTTP Request
    ↓
Server
    ↓
HTTP Response
    ↓
response.json()
    ↓
JavaScript

19. Sending Data with POST

We can also send data to the server using fetch().

const response = await fetch("/api/products", {
    method: "POST",

    headers: {
        "Content-Type": "application/json"
    },

    body: JSON.stringify({
        name: "Keyboard",
        price: 2000
    })
});

const data = await response.json();

console.log(data);

Let's understand this.

Method

method: "POST"

We are sending a POST request.

Headers

headers: {
    "Content-Type": "application/json"
}

We are telling the server that the request body contains JSON.

Body

body: JSON.stringify({
    name: "Keyboard",
    price: 2000
})

JSON.stringify() converts the JavaScript object into a JSON string that can be sent in the request body.

20. How Express Receives the Request

Now let's connect HTTP with Node.js and Express.

const express = require("express");

const app = express();

app.use(express.json());

app.post("/api/products", (req, res) => {
    console.log(req.body);

    res.status(201).json({
        message: "Product created",
        product: req.body
    });
});

app.listen(3000, () => {
    console.log("Server running on port 3000");
});

If the frontend sends:

{
    "name": "Keyboard",
    "price": 2000
}

Express receives it through:

req.body

and sends a response using:

res.json()

This is the basic connection between an HTTP request and an Express route.

21. Request → Server → Database → Response

In a real application, the server may need to communicate with a database.

For example:

app.get("/api/products", async (req, res) => {
    try {
        const products = await Product.find();

        res.status(200).json(products);
    } catch (error) {
        res.status(500).json({
            message: "Something went wrong"
        });
    }
});

The flow is:

GET /api/products
        ↓
Express receives request
        ↓
Route matches
        ↓
Product.find()
        ↓
MongoDB returns data
        ↓
Express creates response
        ↓
Client receives JSON

This is a common flow in MERN applications.

22. Complete HTTP Flow in a MERN Application

Let's look at a complete example.

Suppose a React application wants to display products.

Step 1 — React sends a request

const response = await fetch("/api/products");

const products = await response.json();

Step 2 — HTTP request is created

Conceptually:

GET /api/products HTTP/1.1
Accept: application/json

Step 3 — Express receives the request

app.get("/api/products", async (req, res) => {

Step 4 — Backend communicates with MongoDB

const products = await Product.find();

Step 5 — Server sends the response

res.status(200).json(products);

Step 6 — React receives the data

const products = await response.json();

Step 7 — React displays the data

The UI can now render the products.

The complete flow:

React
  ↓
fetch()
  ↓
HTTP GET Request
  ↓
Express
  ↓
Route
  ↓
Business Logic
  ↓
MongoDB
  ↓
JSON Response
  ↓
React
  ↓
UI

23. HTTP is Stateless

One important property of HTTP is that it is stateless.

Stateless means that each request is treated independently.

For example:

Request 1:
GET /api/products

Request 2:
GET /api/products/10

The second request does not automatically remember everything about the first request.

If an application needs to maintain information about a user between requests, it can use mechanisms such as:

Cookies
Sessions
Tokens
JWT
Server-side storage

This becomes important when implementing authentication.

We will explore authentication and JWT in later parts of this series.

24. HTTP vs HTTPS

You have probably seen URLs like:

http://example.com

and:

https://example.com

HTTPS is HTTP protected using TLS.

With HTTPS, communication between the client and server is encrypted.

Conceptually:

HTTP

Client
  ↓
Request
  ↓
Server

With HTTPS:

Client
  ↓
Encrypted communication
  ↓
Server

HTTPS is important when sending sensitive information such as:

Passwords
Authentication tokens
Personal information
Payment-related information

We already discussed TLS at a high level in Part 1.

25. How Developers Debug HTTP Requests

When building frontend and backend applications, the browser's Network tab is one of the most useful debugging tools.

Open:

Browser
   ↓
Developer Tools
   ↓
Network

Then make an API request.

You can inspect:

Request URL
Request Method
Status Code
Request Headers
Request Payload
Response Headers
Response Body

For example:

Request URL:
http://localhost:3000/api/products

Request Method:
GET

Status Code:
200 OK

You can also inspect the JSON response.

This is extremely useful when debugging API problems.

26. Common HTTP Problems

404 Not Found

You may have requested the wrong endpoint.

For example, your backend has:

/api/products

but your frontend requests:

/api/product

The server may return:

404 Not Found

400 Bad Request

The request data may be invalid.

For example:

{
    "price": "hello"
}

when the server expects a number.

401 Unauthorized

The request requires authentication, but valid authentication credentials were not provided.

403 Forbidden

The user is authenticated but does not have permission to access the resource.

500 Internal Server Error

Something went wrong while processing the request on the server.

When this happens, check your backend logs.

27. A Simple Mental Model for HTTP

If you're learning backend development, remember this:

               HTTP REQUEST
                     |
      +---------+----+----+---------+
      |         |         |         |
      v         v         v         v
   Method      URL     Headers    Body
      |         |         |         |
      +---------+----+----+---------+
                     |
                     v
                  SERVER
                     |
                     v
               HTTP RESPONSE
                     |
         +-----------+-----------+
         |           |           |
         v           v           v
    Status Code   Headers      Body

For example:

POST /api/products
Content-Type: application/json

{
    "name": "Keyboard",
    "price": 2000
}

The server processes the request and might return:

HTTP/1.1 201 Created
Content-Type: application/json

{
    "message": "Product created successfully"
}

That's the basic request-response cycle.

28. A Small REST API Example

Let's combine what we have learned into a simple Express API.

const express = require("express");

const app = express();

app.use(express.json());

const products = [
    {
        id: 1,
        name: "Keyboard",
        price: 2000
    },
    {
        id: 2,
        name: "Mouse",
        price: 1000
    }
];

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

// GET one product
app.get("/api/products/:id", (req, res) => {
    const id = Number(req.params.id);

    const product = products.find((item) => item.id === id);

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

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

// Create product
app.post("/api/products", (req, res) => {
    const product = {
        id: products.length + 1,
        name: req.body.name,
        price: req.body.price
    };

    products.push(product);

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

// Delete product
app.delete("/api/products/:id", (req, res) => {
    const id = Number(req.params.id);

    const index = products.findIndex((item) => item.id === id);

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

    products.splice(index, 1);

    res.status(200).json({
        message: "Product deleted successfully"
    });
});

app.listen(3000, () => {
    console.log("Server running on port 3000");
});

This small API demonstrates:

GET
POST
DELETE
URL parameters
Request body
Status codes
JSON responses
Express routes

29. The Big Picture

Let's put everything together.

When you click a button in a web application, something like this can happen:

                  USER
                    |
                    v
                REACT UI
                    |
                    v
                 fetch()
                    |
                    v
              HTTP REQUEST
                    |
        +-----------+-----------+
        |           |           |
        v           v           v
     Method      Headers      Body
        |           |           |
        v           v           v
      POST    Content-Type      |
              Authorization     |
        |           |           |
        +-----------+-----------+
                    |
                    v
             EXPRESS SERVER
                    |
                    v
                  ROUTE
                    |
                    v
             BUSINESS LOGIC
                    |
                    v
                 MONGODB
                    |
                    v
             SERVER RESPONSE
                    |
                    v
              HTTP RESPONSE
                    |
                    v
                  REACT
                    |
                    v
                UI UPDATE

This is the basic communication cycle behind many modern web applications.

30. What You Should Remember

You don't need to memorize every part of the HTTP specification.

Start with these concepts:

HTTP
 ↓
Request / Response
 ↓
HTTP Methods
 ↓
Headers
 ↓
Request Body
 ↓
Query Parameters
 ↓
URL Parameters
 ↓
Status Codes
 ↓
JSON
 ↓
REST APIs
 ↓
Express

For example:

GET /api/products?page=2

means:

GET → retrieve data
/api/products → endpoint
page=2 → query parameter

And:

POST /api/products
Content-Type: application/json

{
    "name": "Keyboard",
    "price": 2000
}

means:

POST → send data, commonly to create a resource
/api/products → endpoint
Content-Type → request contains JSON
Request body → product data

Conclusion

HTTP is one of the fundamental building blocks of web development.

Every time your frontend communicates with your backend, HTTP is usually involved.

Once you understand:

Request
   ↓
Method
   ↓
URL
   ↓
Headers
   ↓
Body
   ↓
Server
   ↓
Response
   ↓
Status Code
   ↓
Response Body

APIs become much easier to understand and debug.

In a MERN application, the flow can look like:

React
   ↓
HTTP Request
   ↓
Node.js + Express
   ↓
Business Logic
   ↓
MongoDB
   ↓
HTTP Response
   ↓
React

Understanding this flow gives you a strong foundation for backend development.

Final Takeaway

HTTP may look simple from the outside:

Request → Response

But inside a real application, that request passes through multiple layers:

Frontend
   ↓
HTTP
   ↓
Express
   ↓
Business Logic
   ↓
Database
   ↓
HTTP
   ↓
Frontend

Once you understand this flow, you're not just using APIs anymore — you understand what is happening behind them.

References

If you want to go deeper into HTTP and web development, these are useful references:

HTTP Semantics — RFC 9110
HTTP — MDN Web Docs
HTTP request methods — MDN Web Docs
HTTP response status codes — MDN Web Docs
Fetch API — MDN Web Docs

What Happens When You Enter a URL?

Aryan Gupta — Thu, 01 Oct 2026 06:36:12 +0000

Have you ever wondered what happens after you type a URL into your browser and press Enter?

For example:

https://example.com

A webpage appears within a few seconds, but a lot happens behind the scenes before you see it.

In a simplified form, the process looks like this:

URL
 ↓
DNS Lookup
 ↓
TCP Connection
 ↓
TLS Handshake
 ↓
HTTP Request
 ↓
Web Server
 ↓
HTTP Response
 ↓
Browser Processes Response
 ↓
Page Rendered

Let's understand each step in simple terms.

1. The Browser Reads the URL

First, the browser breaks the URL into different parts.

Consider:

https://example.com/products?id=10

It contains:

https://              → Protocol
example.com           → Domain
/products             → Path
?id=10                → Query parameter

The protocol tells the browser how it should communicate with the server.

For HTTPS, the default port is:

For HTTP, the default port is:

So when you type:

https://example.com

the browser knows that it needs to communicate securely with the server using HTTPS.

2. DNS Finds the Server

Computers communicate using IP addresses.

Humans, however, prefer names like:

example.com

instead of:

93.184.216.34

This is where DNS (Domain Name System) comes in.

DNS translates a domain name into an IP address.

A simplified flow looks like:

example.com
     ↓
DNS
     ↓
IP Address

You can actually perform a DNS lookup from your terminal.

Windows

nslookup example.com

Linux / macOS

dig example.com

The result contains information about the domain's DNS records, including its IP address.

The browser can then use that IP address to communicate with the destination server.

3. DNS Isn't Always Requested From Scratch

One important detail is that the browser doesn't necessarily perform a complete DNS lookup every time.

DNS information can be cached at different levels:

Browser Cache
      ↓
Operating System Cache
      ↓
DNS Resolver Cache
      ↓
DNS Servers

If a valid cached result already exists, the browser may use it instead of performing another lookup.

This caching helps reduce latency and unnecessary DNS traffic.

4. A Connection Is Established

Once the browser knows the server's IP address, it needs to establish a connection.

For traditional HTTPS over TCP, this starts with the TCP three-way handshake.

It looks like this:

Client                         Server

   SYN  ------------------------>

        <------------------------ SYN + ACK

   ACK  ------------------------>

Step 1: SYN

The client sends a SYN packet to start a connection.

Step 2: SYN-ACK

The server responds with SYN-ACK.

Step 3: ACK

The client sends an ACK.

The TCP connection is now established.

Modern HTTP/3 uses QUIC over UDP instead of TCP, so not every HTTPS connection follows this exact TCP flow.

5. HTTPS Establishes Secure Communication

Because we're using:

https://

the connection needs encryption.

This is handled by TLS (Transport Layer Security).

The browser and server perform a TLS handshake to establish secure communication.

A simplified version looks like:

Browser                         Server

ClientHello  ------------------>

             <------------------ ServerHello
             <------------------ Certificate

Certificate verification

Key exchange  ------------------>

Encrypted communication begins

The browser verifies the server's certificate and establishes cryptographic keys for the connection.

After this point, the HTTP data can be exchanged securely.

This is one of the main differences between:

HTTP

and:

HTTPS

HTTPS protects the communication between the client and server using TLS.

6. The Browser Sends an HTTP Request

Now the browser can send the actual request.

For example:

GET /products HTTP/1.1
Host: example.com
Accept: text/html

The request tells the server what the browser wants.

An HTTP request generally contains:

Request Method
URL / Path
Headers
Optional Body

Common HTTP methods include:

GET     → Read data
POST    → Create data
PUT     → Replace/update data
PATCH   → Partially update data
DELETE  → Delete data

For example:

GET /products

means:

Give me the products resource.

7. The Request Reaches the Server

The request doesn't necessarily go directly from the browser to your application.

A production application can have several layers:

Browser
   ↓
Internet
   ↓
CDN / Load Balancer
   ↓
Web Server / Reverse Proxy
   ↓
Backend Application
   ↓
Database

For a simple MERN application, you might have:

React
  ↓
Node.js + Express
  ↓
MongoDB

The backend receives the request and decides what should happen next.

8. Express Handles the Request

Suppose our frontend sends:

GET /api/products

An Express server could handle it like this:

const express = require("express");

const app = express();

app.get("/api/products", (req, res) => {
    const products = [
        {
            id: 1,
            name: "Laptop",
            price: 60000
        },
        {
            id: 2,
            name: "Keyboard",
            price: 2000
        }
    ];

    res.json(products);
});

app.listen(3000, () => {
    console.log("Server running on port 3000");
});

When the browser sends:

GET /api/products

Express matches the route:

app.get("/api/products", ...)

and executes the function.

The server then sends the products back as JSON.

9. The Backend May Talk to a Database

In a real application, we usually don't hardcode the data.

The backend may query a database.

For example, using Mongoose:

app.get("/api/products", async (req, res) => {
    try {
        const products = await Product.find();

        res.json(products);
    } catch (error) {
        res.status(500).json({
            message: "Something went wrong"
        });
    }
});

Now the flow becomes:

Browser
   ↓
HTTP Request
   ↓
Express
   ↓
Route
   ↓
MongoDB
   ↓
Data
   ↓
Express
   ↓
HTTP Response

This is the basic request-response cycle you'll use frequently as a MERN developer.

10. The Server Sends an HTTP Response

After processing the request, the server sends a response.

For example:

HTTP/1.1 200 OK
Content-Type: application/json

The response body could be:

[
    {
        "id": 1,
        "name": "Laptop",
        "price": 60000
    },
    {
        "id": 2,
        "name": "Keyboard",
        "price": 2000
    }
]

The status code tells the client what happened.

Some commonly used status codes are:

Status Code	Meaning
200	Request successful
201	Resource created
400	Bad request
401	Authentication required
403	Access forbidden
404	Resource not found
500	Server error

For example:

res.status(404).json({
    message: "Product not found"
});

sends a 404 Not Found response.

11. The Browser Processes the Response

If the browser requested an HTML document, it starts parsing the HTML.

For example:

<!DOCTYPE html>
<html>
<head>
    <title>My Website</title>
</head>

<body>
    <h1>Hello World</h1>
    <p>Welcome to my website.</p>
</body>
</html>

The browser parses this HTML and creates a DOM (Document Object Model).

Conceptually:

HTML
 ↓
DOM

The DOM represents the structure of the webpage.

For example:

Document
   |
  html
   |
  body
 /    \
h1     p

JavaScript can then interact with this DOM.

12. The Browser Loads CSS

The HTML might contain:

<link rel="stylesheet" href="/style.css">

The browser makes another request for:

/style.css

The server might return:

body {
    font-family: Arial, sans-serif;
}

h1 {
    font-size: 32px;
}

p {
    line-height: 1.6;
}

The browser uses this CSS to determine how the HTML elements should look.

13. JavaScript Is Downloaded and Executed

The webpage can also contain JavaScript.

For example:

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

The browser downloads the JavaScript file and executes it.

For example:

const button = document.querySelector("#button");

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

JavaScript can:

Modify the DOM
Handle user interactions
Send API requests
Update application state
Perform calculations
Change the UI

This is where modern frontend frameworks such as React become useful.

14. What Changes in a React Application?

In a React application, the browser loads the application JavaScript and React takes responsibility for building the user interface.

A simplified flow looks like:

Browser
   ↓
HTML
   ↓
JavaScript
   ↓
React
   ↓
API Request
   ↓
Express Backend
   ↓
Database

For example, a React component might request data:

import { useEffect, useState } from "react";

function Products() {
    const [products, setProducts] = useState([]);

    useEffect(() => {
        fetch("/api/products")
            .then(response => response.json())
            .then(data => setProducts(data));
    }, []);

    return (
        <div>
            {products.map(product => (
                <p key={product.id}>
                    {product.name} - ₹{product.price}
                </p>
            ))}
        </div>
    );
}

export default Products;

Here, another HTTP request is made from the browser to:

/api/products

The backend returns JSON, and React uses that data to update the UI.

15. The Browser Renders the Page

Once the browser has the required HTML and CSS, it needs to turn them into pixels on your screen.

A simplified rendering process is:

HTML
 ↓
DOM
 ↓
CSS
 ↓
CSSOM
 ↓
Render Tree
 ↓
Layout
 ↓
Paint
 ↓
Composite
 ↓
Screen

Layout

The browser calculates where elements should appear and how much space they need.

Paint

It draws things such as:

Text
Colors
Borders
Images
Shadows

Composite

The browser combines the different visual layers and displays the final result.

16. One URL Can Trigger Many Requests

This is an important thing to understand.

You may type only:

https://example.com

but loading that page may require many requests:

index.html
     ↓
style.css
     ↓
app.js
     ↓
images
     ↓
fonts
     ↓
API requests

For a modern web application, the browser may continue making requests even after the initial HTML has loaded.

You can see these requests yourself.

Open Browser DevTools

In Chrome or another Chromium-based browser:

Right Click
    ↓
Inspect
    ↓
Network

Then reload the page.

You'll see requests for things such as:

HTML
CSS
JavaScript
Images
Fonts
API calls

This is one of the best ways to understand what your browser is actually doing.

17. You Can See the Process Yourself

Open DevTools and go to the Network tab.

When you reload a website, you'll see information such as:

Name
Status
Type
Size
Time

For an API request, you may see:

GET /api/products
Status: 200
Type: fetch

You can click the request and inspect:

Headers
Payload
Preview
Response
Timing

This is extremely useful when debugging frontend and backend applications.

18. What If Something Goes Wrong?

Understanding the request flow makes debugging easier.

DNS problem

The domain cannot be resolved.

Domain
  ↓
DNS
  X
IP address not resolved

404 Error

The server was reached, but the requested resource doesn't exist.

GET /products/100
        ↓
       404

500 Error

The request reached the backend, but the server encountered an error while processing it.

Network Error

The browser may not be able to communicate with the server because of a network, connection, server, or configuration issue.

CORS Error

The browser can block a cross-origin request when the server does not allow that origin through its CORS configuration.

For example:

Frontend
http://localhost:5173

        ↓

Backend
http://localhost:5000

These are different origins, so the backend may need appropriate CORS configuration.

The Complete Flow

Now let's put everything together.

When you enter:

https://example.com

a simplified version of what happens is:

             URL
              ↓
        Browser parses URL
              ↓
          DNS lookup
              ↓
          IP address
              ↓
     Connection established
              ↓
        TLS handshake
              ↓
       HTTP request sent
              ↓
          Web server
              ↓
      Backend application
              ↓
       Database / Services
              ↓
        HTTP response
              ↓
        Browser receives it
              ↓
       HTML / CSS / JS
              ↓
        Browser rendering
              ↓
          Web page

And that's the journey from typing a URL to seeing a webpage.

Why Should a Web Developer Understand This?

You don't need to become a networking expert to build websites.

But understanding this flow gives you a much better mental model of web development.

When an API isn't working, you can ask:

Did the request leave the browser?
        ↓
Did DNS resolve correctly?
        ↓
Did the server receive the request?
        ↓
Did the Express route match?
        ↓
Did the database query work?
        ↓
What status code did the server return?
        ↓
Did the browser receive the response?

Instead of randomly changing code, you can debug the problem step by step.

That's the real value of understanding what happens behind a URL.

Final Takeaway

Typing a URL looks like one simple action, but it starts a chain of operations involving:

DNS
Networking
TCP or QUIC
TLS
HTTP
Web servers
Backend applications
Databases
HTML
CSS
JavaScript
Browser rendering

As a developer, you don't need to memorize every detail.

The important thing is to understand how these pieces connect.

Once you have that mental model, concepts like APIs, authentication, React, Node.js, Express, databases, and browser DevTools become much easier to understand.

And the next time you press Enter after typing a URL, you'll know there's a lot more happening than just "opening a website."

DEV Community: Aryan Gupta

How MongoDB Finds Your Data

1. Where MongoDB Fits in Our Application

2. What Is a MongoDB Document?

3. What Happens When We Run findOne()?

4. What Is a Query?

5. The Query Planner

6. What Is a Collection Scan?

7. Enter Indexes

8. Creating an Index

9. Why Don't We Index Everything?

10. What Happens When MongoDB Uses an Index?

11. How Do We Know If MongoDB Used the Index?

12. COLLSCAN vs IXSCAN

COLLSCAN

IXSCAN

13. A Simple Experiment

14. totalDocsExamined vs nReturned

15. What Is a Compound Index?

16. MongoDB Doesn't Just "Search the Database"

17. Where Does Mongoose Fit?

18. What Happens During a Real API Request?

19. Why _id Is Special

20. What About Sorting?

21. Indexes Are Not Magic

22. What Happens When Data Changes?

23. A Practical Backend Example

24. How to Think About Database Performance

25. Common Mistakes

❌ Creating an index on every field

❌ Assuming an index is always used

❌ Ignoring query patterns

❌ Thinking MongoDB simply searches every document

❌ Adding indexes without measuring

26. The Mental Model

27. The Bigger Picture

28. Conclusion

References

How Express Middleware Works

1. What Is Express?

2. What Is Middleware?

req

res

next

3. The Middleware Chain

4. Why Do We Need next()?

5. Middleware Can End the Request

6. Middleware Can Modify the Request

7. A Real Authentication Example

8. Types of Middleware

Application-level middleware

Router-level middleware

Built-in middleware

Error-handling middleware

9. How Express Knows the Order

10. Middleware as a Pipeline

11. What Happens If Middleware Sends a Response?

12. Why return Is Often Used

13. Error Handling in Middleware

14. next() vs next(error)

next()

next(error)

15. Middleware Can Be Reused

16. A Complete Example

17. What Happens Under the Hood?

18. Common Mistakes

❌ Forgetting next()

❌ Sending a response and continuing

❌ Putting middleware in the wrong order

❌ Putting all logic into middleware

19. The Mental Model

20. Conclusion

References

How Node.js Handles Requests

1. What is Node.js?

2. What Happens When a Request Arrives?

3. Is Node.js Single-Threaded?

4. What is the Event Loop?

5. Blocking vs Non-Blocking Code

Blocking

3. What Happens When We Run `findOne()`?

12. `COLLSCAN` vs `IXSCAN`

`COLLSCAN`

`IXSCAN`

14. `totalDocsExamined` vs `nReturned`

19. Why `_id` Is Special

`req`

`res`

`next`

4. Why Do We Need `next()`?

12. Why `return` Is Often Used

14. `next()` vs `next(error)`

`next()`

`next(error)`

❌ Forgetting `next()`

11. What Does `await` Actually Mean?

❌ "`await` blocks the entire server."