DEV Community: Shivam Yadav

The Node.js Event Loop Explained

Shivam Yadav — Sun, 10 May 2026 15:35:25 +0000

The Node.js Event Loop Explained

If you spend even 15 minutes learning Node.js, eventually someone says:

“Everything works because of the event loop.”

And suddenly beginners are expected to understand:

asynchronous execution
task queues
call stacks
callbacks
timers
I/O operations

all at once.

Which usually results in:

brain buffering indefinitely.

The funny part?

The event loop is actually based on a very simple idea.

It is basically:

a smart task manager.

That’s it.

In this article, we will understand:

what the event loop is
why Node.js needs it
call stack vs task queue
how async operations work
timers vs I/O callbacks
why the event loop makes Node.js scalable

And we will keep things conceptual and beginner-friendly instead of diving into terrifying internal phases immediately.

Because surviving the basics matters first.

First Understand the Main Problem

Node.js is:

single-threaded

Meaning:
JavaScript mainly runs on:

one main thread

Now logically this sounds dangerous.

Because if one thread handles:

requests
file reading
database calls
timers
APIs

then shouldn’t everything freeze constantly?

That would be true…

if Node.js executed everything synchronously.

But Node.js uses:

asynchronous execution

And the event loop is what manages that system.

Real-Life Restaurant Analogy

Imagine a restaurant with:

one super-efficient manager

Customers continuously place orders.

Now if manager personally:

cooks food
waits for oven
washes dishes
handles billing

restaurant collapses instantly.

Instead manager:

delegates slow work
keeps taking new orders
handles completed tasks later

This manager is basically:

the event loop

What Is the Event Loop?

The event loop is:

a mechanism that continuously checks and executes tasks.

Its main job is:

```text id="a81ks2"
"Is there any task ready to run?"




If yes:

* execute it

If no:

* continue checking

Simple idea.
Massive impact.

---

# Why Node.js Needs an Event Loop

Without event loop,
Node.js would behave like traditional blocking systems.

Example:



```text id="b72ms1"
Read File
↓
WAIT
↓
Continue

During waiting:
everything stops.

Bad for servers.

Very bad.

The event loop allows Node.js to:

avoid unnecessary waiting
continue handling requests
process async tasks later

That is why Node.js scales efficiently.

First Understand the Call Stack

The call stack is:

where JavaScript executes functions.

Think of it like:

current work desk.

Whenever function runs,
it goes onto stack.

Example:

```js id="c63ps2"
function one() {
console.log("One");
}

function two() {
console.log("Two");
}

one();
two();




Execution flow:



```text id="d54jd1"
one()
↓
print "One"
↓
remove one()

two()
↓
print "Two"
↓
remove two()

Functions enter and leave stack one by one.

Call Stack Is Synchronous

Important rule:

Call stack executes one thing at a time.

That is why JavaScript is called:

single-threaded

Now Comes the Problem

What happens if task takes long time?

Example:

```js id="e45ks2"
setTimeout(() => {
console.log("Done");
}, 2000);

console.log("Hello");




Question:
Why does `"Hello"` print first?

Because async tasks do not stay blocking inside call stack.

That is where event loop enters.

---

# Understanding Async Operations

Operations like:

* timers
* file reads
* database calls
* API requests

are handled outside main execution flow.

Node.js delegates them to:

* browser APIs (in browsers)
* libuv/OS system (in Node.js)

Meanwhile:
call stack continues executing other code.

---

# Event Loop Core Flow



```text id="f36ms1"
Call Stack Executes Code
         ↓
Async Task Starts
         ↓
Task Delegated
         ↓
Call Stack Continues
         ↓
Task Completes
         ↓
Callback Added to Queue
         ↓
Event Loop Pushes Callback to Stack
         ↓
Callback Executes

This is the heart of async JavaScript.

Understanding Task Queue

Task queue stores:

completed async callbacks waiting to execute

Think of it like:

waiting room.

Callbacks wait there until:

call stack becomes empty

Only then:
event loop moves them into stack.

Simple Visualization

```text id="g27ps2"
CALL STACK
↓
EVENT LOOP
↓
TASK QUEUE




Event loop constantly checks:



```text id="h18ks1"
"Is stack empty?"

If yes:
move callback from queue to stack.

Example Step-by-Step

Code:

```js id="i09jd2"
console.log("Start");

setTimeout(() => {
console.log("Timer Done");
}, 2000);

console.log("End");




---

# Step 1



```text id="j90ms2"
console.log("Start")

Output:

```text id="k81ps1"
Start




---

# Step 2

`setTimeout()` starts timer.

Timer handled separately.

Callback waits.

---

# Step 3



```text id="l72ks2"
console.log("End")

Output:

```text id="m63ms1"
End




---

# Step 4

After 2 seconds:
callback enters task queue.

---

# Step 5

Event loop checks:

* stack empty?

Yes.

Moves callback to stack.

---

# Final Output



```text id="n54ps2"
Start
End
Timer Done

This is event loop behavior.

Queue Analogy

Imagine food court token system.

Customers wait in queue.

Manager only calls next customer when:

counter becomes free

Similarly:
callbacks wait until:

call stack becomes empty

Timers vs I/O Callbacks

Node.js handles different async operations.

Examples:

timers
file operations
database calls

Timer Example

```js id="o45ks1"
setTimeout(() => {

}, 1000);




Executes after delay.

---

# I/O Callback Example



```js id="p36jd1"
fs.readFile("data.txt", () => {

});

Executes after file reading finishes.

Both use async behavior,
but internally they originate differently.

For beginners,
important understanding is:

async tasks complete later and return via queue system.

Why Event Loop Makes Node.js Scalable

This is the most important real-world point.

Traditional blocking systems may:

waste threads waiting

Node.js avoids that.

Instead:

async operations happen separately
event loop keeps server responsive

Meaning:
one thread can manage many users efficiently.

Traditional Blocking Server

```text id="q27ms2"
User 1 → Processing
User 2 → Waiting
User 3 → Waiting




---

# Node.js Event Loop Model



```text id="r18ps1"
User 1 → Async Task Started
User 2 → Processing
User 3 → Processing
User 4 → Processing

Huge difference in scalability.

Event Loop as Task Manager

Best beginner mental model:

The event loop is:

a smart manager coordinating tasks.

It:

checks stack
checks queue
schedules callbacks
keeps system moving

Without it,
Node.js async behavior would not exist.

Important Truth About the Event Loop

The event loop itself does not magically make code faster.

It makes Node.js efficient by:

reducing idle waiting
enabling concurrency
managing async execution smartly

That distinction matters.

Common Beginner Confusions

“setTimeout Executes Exactly On Time”

No.

Minimum delay only.

If stack busy,
callback waits longer.

Async Means Parallelism?

Not exactly.

Node.js mainly focuses on:

concurrency

not true multi-core parallelism.

Event Loop Executes Multiple Things Simultaneously?

No.

Call stack still executes:

one task at a time

Event loop simply manages scheduling.

What Happens If Stack Never Clears?

Example:

```js id="s09ks2"
while(true){

}




Event loop cannot process queue.

Everything freezes.

Because call stack never becomes empty.

---

# Visual Event Loop Cycle



```text id="t90jd1"
Execute Stack
      ↓
Check Queue
      ↓
Move Ready Callback
      ↓
Execute Callback
      ↓
Repeat Forever

This loop continuously runs during application lifetime.

Real-World Example

Imagine social media app.

Users continuously:

send messages
fetch posts
upload content
receive notifications

Most tasks involve:

waiting for network
database operations
async events

Event loop helps Node.js handle all this efficiently without blocking everything.

Quick Revision

Event Loop Is:

task manager
async execution coordinator

Call Stack:

executes functions
synchronous
one task at a time

Task Queue:

stores completed async callbacks

Event Loop Checks:

```text id="u81ms2"
Is call stack empty?




---

## Async Operations Include:

* timers
* file reads
* database calls
* API requests

---

# Final Thoughts

The Node.js event loop sounds complicated mostly because of the terminology around it.

But the core idea is actually simple:

> JavaScript executes one thing at a time, while the event loop smartly manages asynchronous tasks around it.

That system allows Node.js to:

* stay responsive
* avoid blocking
* handle many users efficiently

And honestly,
once the event loop finally clicks in your brain,
a huge portion of Node.js suddenly starts making sense together.

Blocking vs Non-Blocking Code in Node.js

Shivam Yadav — Sun, 10 May 2026 15:33:45 +0000

Blocking vs Non-Blocking Code in Node.js

One of the biggest reasons Node.js became popular is this phrase:

“Node.js is non-blocking.”

And beginners usually react with:

“Okay… sounds important.”
“But what exactly is being blocked?”

Fair question.

Because terms like:

blocking
non-blocking
asynchronous
event loop

often get explained in ways that sound more confusing than helpful.

So in this article, we will understand:

what blocking code actually means
what non-blocking code means
why blocking hurts server performance
how Node.js handles async operations
real-world examples using file handling and database calls

And yes, we are going to use real-life analogies because software concepts become much easier once humans stop explaining them like robot manuals.

First Understand: What Does “Blocking” Mean?

Blocking simply means:

“Execution has to wait.”

The program cannot continue until current task finishes.

Imagine standing in line at a small shop.

Shopkeeper serves:

one customer fully
then next customer
then next customer

Everyone behind must wait.

That is blocking behavior.

Simple Blocking Example

Imagine this code:

```js id="a82ks1"
console.log("Start");

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

}

console.log("End");




What happens?



```text id="b73ms2"
Start
(wait...)
(wait...)
End

Program gets stuck in loop before continuing.

Because JavaScript executes code line by line.

The heavy loop blocks execution.

Why Blocking Is Dangerous in Servers

Now imagine this happening in a server.

One request arrives.

Server blocks while processing it.

Meanwhile:

other users wait
requests pile up
performance drops

Suddenly your backend behaves like:

a government office before lunch break.

Real-Life Restaurant Analogy

Imagine restaurant with one chef.

Customer 1 orders pasta.

Chef does this:

```text id="c64ps1"
Start Cooking
↓
Stand and stare at boiling pasta
↓
Ignore all other customers
↓
Finish pasta
↓
Take next order




Terrible system.

Other customers suffer unnecessarily.

This is blocking behavior.

---

# What Is Non-Blocking Code?

Non-blocking means:

# “Start task and continue doing other work.”

Instead of waiting,
program moves forward and returns later when task finishes.

---

# Non-Blocking Restaurant Version

Smart chef does this:



```text id="d55jd1"
Start Pasta
↓
While pasta cooks → take more orders
↓
Serve completed dishes later

One chef.
Many customers.
Efficient workflow.

That is Node.js philosophy.

Why Node.js Loves Non-Blocking Operations

Modern applications spend huge amounts of time:

waiting for database
waiting for files
waiting for APIs
waiting for network

Node.js says:

“Why waste entire thread waiting?”

Instead:

delegate slow tasks
continue execution
process callback later

This makes Node.js highly efficient.

Blocking File Read Example

Node.js has synchronous functions.

Example:

```js id="e46ks2"
const fs = require("fs");

console.log("Start");

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

console.log(data);

console.log("End");




---

# What Happens Here?

Flow:



```text id="f37ms1"
Start
↓
Read File
↓
WAIT
↓
File Loaded
↓
Print Data
↓
End

Execution stops completely while file loads.

This is:

blocking code

Because:
readFileSync() blocks thread.

Non-Blocking File Read Example

Now async version:

```js id="g28ps2"
const fs = require("fs");

console.log("Start");

fs.readFile("data.txt", "utf8", (err, data) => {

console.log(data);

});

console.log("End");




Output:



```text id="h19ks1"
Start
End
[file content]

Interesting difference.

Why Did “End” Print First?

Because:

file reading started
Node.js did not wait
execution continued immediately
callback executed later

This is:

non-blocking behavior

Blocking vs Non-Blocking Timeline

Blocking Execution Timeline

```text id="i00jd2"
Start
↓
Read File
↓
WAIT...
↓
Continue
↓
End




---

# Non-Blocking Execution Timeline



```text id="j91ms2"
Start
 ↓
Start File Read
 ↓
Continue Execution
 ↓
End
 ↓
File Finished
 ↓
Callback Runs

Huge difference in performance behavior.

Understanding Async Operations

Non-blocking operations are usually:

asynchronous

Meaning:
they complete later.

Examples:

file reading
database calls
API requests
timers
network operations

These tasks take time.

Node.js handles them asynchronously.

Async Does NOT Mean Parallel Magic

Important clarification.

Beginners often think:

“Async means everything happens simultaneously.”

Not exactly.

Node.js mainly uses:

concurrency

not heavy parallelism.

Concurrency vs Parallelism

Parallelism

Doing multiple tasks literally at same time.

Example:

4 chefs cooking 4 dishes simultaneously

Concurrency

Managing many tasks efficiently without unnecessary waiting.

Example:

one chef handling multiple orders smartly

Node.js focuses heavily on:

concurrency

Event Loop Role

The event loop is what makes non-blocking behavior possible.

Flow:

```text id="k82ps1"
Task Starts
↓
Background Worker Handles It
↓
Event Loop Continues Running
↓
Task Finishes
↓
Callback Added to Queue
↓
Event Loop Executes Callback




This architecture is core Node.js behavior.

---

# Real-World Database Example

Imagine login request.

Server must:

* query database
* verify user

Database operations are slow compared to CPU speed.

Blocking version would freeze server while waiting.

Non-blocking version:

* sends DB query
* continues handling other requests
* processes result later

This is why Node.js scales well.

---

# Example Database Analogy

Bad waiter:



```text id="l73ks2"
Take Order
↓
Go to kitchen
↓
Stand there silently until food ready
↓
Return

Good waiter:

```text id="m64ps1"
Take Order
↓
Give order to kitchen
↓
Handle other tables
↓
Return when food ready




Node.js behaves like second waiter.

---

# Why Blocking Slows Servers

Node.js uses:

# single main thread

Meaning:
if blocking task occurs,
entire server responsiveness suffers.

Example:

* one heavy synchronous operation
* all users affected

That is dangerous in production systems.

---

# Example of Dangerous Blocking



```js id="n55jd2"
while(true){

}

This infinite loop blocks event loop completely.

Result:

server freezes
requests stop responding

Backend officially enters emotional collapse.

Common Blocking Mistakes Beginners Make

Using Sync File Methods Everywhere

Bad for servers:

```js id="o46ks2"
fs.readFileSync()




Better:



```js id="p37ms1"
fs.readFile()

Heavy CPU Loops

Large calculations block event loop.

Blocking Inside Request Handlers

Very dangerous because:
every incoming request gets delayed.

When Blocking Code Is Actually Fine

Now important honesty section.

Blocking code is not always evil.

Sometimes sync code is acceptable:

startup scripts
command line tools
tiny local scripts

Problem starts when:
blocking happens in active server handling multiple users.

Why Non-Blocking Makes Node.js Fast

Because Node.js avoids wasting time.

Instead of:

sitting idle
waiting for slow operations

it continues handling requests efficiently.

That efficiency is the reason Node.js became popular for:

APIs
chat apps
streaming
realtime systems

Real-World Apps That Benefit

Applications with lots of:

API requests
database queries
network communication

benefit heavily from non-blocking architecture.

Examples:

messaging apps
dashboards
live notifications
realtime tracking

Simple Mental Model

Blocking:

```text id="q28ps2"
Wait first → continue later




Non-blocking:



```text id="r19ks1"
Start task → continue immediately

That is the core difference.

Quick Revision

Blocking Code Means:

execution waits
thread gets occupied

Non-Blocking Code Means:

execution continues
task handled asynchronously

Blocking Hurts Servers Because:

requests wait
event loop freezes
responsiveness drops

Async Operations Include:

file reading
database calls
API requests

Node.js Uses:

event loop
non-blocking I/O
asynchronous execution

Final Thoughts

Blocking vs non-blocking is one of the most important Node.js concepts.

Because this behavior directly explains:

why Node.js feels fast
why it handles many users efficiently
why asynchronous programming matters

At first,
non-blocking execution feels strange because humans naturally think:

“Start task → wait until done.”

Node.js changed that idea completely.

Its philosophy is basically:

“Why stand idle while work is happening somewhere else?”

And honestly,
that is exactly why Node.js became so powerful for modern web applications.

REST API Design Made Simple with Express.js

Shivam Yadav — Sun, 10 May 2026 15:32:17 +0000

REST API Design Made Simple with Express.js

Every backend developer reaches a point where they hear this sentence:

“Build a REST API.”

And suddenly everyone starts pretending they fully understand:

REST
resources
endpoints
CRUD
status codes
HTTP methods

Meanwhile beginners are sitting there like:

“Brother I just learned app.get() yesterday.”

The good news?

REST APIs are actually based on very simple ideas.

Most of the scary terminology comes from people explaining it in the most robotic way possible.

So in this article, we are going to understand REST APIs properly using:

simple language
real-world examples
Express.js
one resource (users)
practical route design

By the end, REST APIs will stop looking like mysterious backend rituals.

First Understand: What Is an API?

API stands for:

Application Programming Interface

Sounds complicated.

But the real idea is simple.

An API allows:

two systems to communicate.

Real-Life API Analogy

Imagine a restaurant.

You:

place order to waiter

Waiter:

takes request to kitchen

Kitchen:

prepares food

Waiter:

brings response back

Here:

you = client
kitchen = server
waiter = API

The API acts as:

communication bridge between client and server.

What Is REST?

REST stands for:

Representational State Transfer

Yes.
That name sounds like it was invented by someone who hated beginners.

Thankfully:
you do not need to memorize the full form to understand REST.

REST is basically:

a standard way to design APIs.

It focuses on:

clean routes
proper HTTP methods
predictable structure

REST APIs Work Around Resources

This is the most important REST concept.

Resource = Anything your application manages

Examples:

users
products
orders
posts
comments

If your app stores or manages something,
it becomes a resource.

Example Resource: Users

We will use:

users

throughout this article.

Example user object:

```json id="a81ks2"
{
"id": 1,
"name": "Shivam",
"email": "shivam@gmail.com"
}




---

# REST API Structure Idea

REST focuses on:

* resources
* actions performed on resources

Instead of routes like:



```text id="b72ms1"
/getUsers
/createUser
/deleteUser

REST prefers:

```text id="c63ps2"
/users
/users/:id




Cleaner.
Predictable.
Industry standard.

---

# Understanding HTTP Methods

REST APIs mainly use:

* GET
* POST
* PUT
* DELETE

These methods define:

> what action should happen.

---

# CRUD Operations

REST APIs usually map to CRUD operations.

CRUD means:

| Operation | Meaning     |
| --------- | ----------- |
| Create    | Add data    |
| Read      | Fetch data  |
| Update    | Modify data |
| Delete    | Remove data |

---

# CRUD vs HTTP Methods

| CRUD   | HTTP Method |
| ------ | ----------- |
| Create | POST        |
| Read   | GET         |
| Update | PUT         |
| Delete | DELETE      |

This mapping is core REST design.

---

# Setting Up Express Server

First install Express:



```bash id="d54jd1"
npm install express

Now create:

```text id="e45ks2"
app.js




Basic setup:



```js id="f36ms1"
const express = require("express");

const app = express();

app.use(express.json());

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

Why `express.json()`?

It parses incoming JSON data.

Without it:
req.body becomes undefined.

And beginners spend 45 minutes questioning reality.

GET Method — Fetching Users

GET is used for:

reading data

Example route:

```js id="g27ps2"
app.get("/users", (req, res) => {

res.send("All Users");

});




When client requests:



```text id="h18ks1"
GET /users

server returns users.

Fetch Single User

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

res.send(`User ID: ${req.params.id}`);

});




Example request:



```text id="j90ms2"
GET /users/5

Response:

```text id="k81ps1"
User ID: 5




---

# Understanding Route Parameters



```js id="l72ks2"
:id

means:

dynamic value

Useful for:

user IDs
product IDs
order IDs

POST Method — Creating Data

POST is used for:

creating resources

Example:

```js id="m63ms1"
app.post("/users", (req, res) => {

const user = req.body;

res.send("User Created");

});




Request body example:



```json id="n54ps2"
{
    "name": "Shivam",
    "email": "shivam@gmail.com"
}

This creates new user.

PUT Method — Updating Data

PUT is used for:

updating existing resource

Example:

```js id="o45ks1"
app.put("/users/:id", (req, res) => {

res.send(`Updated User ${req.params.id}`);

});




Request:



```text id="p36jd1"
PUT /users/2

Meaning:
update user with ID 2.

DELETE Method — Removing Data

DELETE removes resource.

Example:

```js id="q27ms2"
app.delete("/users/:id", (req, res) => {

res.send(`Deleted User ${req.params.id}`);

});




Request:



```text id="r18ps1"
DELETE /users/2

REST Route Design Principles

Good REST APIs follow clean naming conventions.

Good Routes

```text id="s09ks2"
GET /users
GET /users/:id
POST /users
PUT /users/:id
DELETE /users/:id




---

# Bad Routes



```text id="t90jd1"
/getAllUsers
/createNewUser
/updateUserData
/deleteThisUser

REST prefers:

nouns
resources
clean structure

Not action-heavy route names.

Because HTTP methods already define action.

REST Request-Response Lifecycle

```text id="u81ms2"
Client Sends Request
↓
Express Route Matches
↓
Controller Logic Runs
↓
Response Sent Back




This cycle powers modern web applications.

---

# Status Codes Basics

Status codes tell client:

> what happened.

Very important in APIs.

---

# Common Status Codes

| Code | Meaning          |
| ---- | ---------------- |
| 200  | Success          |
| 201  | Resource Created |
| 400  | Bad Request      |
| 401  | Unauthorized     |
| 404  | Not Found        |
| 500  | Server Error     |

---

# Sending Status Codes

Example:



```js id="v72ps1"
res.status(200).send("Success");

Example: Resource Created

```js id="w63ks2"
res.status(201).send("User Created");




201 means:
new resource successfully created.

---

# Example: Not Found



```js id="x54ms1"
res.status(404).send("User Not Found");

Useful when requested data does not exist.

Why Status Codes Matter

Without status codes,
client cannot properly understand:

success
failure
permission issues
validation errors

They are basically:

backend communication signals.

Real-World REST API Example

Imagine building social media app.

Possible REST routes:

```text id="y45ps2"
GET /posts
POST /posts
GET /posts/:id
PUT /posts/:id
DELETE /posts/:id




Same REST principles everywhere.

---

# Full Example Together



```js id="z36ks1"
const express = require("express");

const app = express();

app.use(express.json());

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

app.get("/users/:id", (req, res) => {
    res.send(`User ${req.params.id}`);
});

app.post("/users", (req, res) => {
    res.status(201).send("User Created");
});

app.put("/users/:id", (req, res) => {
    res.send(`Updated User ${req.params.id}`);
});

app.delete("/users/:id", (req, res) => {
    res.send(`Deleted User ${req.params.id}`);
});

app.listen(3000);

Simple REST API structure.

Clean.
Readable.
Scalable.

Why REST Became Popular

REST APIs are:

simple
predictable
scalable
easy for frontend/backend communication

Almost every modern application:

mobile apps
web apps
dashboards
frontend frameworks

communicates using APIs.

And REST became one of the most common standards.

Common Beginner Mistakes

Using Verbs in Routes

Bad:

```text id="a25jd2"
/createUser




Good:



```text id="b16ms1"
/users

Forgetting HTTP Method Meaning

Using GET for deletion?

Backend police arriving soon.

Ignoring Status Codes

Always send meaningful responses.

Confusing PUT and POST

Remember:

Method	Purpose
POST	Create
PUT	Update

REST Is About Consistency

The biggest strength of REST APIs is:

predictability

When APIs follow proper conventions,
developers instantly understand:

routes
actions
behavior

Without reading entire backend code.

That consistency matters heavily in real-world systems.

Quick Revision

REST Means:

```text id="c07ps1"
Representational State Transfer




Standard API design approach.

---

## Resource Example:



```text id="d98ks2"
/users

HTTP Methods:

Method	Purpose
GET	Fetch
POST	Create
PUT	Update
DELETE	Remove

Common Status Codes:

Code	Meaning
200	Success
201	Created
404	Not Found

Final Thoughts

REST APIs look complicated only because of the terminology.

At its core,
REST is simply:

organizing communication between client and server properly.

Client asks for resource.
Server processes request.
Server returns response.

That’s the entire game.

Once you understand:

resources
routes
HTTP methods
status codes

backend development starts feeling far more structured and logical.

And honestly,
most modern applications are basically:

different systems sending requests to each other all day long.

Why Node.js is Perfect for Building Fast Web Applications

Shivam Yadav — Sun, 10 May 2026 15:30:27 +0000

Why Node.js is Perfect for Building Fast Web Applications

Every technology has that one sentence people repeat endlessly.

For Node.js, it is:

“Node.js is fast.”

Cool.

But beginners immediately ask:

“Fast compared to what?”
“Why is it fast?”
“What is actually happening internally?”

And then somebody explains it using:

event loops
threads
asynchronous execution
non-blocking I/O

At which point half the room mentally exits the conversation.

So let’s simplify everything properly.

In this article, we will understand:

what actually makes Node.js fast
how non-blocking I/O works
event-driven architecture
single-threaded model
concurrency vs parallelism
where Node.js performs best
companies using Node.js in production

And yes, we are absolutely using the restaurant analogy because Node.js education would collapse without it.

First Understand: Fast Does NOT Mean “Powerful Computer”

When people say:

“Node.js is fast”

they usually mean:

“Node.js handles many requests efficiently.”

Not:

magical CPU speed
superhero hardware
NASA-level processing power

Node.js wins because of:

smart request handling
non-blocking behavior
efficient concurrency

It wastes less time waiting.

And modern web applications spend a massive amount of time:

waiting.

Waiting for:

database
APIs
files
network
external services

Node.js handles that waiting extremely well.

The Traditional Server Problem

Imagine a normal blocking server.

User sends request.

Server starts processing it.

While processing:

everyone else waits.

Example:

```text id="a82ks1"
User 1 → Processing...
User 2 → Waiting
User 3 → Waiting
User 4 → Waiting




This becomes slow very quickly.

Especially when requests involve:

* database calls
* file reading
* API fetching

Because those operations take time.

---

# Real-Life Restaurant Analogy

Imagine a restaurant with one chef.

Customer 1 orders pasta.

Now imagine chef does this:



```text id="b73ms2"
Take Order
↓
Stand and watch pasta boil for 10 minutes
↓
Then take next order

Restaurant destroyed.
Business gone.
Chef arrested emotionally.

This is blocking behavior.

Node.js Does It Differently

Node.js chef works smarter.

Flow becomes:

```text id="c64ps1"
Take Order
↓
Start Cooking
↓
While food cooks → take more orders
↓
Serve completed dishes when ready




One chef.
Many customers.
Nobody feels ignored.

That is Node.js.

---

# What Makes Node.js Fast?

Main reasons:

* non-blocking I/O
* event-driven architecture
* efficient concurrency
* lightweight execution
* V8 engine performance

Let’s understand them one by one.

---

# Non-Blocking I/O Concept

This is the heart of Node.js.

---

# First Understand I/O

I/O means:

# Input / Output

Examples:

* reading files
* database queries
* API requests
* network operations

These operations are usually slow compared to CPU speed.

---

# Blocking I/O

Example:



```text id="d55jd1"
Read File
↓
Wait...
↓
Wait...
↓
Continue

During waiting:
server cannot handle other tasks efficiently.

Non-Blocking I/O

Node.js says:

```text id="e46ks2"
Start Task
↓
Don't Wait
↓
Handle Other Requests
↓
Come Back When Task Finishes




This is why Node.js handles traffic efficiently.

---

# Example in Code



```js id="f37ms1"
const fs = require("fs");

console.log("Start");

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

console.log("End");

Output:

```text id="g28ps2"
Start
End
[file content]




Why?

Because Node.js does not block execution while reading file.

Instead:

* file operation happens separately
* event loop continues running

---

# Event-Driven Architecture

Another major reason Node.js feels fast.

Node.js works using:

# events

Instead of waiting continuously,
Node.js listens for events.

Examples:

* request received
* file loaded
* timer completed
* database response returned

When event occurs:
callback executes.

---

# Simple Event Flow



```text id="h19ks1"
Request Arrives
      ↓
Event Registered
      ↓
Node.js Continues Working
      ↓
Task Completes
      ↓
Callback Executes

Efficient.
Lightweight.
Scalable.

The Event Loop: The Real Hero

The event loop is basically:

Node.js traffic manager.

It continuously checks:

```text id="i00jd2"
"Is any task ready?"




If yes:
execute callback.

If not:
keep moving.

The event loop never stops.

Unlike developers after debugging for 6 hours.

---

# Event Loop Visualization



```text id="j91ms2"
Incoming Requests
        ↓
Event Queue
        ↓
Event Loop
        ↓
Callback Execution
        ↓
Response Sent

This is the backbone of Node.js.

Single-Threaded Model Explanation

Now comes the confusing part.

Node.js is:

single-threaded

Beginners hear this and panic.

Because logically:

```text id="k82ps1"
One Thread = One Task?




No.

That is misunderstanding.

---

# Single Thread ≠ Single User

Node.js uses:

* one main thread
* asynchronous handling

Meaning:
one thread can manage many connections concurrently.

---

# Concurrency vs Parallelism

This is extremely important.

---

# Parallelism

Doing multiple tasks literally at same time.

Example:

* 4 chefs cooking 4 dishes simultaneously

---

# Concurrency

Managing multiple tasks efficiently without waiting unnecessarily.

Example:

* one chef managing many orders smartly

Node.js focuses on:

# concurrency

Not heavy parallel processing.

---

# Why This Makes Node.js Efficient

Traditional systems often create:

* one thread per request

More users:

* more threads
* more memory
* more CPU usage

Node.js avoids this overhead.

Instead:

* lightweight request handling
* async processing
* event-driven execution

Result:
better scalability for many applications.

---

# Where Node.js Performs Best

Node.js is excellent for:

* APIs
* realtime applications
* chat apps
* streaming
* notifications
* collaborative apps
* websocket systems

Basically:
applications with lots of I/O operations.

---

# Examples of Perfect Node.js Use Cases

---

# Chat Applications

Like:

* WhatsApp Web
* Discord-like systems

Need:

* constant connections
* realtime communication

Node.js handles this beautifully.

---

# Streaming Applications

Example:

* Netflix-like services

Streaming involves:

* constant data transfer
* asynchronous delivery

Perfect for Node.js.

---

# API Servers

Modern frontend apps constantly make:

* API requests
* database calls

Node.js handles these efficiently.

---

# Where Node.js Is NOT Ideal

Important honesty section.

Node.js is not best for:

* heavy CPU calculations
* video rendering
* machine learning computation
* massive image processing

Why?

Because CPU-heavy tasks can block event loop.

And once event loop blocks:
everyone suffers equally.

Like group punishment in school.

---

# Blocking Example



```js id="l73ks2"
while(true){

}

This blocks everything.

Server becomes unresponsive.

Because:
event loop cannot continue.

Real-World Companies Using Node.js

Many huge companies use Node.js.

Examples include:

Netflix
PayPal
LinkedIn
Uber
Walmart

Why?

Because they need:

scalability
realtime communication
efficient APIs
high concurrency

Why Developers Love Node.js

Besides performance,
Node.js also offers:

JavaScript everywhere
huge ecosystem
npm packages
fast development
strong community

Frontend and backend using same language became a massive advantage.

Before Node.js:
developers often had:

JavaScript frontend
different backend language

Now:
full-stack JavaScript became possible.

That changed web development completely.

Blocking vs Non-Blocking Comparison

Traditional Blocking Server

```text id="m64ps1"
Request 1 → Processing
Request 2 → Waiting
Request 3 → Waiting




---

# Node.js Non-Blocking Server



```text id="n55jd2"
Request 1 → Delegated
Request 2 → Processing
Request 3 → Processing
Request 4 → Processing

Much more efficient for modern web traffic.

Important Truth About Performance

Node.js is not magically faster at:

calculations
raw computation

Its real strength is:

handling many concurrent I/O operations efficiently

That distinction matters a lot.

Common Beginner Misunderstanding

People sometimes think:

“Single-threaded means weak.”

Not true.

Node.js succeeds because:

most web apps wait more than they calculate

And Node.js handles waiting extremely efficiently.

Quick Revision

Node.js Is Fast Because Of:

non-blocking I/O
event-driven architecture
efficient concurrency
lightweight request handling

Non-Blocking Means:

```text id="o46ks2"
Start Task
↓
Do Other Work
↓
Return Later




---

## Event Loop:

* manages callbacks
* processes events
* keeps server responsive

---

## Node.js Performs Best For:

* APIs
* realtime apps
* streaming
* chat systems

---

## Node.js Is Not Best For:

* CPU-heavy tasks
* blocking calculations

---

# Final Thoughts

Node.js became popular because it solved a massive modern web problem:

> handling huge numbers of users efficiently.

It does not win by brute force.

It wins by:

* wasting less time
* avoiding unnecessary waiting
* managing concurrency intelligently

That is why Node.js became one of the biggest technologies in modern backend development.

And honestly,
once you understand:

* non-blocking I/O
* event loop
* asynchronous execution

Node.js stops feeling magical.

You realize it is simply:

> a very smart system designed around efficient waiting.

What is Middleware in Express and How It Works

Shivam Yadav — Sun, 10 May 2026 15:28:31 +0000

What is Middleware in Express and How It Works

Every Express beginner eventually reaches this moment:

You open some backend project and suddenly see this mysterious thing everywhere:

```js id="a72ks1"
app.use()




Then somebody says:

> “Oh that’s middleware.”

And beginners immediately pretend they understood.

Meanwhile internally:

> “What even is this creature?”

Because middleware sounds complicated.

But the reality is surprisingly simple.

Middleware is basically:

> a checkpoint system between request and response.

That’s it.

In this article, we will understand:

* what middleware actually is
* where it sits in Express
* how request flow works
* execution order
* role of `next()`
* types of middleware
* real-world examples like:

  * logging
  * authentication
  * validation

And no, we are not diving into Express internals deep enough to summon ancient backend demons.

---

# First Understand How Request Flow Works

When a user sends request:



```text id="b81ms2"
Browser → Server

the request does not magically teleport to route handler.

Express processes it step by step.

Think of it like airport security.

Before boarding:

ID check
baggage check
security check
ticket verification

Only then:
you reach your gate.

Middleware works similarly.

What Is Middleware?

Middleware is:

a function that runs between request and response.

It gets access to:

request object (req)
response object (res)
next function (next)

Example:

```js id="c92ps1"
function middleware(req, res, next) {

console.log("Middleware running");

next();

}




This function executes before final response is sent.

---

# Middleware Position in Request Lifecycle



```text id="d73ks2"
Client Request
       ↓
Middleware
       ↓
Middleware
       ↓
Route Handler
       ↓
Response

This chain is called:

middleware pipeline

Request Pipeline Analogy

Imagine a restaurant.

Customer places order.

Before food reaches table:

waiter checks order
kitchen prepares food
manager verifies bill
staff serves plate

Many checkpoints exist before final output.

Middleware works the same way.

Why Middleware Exists

Middleware helps:

organize logic
reuse functionality
separate responsibilities

Instead of writing:

authentication
logging
validation

inside every route repeatedly.

Without middleware,
backend code becomes:

copy-paste Olympics.

Basic Middleware Example

```js id="e84js1"
const express = require("express");

const app = express();

function logger(req, res, next) {

console.log("Request received");

next();

}

app.use(logger);

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

res.send("Homepage");

});

app.listen(3000);




---

# What Happens Here?

When request comes:



```text id="f75ls1"
GET /

Flow becomes:

```text id="g66kd2"
Request
↓
logger middleware
↓
Route Handler
↓
Response




---

# Understanding `next()` Function

This is the most important middleware concept.



```js id="h57ps2"
next()

means:

“Move to the next middleware or route.”

Without next(),
request gets stuck forever.

Like customer support calls placed on eternal hold.

Example Without `next()`

```js id="i48ms1"
function middleware(req, res, next) {

console.log("Blocked");

}




Problem:

* request never reaches route
* browser keeps loading

Because middleware stopped the pipeline.

---

# Middleware Execution Sequence

Multiple middleware run in order.

Example:



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

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

app.get("/", (req, res) => {
    console.log("Route Handler");
    res.send("Done");
});

Output:

```text id="k20jd1"
Middleware 1
Middleware 2
Route Handler




Execution order matters a lot.

---

# Middleware Execution Flow



```text id="l11ps2"
Request
   ↓
Middleware 1
   ↓
Middleware 2
   ↓
Middleware 3
   ↓
Route Handler
   ↓
Response

This is Express middleware chaining.

Types of Middleware in Express

Express mainly has:

Application-level middleware
Router-level middleware
Built-in middleware

Let’s understand them one by one.

1. Application-Level Middleware

Applied to entire app.

Example:

```js id="m02ks1"
app.use((req, res, next) => {

console.log("Runs for every request");

next();

});




This runs for:

* `/`
* `/about`
* `/login`
* every route

Useful for:

* logging
* authentication
* request parsing

---

# Route-Specific Middleware

You can also apply middleware only to certain routes.

Example:



```js id="n93ms2"
app.get(
    "/profile",
    authMiddleware,
    (req, res) => {
        res.send("Profile Page");
    }
);

Here:

middleware runs only for /profile

2. Router-Level Middleware

Express allows separate routers.

Example:

```js id="o84ps1"
const router = express.Router();




Middleware can be attached specifically to router.

Example:



```js id="p75ks2"
router.use((req, res, next) => {

    console.log("Router Middleware");

    next();

});

Useful for:

modular backend structure
large applications

Real-World Router Example

Imagine:

```text id="q66jd1"
/admin




All admin routes may require:

* authentication
* admin permission

Instead of repeating middleware everywhere,
router-level middleware handles all of them together.

---

# 3. Built-In Middleware

Express already provides some middleware.

Most common:



```js id="r57ms2"
express.json()

Used for:

parsing JSON request body

Example:

```js id="s48ks1"
app.use(express.json());




Without this,
`req.body` will be undefined for JSON requests.

And debugging that for 40 minutes is basically Express beginner tradition.

---

# Another Built-In Middleware



```js id="t39ps2"
express.static()

Used for serving:

images
CSS
JavaScript files

Example:

```js id="u20ms1"
app.use(express.static("public"));




---

# Real-World Middleware Examples

Now let’s see actual practical use cases.

---

# 1. Logging Middleware

Tracks requests.

Example:



```js id="v11ks2"
function logger(req, res, next) {

    console.log(`${req.method} ${req.url}`);

    next();
}

Output:

```text id="w02jd1"
GET /
POST /login
GET /profile




Useful for:

* debugging
* monitoring traffic
* tracking API usage

---

# 2. Authentication Middleware

Protects private routes.

Example:



```js id="x93ms2"
function auth(req, res, next) {

    const token = req.headers.authorization;

    if (!token) {
        return res.send("Access Denied");
    }

    next();
}

Flow:

```text id="y84ks1"
Request
↓
Check Token
↓
Valid?
↓ ↓
Yes No
↓ ↓
Next Reject




---

# 3. Request Validation Middleware

Checks incoming data.

Example:



```js id="z75ps2"
function validate(req, res, next) {

    const { username } = req.body;

    if (!username) {
        return res.send("Username Required");
    }

    next();
}

Prevents bad data from entering application.

Combining Multiple Middleware

Example:

```js id="a66ms1"
app.post(
"/dashboard",
logger,
auth,
validate,
(req, res) => {

    res.send("Welcome");

}

);




Execution order:



```text id="b57ks2"
Request
   ↓
Logger
   ↓
Authentication
   ↓
Validation
   ↓
Route Handler
   ↓
Response

Very clean structure.

Why Middleware Makes Express Powerful

Middleware allows:

reusable code
modular architecture
cleaner backend structure

Instead of giant messy route handlers doing everything.

Without middleware,
large applications become:

giant spaghetti code disasters.

Important Middleware Rule

Order matters.

Example:

```js id="c48ps1"
app.use(express.json());




must come before routes using `req.body`.

Wrong order:



```js id="d39ms2"
app.post("/login", (req, res) => {
    console.log(req.body);
});

app.use(express.json());

Result:
req.body becomes undefined.

Because middleware executed too late.

Common Beginner Mistakes

Forgetting `next()`

Result:
request hangs forever.

Sending Multiple Responses

Bad example:

```js id="e20ks1"
res.send("Hello");

next();




Can create errors because response already ended.

---

# Wrong Middleware Order

Execution sequence matters heavily in Express.

---

# Middleware Is Not Only for Authentication

Beginners often think:

> middleware = auth only

No.

Middleware can:

* modify requests
* log data
* validate forms
* parse JSON
* handle errors
* compress responses

It is basically:

> backend traffic control.

---

# Simple Middleware Mental Model

Think of middleware as:

# security checkpoints for requests

Each middleware decides:

* continue
* modify request
* block request
* send response

That’s the entire concept.

---

# Quick Revision

## Middleware Is:

* function between request and response
* part of request pipeline

---

## Middleware Receives:



```js id="f11ms2"
(req, res, next)

`next()` Means:

```text id="g02jd1"
Move to next middleware




---

## Types of Middleware:

* Application-level
* Router-level
* Built-in

---

## Common Uses:

* logging
* authentication
* validation
* parsing JSON

---

# Final Thoughts

Middleware is one of the reasons Express became so successful.

Because instead of writing massive unreadable route handlers,
Express allows backend logic to flow step by step like an organized pipeline.

And once middleware finally clicks in your brain,
you suddenly understand:

* authentication systems
* logging systems
* validation layers
* API architecture

much more clearly.

At its core,
middleware is simply:

> “Something that happens before the final response.”

That’s the big scary concept.

Just a checkpoint system for requests.

JWT Authentication in Node.js Explained Simply

Shivam Yadav — Sun, 10 May 2026 15:24:56 +0000

JWT Authentication in Node.js Explained Simply

Authentication is one of those topics that sounds terrifying at first.

People start throwing around words like:

tokens
authorization
encryption
bearer headers
signatures
middleware

And suddenly beginners feel like:

“I just wanted users to log in, not join a cybersecurity agency.”

But the truth is:
JWT authentication is actually a very simple idea once you stop overcomplicating it.

In this article, we will understand:

what authentication really means
why applications need it
what JWT is
how JWT login works
structure of JWT
how tokens are sent
how protected routes work
why JWT became so popular

And no, we are not diving into scary cryptography mathematics today.
Human survival matters.

First Understand: What Authentication Actually Means

Authentication simply means:

“Proving who you are.”

That’s it.

When you log into:

Instagram
YouTube
Amazon
Netflix

the application checks:

```text id="a7d2s1"
"Are you really this user?"




If yes:
you get access.

If not:
goodbye.

---

# Real-Life Authentication Example

Imagine entering a college exam hall.

Teacher asks for:

* ID card

You show it.

Teacher verifies:

* your identity

Then allows entry.

That process is:

# authentication

---

# Why Authentication Is Required

Without authentication:
anyone could:

* access your account
* view private data
* modify information
* perform actions as you

That would be absolute chaos.

Imagine random people posting from your Instagram account at 3 AM:

> “I have left society and now sell coconuts in Goa.”

Authentication prevents that disaster.

---

# Traditional Session-Based Authentication

Before JWT became popular, many applications used:

# sessions

Flow:

1. User logs in
2. Server creates session
3. Session stored in database/server memory
4. Browser gets session ID
5. Every request sends session ID

This works.

But at large scale:

* managing sessions becomes harder
* scaling servers becomes difficult
* server stores too much state

Then JWT entered the scene like:

> “What if the server didn’t need to remember everyone?”

---

# What Is JWT?

JWT stands for:

# JSON Web Token

It is a token-based authentication system.

After login:

* server creates a token
* sends token to client
* client stores token
* client sends token with future requests

Server verifies token instead of storing session data.

---

# Simple JWT Idea

Instead of server remembering users,
the token itself carries user information.

Like a temporary digital ID card.

---

# JWT Is Stateless Authentication

This is the important concept.

# Stateless Authentication

Means:

* server does not store login state

The token contains everything needed.

Server simply verifies:

* Is token valid?
* Is signature correct?

If yes:
user is authenticated.

---

# Real-Life JWT Analogy

Imagine a concert entry pass.

Security guard does not memorize every visitor.

Instead:

* visitor carries pass
* guard checks validity
* if valid → entry allowed

JWT works similarly.

---

# Structure of a JWT

A JWT has 3 parts:



```text id="q9s2x1"
Header.Payload.Signature

Looks something like:

```text id="w8d1k2"
eyJhbGciOiJIUzI1Ni...




Looks scary.

Actually very structured.

---

# JWT Structure Breakdown

---

# 1. Header

The header stores:

* token type
* algorithm information

Example:



```json id="m2s8p1"
{
  "alg": "HS256",
  "typ": "JWT"
}

Meaning:

algorithm used = HS256
token type = JWT

2. Payload

Payload contains:

user data
token information

Example:

```json id="d8s2w1"
{
"id": 101,
"username": "shivam"
}




This data is called:

# claims

Important:
JWT payload is not encrypted by default.

Anyone can decode it.

So never store:

* passwords
* sensitive secrets

inside JWT payload.

Unless your goal is:

> creating future security documentaries.

---

# 3. Signature

Signature is the security part.

It verifies:

* token authenticity
* token integrity

Server creates signature using:

* secret key
* header
* payload

If token changes:
signature becomes invalid.

Meaning:
tampered token gets rejected.

---

# JWT Visual Structure



```text id="k7d2m1"
HEADER
   ↓
PAYLOAD
   ↓
SIGNATURE

Combined together:

```text id="x8s1z2"
header.payload.signature




---

# Installing JWT in Node.js

We usually use package:



```text id="j2w8d1"
jsonwebtoken

Install it:

```bash id="u8s2x1"
npm install jsonwebtoken




---

# Basic Login Flow Using JWT

Now let’s understand the actual login process.

---

# JWT Authentication Flow



```text id="l9d2p1"
User Logs In
      ↓
Server Verifies Credentials
      ↓
JWT Token Created
      ↓
Token Sent to Client
      ↓
Client Stores Token
      ↓
Client Sends Token with Requests
      ↓
Server Verifies Token
      ↓
Access Granted

This is the entire JWT system.

Simple flow.
Massive industry usage.

Creating Your First JWT Token

Example:

```js id="f8s2k1"
const jwt = require("jsonwebtoken");

const token = jwt.sign(
{
id: 1,
username: "shivam"
},
"secretkey"
);

console.log(token);




---

# Understanding `jwt.sign()`



```js id="n7d2s1"
jwt.sign(payload, secret)

payload = user data
secret = secret key used for signature

This generates token.

Example Generated Token

```text id="r8w1m2"
eyJhbGciOiJIUzI1NiIsInR5cCI...




Looks like hacker language.

Actually just encoded text.

---

# Login Route Example

Using Express:



```js id="c9s2p1"
const express = require("express");
const jwt = require("jsonwebtoken");

const app = express();

app.use(express.json());

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

    const user = {
        id: 1,
        username: "shivam"
    };

    const token = jwt.sign(user, "secretkey");

    res.json({
        token
    });
});

app.listen(3000);

When user hits:

```text id="p8d1k1"
/login




server sends token.

---

# Sending Token with Requests

After login,
client stores token.

Usually in:

* localStorage
* cookies
* memory

Then sends token in headers.

Example:



```text id="m7w2x1"
Authorization: Bearer TOKEN_HERE

This is standard practice.

Why “Bearer”?

Bearer means:

whoever carries this token gets access.

Like carrying a valid entry ticket.

Protected Routes

Now comes the real power.

Some routes should only work for logged-in users.

Example:

profile page
orders
private dashboard
account settings

These become:

protected routes

Token Verification Middleware

Example:

```js id="v9s2d1"
function verifyToken(req, res, next) {

const bearerHeader = req.headers["authorization"];

if (!bearerHeader) {
    return res.sendStatus(403);
}

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

jwt.verify(token, "secretkey", (err, decoded) => {

    if (err) {
        return res.sendStatus(403);
    }

    req.user = decoded;

    next();
});

}




Looks scary first time.
Actually straightforward.

---

# What This Middleware Does

---

## Step 1: Get Authorization Header



```js id="q8w1k2"
req.headers["authorization"]

Gets token header.

Step 2: Extract Token

```js id="d7s2m1"
Bearer TOKEN




Split and get actual token.

---

## Step 3: Verify Token



```js id="x9d2s1"
jwt.verify()

Checks:

signature validity
token authenticity

Step 4: Allow Access

If token valid:

```js id="a8s2k1"
next()




moves to protected route.

---

# Protected Route Example



```js id="h7d2m1"
app.get("/profile", verifyToken, (req, res) => {

    res.json({
        message: "Protected Profile Data",
        user: req.user
    });

});

Without valid token:
access denied.

With valid token:
access granted.

Token Validation Lifecycle

```text id="t8w2p1"
Client Sends Request
↓
Token Attached in Header
↓
Server Verifies Token
↓
Valid?
↓ ↓
Yes No
↓ ↓
Access Reject Request
Granted




This flow powers millions of applications daily.

---

# Why JWT Became So Popular

Because JWT is:

* lightweight
* scalable
* stateless
* fast
* easy for APIs

Especially useful for:

* mobile apps
* frontend-backend separation
* REST APIs
* microservices

---

# But JWT Is Not Magic

Now important honesty section.

JWT is useful.
But beginners sometimes worship it like:

> ancient authentication prophecy.

JWT is not always the perfect solution.

For example:

* logout handling becomes tricky
* token expiration management matters
* stolen tokens are dangerous

Good security practices are still required.

---

# Important Security Practices

---

## Never Store Passwords in JWT

Bad idea.

Very bad idea.

---

## Use Expiration Time

Example:



```js id="k9s2w1"
jwt.sign(user, "secretkey", {
    expiresIn: "1h"
});

Token expires after 1 hour.

Keep Secret Key Safe

Never expose:

```text id="b7d2m1"
secretkey




in frontend code.

Otherwise attackers can generate fake tokens.

And then:
your backend security becomes decorative art.

---

# Common Beginner Confusions

---

# Authentication vs Authorization

## Authentication



```text id="y8w1s2"
Who are you?

Authorization

```text id="n7d2k1"
What are you allowed to access?




Different concepts.

---

# JWT Is Not Encryption

JWT is encoded.
Not encrypted by default.

Huge difference.

---

# Stateless Does Not Mean Secure Automatically

Security still depends on:

* proper implementation
* HTTPS
* safe token storage
* expiration handling

---

# Quick Revision

## JWT Means:



```text id="m9s2x1"
JSON Web Token

JWT Has 3 Parts:

```text id="d8w1p1"
Header.Payload.Signature




---

## Login Flow:



```text id="r7d2m1"
Login → Generate Token → Send Token → Verify Token

Protected Routes Require:

```js id="q9s2k1"
jwt.verify()




---

## JWT Is:

* stateless
* lightweight
* scalable

---

# Final Thoughts

JWT authentication becomes much less scary once you realize:

> it is basically just a digital identity card system.

User logs in.
Server creates token.
User carries token.
Server verifies token.

That’s the core idea.

The complicated-looking strings and fancy terminology scare beginners more than the actual concept itself.

And honestly,
most backend authentication systems are simply:

> “Prove you are allowed to be here.”

JWT just happens to do it in a clean and scalable way.

Creating Routes and Handling Requests with Express

Shivam Yadav — Sun, 10 May 2026 15:22:13 +0000

Creating Routes and Handling Requests with Express

If raw Node.js feels like:

building furniture using individual pieces of wood,

then Express.js feels like:

finally discovering screws, tools, and basic human happiness.

Because let’s be honest.

Creating servers using pure Node.js is great for learning.

But after writing this for the 17th time:

```js id="a82ks1"
res.writeHead(200, { "Content-Type": "text/plain" });
res.end("Hello World");




you start questioning your life choices.

That is exactly why Express.js became popular.

It removes unnecessary pain and lets developers focus on:

* routes
* logic
* APIs
* applications

instead of wrestling with low-level server code every five minutes.

In this article, we will learn:

* What Express.js is
* Why developers use it
* How to create an Express server
* Handling GET requests
* Handling POST requests
* Sending responses properly
* Understanding routing clearly

And yes, we are keeping things beginner-friendly without turning the article into a 900-page encyclopedia.

---

# First Understand: What Is Express.js?

Express.js is a backend framework for Node.js.

It helps simplify:

* server creation
* routing
* request handling
* middleware
* APIs

Instead of writing huge amounts of raw Node.js code,
Express gives you clean and readable methods.

Think of Node.js as:

> the engine.

And Express as:

> the comfortable car built on top of it.

---

# Why Express.js Was Needed

Let’s compare.

---

# Creating Server in Raw Node.js



```js id="f71sk2"
const http = require("http");

const server = http.createServer((req, res) => {
    if (req.url === "/") {
        res.write("Home Page");
        res.end();
    }
});

server.listen(3000);

This works.

But as your application grows:

more routes
more conditions
more headers
more parsing

everything becomes messy very quickly.

Soon your file starts looking like:

ancient scrolls written by exhausted developers.

Same Thing Using Express

```js id="m92ks1"
const express = require("express");

const app = express();

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

app.listen(3000);




Cleaner.
Readable.
Less pain.
Less unnecessary code.

This is why developers love Express.

---

# Installing Express

First create a project folder.



```text id="z81sk2"
express-app

Open terminal inside it.

Now initialize Node project:

```bash id="x71ps2"
npm init -y




This creates:



```text id="q61nd2"
package.json

This file stores:

project information
dependencies
scripts

Now install Express:

```bash id="w82js1"
npm install express




Done.

Express is now added to your project.

---

# Creating Your First Express Server

Create file:



```text id="r81dk2"
app.js

Write:

```js id="p72ms1"
const express = require("express");

const app = express();

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




Run server:



```bash id="s91kd2"
node app.js

Output:

```text id="d82js1"
Server running on port 3000




Congratulations.

You now have an Express server running.

Tiny file.
Massive upgrade.

---

# Understanding What Is Happening

---

## Step 1: Import Express



```js id="e91ks2"
const express = require("express");

Imports Express library.

Step 2: Create App

```js id="u82ms1"
const app = express();




Creates Express application instance.

This `app` object controls:

* routes
* requests
* responses
* middleware
* server behavior

---

## Step 3: Start Server



```js id="l73ps1"
app.listen(3000);

Starts server on port 3000.

What Are Routes?

Routes are basically:

paths users visit.

Example:

```text id="g92ks1"
/




means homepage.



```text id="h83jd1"
/about

means about page.

```text id="t72ls1"
/contact




means contact page.

Every route can perform different actions.

---

# Understanding Routing Properly

Imagine your server is a hotel receptionist.

Different customers ask for different rooms.

Example:



```text id="j82ls1"
/login
/products
/profile
/orders

The receptionist checks:

which path user requested
then sends them to correct place

That is routing.

Handling GET Requests

GET requests are used to:

fetch data
request pages
retrieve information

Example:
Opening a website in browser usually sends a GET request.

First GET Route

Update app.js:

```js id="v73ms2"
const express = require("express");

const app = express();

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

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




Now visit:



```text id="o82jd1"
http://localhost:3000

You will see:

```text id="i72ks1"
Welcome to Homepage




---

# Another Route Example



```js id="c91ps2"
app.get("/about", (req, res) => {
    res.send("About Page");
});

Now:

```text id="f82ls1"
http://localhost:3000/about




returns:



```text id="b71kd2"
About Page

Different routes.
Different responses.

Simple.

Request → Route → Response Flow

```text id="n92js1"
Client Request
↓
Express Route Matches URL
↓
Route Handler Executes
↓
Response Sent Back




This is the foundation of backend APIs.

---

# Understanding Route Handlers

This part:



```js id="m81ps2"
(req, res) => {

}

is called:

route handler

It handles:

incoming request
outgoing response

What Is `req`?

req means:

request object

It contains:

URL
headers
query parameters
body data
client information

Basically:

everything user sends.

What Is `res`?

res means:

response object

It helps send data back to client.

Examples:

```js id="x82ks1"
res.send()
res.json()
res.status()




---

# Sending Responses

---

## Sending Text



```js id="q71ms2"
res.send("Hello");

Sending HTML

```js id="k82ls1"
res.send("

Hello

");




---

## Sending JSON



```js id="t91jd2"
res.json({
    name: "Shivam",
    role: "Developer"
});

Express automatically converts it into JSON response.

Very useful for APIs.

Handling POST Requests

POST requests are used to:

send data
create resources
submit forms

Examples:

login forms
signup forms
uploading data

Basic POST Route

```js id="a73ks2"
app.post("/login", (req, res) => {
res.send("Login Successful");
});




This route responds only to:

# POST requests

Not GET requests.

---

# Difference Between GET and POST

| Method | Purpose          |
| ------ | ---------------- |
| GET    | Fetch data       |
| POST   | Send/Create data |

---

# Important Beginner Confusion

If you open:



```text id="r82ks1"
http://localhost:3000/login

in browser,
it sends:

GET request

But your route expects:

POST request

Result?

```text id="w91js2"
Cannot GET /login




This is normal.

Not a bug.

Your route simply does not handle GET there.

---

# Express Routing Structure Visualization



```text id="u73ls1"
app.get("/")        → Homepage
app.get("/about")  → About Page
app.post("/login") → Login Logic
app.get("/users")  → User Data

Each route has:

method
path
handler

Why Express Feels So Powerful

Because Express removes repetitive low-level work.

Without Express:

manual routing
manual headers
manual parsing
manual response handling

With Express:

cleaner syntax
organized routes
faster development

It lets developers focus on:

application logic instead of server headaches.

Real-World Example

Imagine building:

Instagram
YouTube
Swiggy
Amazon

Every action becomes a route.

Example:

```text id="y82ks1"
GET /products
POST /orders
GET /profile
POST /login
DELETE /cart




Backend development is basically:

> handling requests properly and sending useful responses.

That is why routing is one of the most important concepts in Express.

---

# Common Beginner Mistakes

---

## Forgetting to Install Express

Error:



```text id="p71js2"
Cannot find module 'express'

Solution:

```bash id="z82ls1"
npm install express




---

## Port Already Running

Error:



```text id="v91kd2"
EADDRINUSE

Means:
another app already uses that port.

Change port:

```js id="h73ps2"
app.listen(5000)




---

## Wrong HTTP Method

Using:



```js id="n82ks1"
app.post()

but testing in browser.

Browser sends GET request.

Result:
route not found.

Quick Revision

Express.js Is:

Node.js framework
simplifies backend development
handles routes easily

Install Express

```bash id="l91ms2"
npm install express




---

## Create Server



```js id="c82ls2"
const app = express();

Start Server

```js id="s73jd1"
app.listen(3000)




---

## GET Request



```js id="d82ks1"
app.get()

Used for fetching data.

POST Request

```js id="g91ps2"
app.post()




Used for sending data.

---

# Final Thoughts

Learning Express for the first time feels refreshing because suddenly:

* routing becomes readable
* servers become easier
* backend code stops looking terrifying

And honestly,
that is why Express became one of the most loved Node.js frameworks ever.

It takes complicated backend concepts and says:

> “Relax. We can make this cleaner.”

And that simplicity is exactly what made Express dominate backend development for years.

Setting Up Your First Node.js Application Step-by-Step

Shivam Yadav — Sun, 10 May 2026 15:20:06 +0000

Setting Up Your First Node.js Application Step-by-Step

Every developer remembers their first console.log().

That one tiny line that makes you feel like:

“Yes. I am officially a programmer now.”

And when starting backend development, Node.js is usually where that journey begins.

But for beginners, the first setup can feel unnecessarily confusing.

People throw around terms like:

runtime
REPL
server
environment
localhost

And suddenly:

you just wanted to print “Hello World” but now it feels like launching a satellite.

So in this article, we are going to build your first Node.js application from absolute scratch.

No frameworks.
No unnecessary complexity.
No “just trust me bro” explanations.

By the end, you will:

install Node.js
verify installation
understand REPL
create your first JavaScript file
run it using Node
build your first basic server

And most importantly:
you will actually understand what is happening.

First Understand: What Exactly Is Node.js?

Before installing anything, let’s clear the biggest confusion.

Node.js is not a programming language.

You still write:

JavaScript

But normally JavaScript runs inside:

browsers

Like:

Chrome
Firefox
Edge

Node.js allows JavaScript to run:

outside the browser
directly on your computer/server

Meaning JavaScript can now:

create servers
work with files
access databases
build APIs
handle backend logic

Basically:

Node.js gave JavaScript a job outside the browser.

Installing Node.js

To install Node.js, go to the official website:

Node.js Official Website

You will usually see:

LTS Version
Current Version

Which One Should You Install?

Install:

LTS Version

LTS means:

Long Term Support

It is:

stable
tested
safer for beginners and production apps

The “Current” version contains newer features but may not always be stable.

So unless you enjoy debugging mysterious problems at 2 AM:

use LTS.

Installation Process

The setup is mostly:

Next
Next
Accept
Install
Finish

Classic software installation ritual.

Node.js installation also installs:

npm

npm stands for:

Node Package Manager

It helps install packages and libraries.

We will use it later.

Checking If Node.js Is Installed

After installation, open your terminal.

You can use:

CMD
PowerShell
Terminal
VS Code terminal

Now type:

```bash id="s7a2d1"
node -v




Example output:



```bash id="x8s2k1"
v22.3.0

This means:

Node.js is successfully installed

Now check npm:

```bash id="m3s8d1"
npm -v




Example:



```bash id="j3k8f2"
10.8.1

Done.

Your machine is now officially ready for backend development.

Congratulations.
You now possess the power to accidentally break production servers in the future.

Understanding the Node REPL

Before creating files, we need to understand something called:

REPL

REPL stands for:

```text id="r1a8s3"
Read
Evaluate
Print
Loop




Sounds complicated.

It is actually very simple.

---

# What REPL Does

REPL is basically:

> a live JavaScript playground inside the terminal.

You type JavaScript.
Node.js executes it immediately.

---

# Start REPL

Open terminal and type:



```bash id="t9s7d1"
node

Now your terminal changes into interactive mode.

Example:

```bash id="k8s2p4"

Now try this:

```js id="q1p9x2"
2 + 2




Output:



```text id="w2s8m4"
4

Try another:

```js id="e9d2s1"
console.log("Hello Shivam")




Output:



```text id="y3f8c1"
Hello Shivam

This is REPL.

Why REPL Is Useful

REPL is great for:

testing code quickly
checking logic
debugging small things
learning JavaScript basics

Instead of creating files repeatedly.

Think of it like:

rough notebook work before final answer.

Exit REPL

To exit:

Press:

```text id="p0s9z1"
CTRL + C




twice.

Or type:



```js id="n8d3x7"
.exit

Creating Your First Node.js File

Now let’s create an actual JavaScript file.

Create a folder:

```text id="u7x2m9"
my-first-node-app




Inside it create a file:



```text id="z4m8k2"
app.js

Now write:

```js id="v8s1c2"
console.log("Hello from Node.js");




Save the file.

---

# Running Your First Node.js Script

Open terminal inside the project folder.

Run:



```bash id="l2p8x1"
node app.js

Output:

```text id="h8s2w4"
Hello from Node.js




And there it is.

Your first Node.js program.

Tiny line.
Massive moment.

---

# What Actually Happened Here?

When you ran:



```bash id="d8f2s9"
node app.js

Node.js:

opened the file
read JavaScript code
executed it using the V8 engine
displayed output in terminal

Simple Execution Flow

```text id="o8w2p1"
app.js
↓
Node.js Runtime
↓
V8 JavaScript Engine
↓
Execution
↓
Terminal Output




That is the basic flow of Node.js.

---

# Understanding the Node Runtime

A lot of beginners think Node.js is only:

> “something that runs JavaScript.”

But internally it is much bigger.

Node.js contains:

* V8 JavaScript Engine
* APIs
* Event Loop
* File System Access
* Networking Capabilities

This combination creates a backend runtime environment.

Without Node.js:
JavaScript alone cannot:

* read files
* create servers
* access operating system features

Browsers intentionally restrict that for security reasons.

---

# Writing Your First Hello World Server

Now comes the fun part.

We are going to create an actual server.

Still without frameworks.

No Express.
No shortcuts.

Pure Node.js.

---

# Create Server File

Inside `app.js` write:



```js id="q7s1m2"
const http = require("http");

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

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

Now run:

```bash id="r9x2s1"
node app.js




Output:



```text id="j2m8d4"
Server running on port 3000

What Is Happening Here?

Let’s break this down slowly.

Step 1: Import HTTP Module

```js id="f7d1p9"
const http = require("http");




Node.js has built-in modules.

`http` helps create web servers.

---

## Step 2: Create Server



```js id="a8s2d7"
http.createServer()

This creates a server object.

Step 3: Handle Request and Response

```js id="m8s2p1"
(req, res)




* `req` = incoming request
* `res` = outgoing response

---

## Step 4: Send Response



```js id="c2d9w1"
res.write("Hello World");

Sends data to browser.

Step 5: End Response

```js id="b7f3x1"
res.end();




Ends the response cycle.

Without this:
browser keeps waiting forever.

Like waiting for a friend who said:

> “5 minutes away.”

---

## Step 6: Start Server



```js id="t2w8n1"
server.listen(3000)

Starts server on port 3000.

Testing the Server

Open browser and visit:

```text id="w9s2l1"
http://localhost:3000




You will see:



```text id="v7d1m8"
Hello World

You officially built your first backend server.

Not copied.
Actually understood.

Huge difference.

Understanding localhost

localhost means:

your own computer

Port 3000 is like:

a specific door of your application.

Different applications use different ports.

Examples:

3000
5000
8000
8080

Visual Flow of Server Request

```text id="p2x7s4"
Browser Request
↓
localhost:3000
↓
Node.js Server
↓
Handles Request
↓
Sends Response
↓
Browser Displays Output




This is the foundation of backend development.

Literally everything grows from here.

---

# Common Beginner Mistakes

## Forgetting to Save File

You change code.
Run program.
Nothing changes.

Because:

> file was never saved.

Classic beginner attack.

---

## Wrong File Name

Running:



```bash id="n7s2p1"
node index.js

when file is actually:

```text id="m8s1x4"
app.js




Result:
error.

---

## Port Already In Use

Sometimes port 3000 is occupied.

Error example:



```text id="k2d9p1"
EADDRINUSE

Just change port:

```js id="f8w2d1"
server.listen(5000)




---

# Why Learning Core Node.js Matters

A lot of beginners jump directly into:

* Express
* Next.js
* NestJS

Without understanding Node.js basics.

Then one small error appears and everything collapses emotionally.

Understanding:

* server creation
* request handling
* runtime behavior
* modules

makes frameworks easier later.

Because frameworks are just:

> abstractions built on top of Node.js.

---

# Quick Revision

## Node.js Is:

* a JavaScript runtime
* used outside browsers
* used for backend development

---

## REPL Means:



```text id="x8c1v7"
Read
Evaluate
Print
Loop

Interactive JavaScript environment.

Run Node File Using:

```bash id="l9p2s1"
node filename.js




---

## Create Basic Server Using:



```js id="u2s8m1"
http.createServer()

Access Server Using:

```text id="g7s1x9"
http://localhost:3000




---

# Final Thoughts

Your first Node.js application is not just about printing:



```js id="n2d8s4"
Hello World

It is about understanding:

how JavaScript runs outside browsers
how servers work
how requests and responses behave
how backend systems begin

Every advanced backend application:

authentication systems
APIs
chat apps
streaming platforms
real-time systems

starts from these exact basics.

And honestly, backend development becomes far less scary once you realize:

A server is just code waiting for someone to say hello first.

How Node.js Handles Multiple Requests with a Single Thread

Shivam Yadav — Sun, 10 May 2026 15:18:00 +0000

How Node.js Handles Multiple Requests with a Single Thread

“Wait… Node.js uses only one thread? Then how is it handling thousands of users without catching fire?”

That is probably the first question every developer asks after hearing that Node.js is single-threaded.

Because in most people’s minds:

More users = More threads = More CPU pain = More suffering.

But Node.js walks into the room and says:

“Nah. I’ll do it differently.”

And surprisingly… it works insanely well.

In this blog, we will understand:

What “single-threaded” actually means
How Node.js handles multiple users at the same time
What the event loop really does
How background workers help Node.js
Why Node.js scales so well
Why concurrency is not the same as parallelism

And yes, we are going to use the legendary chef analogy because Node.js without the chef analogy is basically illegal.

First Understand: Thread vs Process

Before jumping into Node.js, let’s clear one confusion.

Process

A process is a running application.

For example:

Chrome running → one process
VS Code running → another process
Your Node.js server running → another process

Each process has:

its own memory
its own resources
its own execution environment

Think of a process as:

A full restaurant building.

Thread

A thread is a worker inside that process.

Think:

One restaurant can have many chefs
Each chef is a thread

Traditional servers often create:

one thread per request
or multiple threads handling users

More users → more threads.

And eventually:

Your server starts sweating harder than students during viva exams.

Node.js Is Single-Threaded

Node.js mainly runs on:

one main thread
one event loop

Meaning:

one thread handles JavaScript execution

This sounds terrible at first.

Because naturally you think:

“One thread? So one user at a time?”

No.

That is where Node.js becomes interesting.

The Biggest Misunderstanding About Node.js

People hear:

“Node.js is single-threaded”

And assume:

“It can only do one thing at a time.”

Wrong.

Node.js can handle many connections simultaneously.

The important word is:

Concurrency

Not parallelism.

Concurrency vs Parallelism

Parallelism

Doing multiple tasks literally at the same time.

Example:

4 chefs cooking 4 dishes simultaneously

That is parallelism.

Concurrency

Handling multiple tasks efficiently by switching between them.

Example:
A single chef:

takes one order
puts noodles to boil
while noodles cook, takes another order
while second dish cooks, serves another customer

One chef.
Multiple customers.
Nobody feels ignored.

That is concurrency.

And that…
is exactly how Node.js works.

The Famous Chef Analogy

Imagine a restaurant with:

one super-fast chef
many customers

Now imagine customers ordering:

pizza
burgers
pasta
coffee

If the chef waits for every dish completely before taking another order:
the restaurant dies.

Instead the chef:

starts cooking one dish
delegates slow work
handles other customers meanwhile

This is Node.js.

How Node.js Actually Handles Requests

Let’s say 5 users hit your server at the same time.

Example:

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

Requests arrive:

User 1
User 2
User 3
User 4
User 5

Node.js does not create:

5 threads
5 processes

Instead:

all requests enter the event loop system

The Event Loop: The Real Hero

The event loop is basically the manager of Node.js.

It continuously checks:

"Is there any task ready to execute?"

If yes:

execute it

If not:

keep moving

The event loop never sleeps.

Unlike college students after lunch.

Simple Flow of Node.js

Client Request
      ↓
Event Queue
      ↓
Event Loop
      ↓
Execute Callback
      ↓
Send Response

Very simple architecture.

But insanely powerful.

What Happens During Slow Operations?

Now comes the magic.

Suppose a request needs:

database query
file reading
API call
network request

These operations are slow.

If Node.js handled them directly on the main thread:
everything would freeze.

But Node.js is smarter than that.

Delegating Work to Background Workers

Node.js uses:

libuv
OS kernel
thread pool

to handle heavy or slow operations.

Meaning:

When a slow task appears:

Node.js delegates it
background workers handle it
main thread becomes free again

Meanwhile:

event loop continues handling other users

Example

const fs = require("fs");

console.log("Start");

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

console.log("End");

Output:

Start
End
[file content]

Why?

Because:

file reading is delegated
Node.js does not wait
callback executes later

This is non-blocking behavior.

Visual Understanding

Traditional Blocking Server

User 1 → Wait
User 2 → Wait
User 3 → Wait

Everything waits in line like:

government office token system.

Node.js Non-Blocking Server

User 1 → delegated
User 2 → handled
User 3 → handled
User 4 → handled

Main thread stays free.

That is why Node.js feels fast.

Event Loop + Worker Interaction

Request Comes In
       ↓
Event Loop Receives It
       ↓
Needs Slow Task?
   ↙         ↘
 No           Yes
 ↓             ↓
Execute      Send to Worker
Immediately        ↓
              Worker Finishes
                    ↓
            Callback Queue
                    ↓
              Event Loop Executes

This architecture is the heart of Node.js.

Why Node.js Scales So Well

Now the important question.

Why do companies use Node.js for:

chat apps
streaming
APIs
realtime systems

Because Node.js is extremely efficient for I/O operations.

Traditional Multi-Threaded Servers Problem

Imagine:

10,000 users
10,000 threads

Your system becomes:

memory hungry
CPU heavy
expensive

Threads are costly.

Context switching between threads also costs performance.

Node.js Approach

Instead:

one main thread
async handling
non-blocking architecture

Result:

less memory usage
faster request handling
better scalability

Node.js says:

“Why create 10,000 workers when one smart worker can manage the crowd?”

But Wait… Node.js Is Not Perfect

Now let’s be honest.

Node.js is amazing for:

APIs
realtime apps
sockets
streaming
I/O-heavy applications

But not ideal for:

CPU-heavy calculations
video rendering
massive mathematical processing

Because:

CPU-heavy tasks block the single thread

If one task takes too long:
the event loop gets stuck.

And then:
every user suffers together.

Like group punishment in school.

Example of Blocking Code

while(true){

}

This infinite loop blocks everything.

Server becomes unresponsive.

Because:

event loop cannot continue

So What Makes Node.js Powerful?

Not magic.

Not “single thread speed”.

The real power is:

event-driven architecture
non-blocking I/O
async execution
efficient concurrency

That combination changed backend development forever.

Real-Life Example

Think about a food delivery app.

Thousands of users:

ordering food
checking status
making payments
tracking delivery

Most operations are:

waiting for DB
waiting for APIs
waiting for network

Node.js handles these waiting tasks beautifully.

Instead of wasting threads doing nothing.

Quick Revision

Node.js Is:

single-threaded for JavaScript execution
event-driven
non-blocking
asynchronous

Event Loop Does:

manages execution
handles callbacks
keeps server responsive

Background Workers Handle:

file system operations
database work
network requests
heavy async tasks

Node.js Is Great For:

APIs
realtime applications
chat apps
streaming
websocket systems

Node.js Is Bad For:

CPU-intensive calculations
long blocking operations

Final Thoughts

At first, Node.js sounds impossible.

One thread handling thousands of users?

Feels fake.

But once you understand:

event loop
async behavior
worker delegation
non-blocking architecture

everything clicks.

Node.js does not win by:

doing more work.

It wins by:

wasting less time waiting.

And honestly, that is a pretty smart philosophy even outside programming.

Because half of software engineering is basically:

managing waiting efficiently.

And Node.js mastered that game.

What is Node.js? JavaScript on the Server

Shivam Yadav — Sat, 09 May 2026 12:11:14 +0000

What Exactly is Node.js?

hi its me

so today's topic is about nodejs yes what is node js why is nodejs who is nodejs and how is node js
everything about node js

just kidding 😭

we are just going to talk about node js like what is it really?
is it JavaScript?
is it a language?
like exactly what it is

so let begin i think i have talked shit for too long let start

First, What is Node.js?

Node.js is a JavaScript runtime that allows JavaScript to run outside the browser — most commonly on servers, backend systems, and command-line tools.

yes this is one of the best ways to explain node js (self appreciation moment waah wahi 😌)

Important things to know:

Node.js is NOT a programming language
Node.js is NOT a framework
JavaScript is the programming language

Node.js is the environment/runtime that executes JavaScript on the server.

Originally JavaScript Was Only For Browsers

Originally, JavaScript was created to make websites interactive.

For example, browsers provide:

JavaScript engine
Browser APIs
DOM access

Example:

document.getElementById("btn");

All these things only work because browsers provide:

document
window
DOM APIs

Without a browser, these APIs do not exist.

Browser JavaScript Main Job

Browser JavaScript's main job is:

interacting with webpages
updating UI
handling clicks

Example:

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

simple life
button clicked
developer happy
user confused why button exists
perfect web development cycle 👍

What Does Node.js Do?

Node.js main job is to:

handle servers
access filesystem
manage databases
process requests

Example:

const fs = require("fs");

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

So Node.js actually just takes the engine which helps browsers run JavaScript, adds some additional features on top of it, and boom — this is Node.js.

Why Was Node.js Made?

Before Node.js was invented, JavaScript could only run inside browsers.

Backend used other languages like:

PHP
Java
Ruby
Python

This separation led a man to create Node.js.

BTW do u know who created Node.js?
i know that just its a man (i am not going to say 😭)

The problem was:

frontend = JavaScript
backend = different language

So developers had to learn multiple languages.

How Node.js Changed Everything

Node.js made it possible to run JavaScript outside the browser.

Which means the same language could now be used for:

frontend
backend

Now the same developer learns one language and can build full applications.

and yes developers after this:

“wait… i can suffer in only one language now?”
revolutionary moment

The V8 Engine

Now the big chunk of separating JavaScript from the browser and running it outside the browser was made possible by the V8 Engine.

It basically helps compile JavaScript into machine code very efficiently.

V8 was created by Google for Chrome.

This is how the high-level flow looks:

JavaScript Code
       ↓
V8 Engine
       ↓
Machine Code
       ↓
CPU Execution

Important Thing To Know About V8

V8 alone is NOT Node.js.

Node.js adds:

filesystem access
networking
server APIs
event loop
operating system interaction

This all happens on top of V8.

This diagram might help:

JavaScript Code
       ↓
Node.js Runtime
       ↓
V8 Engine
       ↓
OS APIs / File System / Network

Additional Features Provided By Node.js

Some additional features provided by Node.js are:

handling servers
accessing filesystem
managing databases
processing requests

It also helps Node.js handle:

WebSockets
chats
live notifications
streaming

One of the best things Node.js gave us is NPM (Node Package Manager).

If i start explaining this it would require another blog because it is actually another rabbit hole 💀

How Node.js Works

Event-Driven Architecture

One of Node.js’s biggest strengths is Event-driven architecture.

Instead of blocking everything while waiting, Node.js uses events and callbacks.

As u know Node.js is single-threaded, so this part should not act as a disadvantage.
That’s why Event-Driven Architecture was introduced.

Traditional Blocking Example

Imagine a server handling:

file reading
database query
API request

Traditional systems may wait for one task to finish before handling another.

Basically:

Do work
Wait
Do next work
Wait again
Cry a little
Repeat

How Node.js Handles This

Node.js works differently.

It says:

“Start task and continue doing other work.”

When the task finishes:

callback runs
event triggers

Example:

const fs = require("fs");

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

console.log("Other code running");

Output:

Other code running
(file content later)

Node.js does not block execution while waiting for file reading.

Event Loop Idea (Simple)

Task Starts
      ↓
Node.js Continues Other Work
      ↓
Task Finishes
      ↓
Callback Executed

This makes Node.js efficient for:

concurrent requests
I/O-heavy applications
real-time systems

Browser JavaScript vs Node.js

Browser JavaScript

Runs inside browser
Uses DOM APIs
Handles UI

Node.js

Runs on server
Uses OS APIs
Handles backend logic

Conclusion

Node.js transformed JavaScript from:

a browser-only language

into:

a full backend runtime

By combining:

the V8 engine
event-driven architecture
non-blocking I/O

Node.js became one of the most popular backend technologies in the world.

It allowed developers to:

use JavaScript everywhere
build scalable applications
create fast real-time systems

so now this is the end

if u liked the blog please let me know in comments
like the video and subscribe me for more knowledge 😭

Handling File Uploads in Express with Multer

Shivam Yadav — Fri, 08 May 2026 17:24:41 +0000

yooo its me

the writter of this blog

today blog is all about multer yes that module which is kinda having 3 or 4 million download a week yes it has

so let see what i am going to cover in this blog

1) how file transfer from frontend to backend
2) what is multer
3) how to use multer
4) kinda eveyrthing about multer and how to use it

first let biginner

1) how file travels from frontend to backend

Normal HTTP requests usually send text like this

{
  "name": "shivam"
}

which is done by express by adding things like

app.use(express.json());

and

app.use(express.urlencoded());

for text-based data.

This is easy.

But files are NOT text.

A PNG file is raw binary bytes:

89 50 4E 47 ...

So browsers needed a special way to send everything in proper way:

text
files
metadata

all together in ONE request.

and that will be done using:

multipart/form-data

why called multipart?

because it contain multi form data 😭

yes this is why it is called like that

Now Let’s Break This Down

Part 1

------WebKit123
Content-Disposition: form-data; name="username"

shivam

This means:

{
  username: "shivam"
}

Part 2 (File)

------WebKit123
Content-Disposition: form-data; name="image"; filename="cat.png"
Content-Type: image/png

This is metadata.

It tells:

field name = image
filename = cat.png
mime type = image/png

Then comes:

(binary bytes)

Actual file data.

How Data Actually Travels

HTTP body travels as STREAMS

NOT like a giant packet.

Instead:

Chunk 1
Chunk 2
Chunk 3
Chunk 4

Like:

------WebKit123
Content-Dispo

then:

sition: form-data;

then:

name="image"

Everything arrives gradually.

Node.js Receives It as Stream

Inside Node.js req is actually a readable stream.

You can literally do:

req.on("data", chunk => {
   console.log(chunk);
});

Example you may see:

<Buffer 2d 2d 2d 2d 57 65 62 4b>

These are raw bytes.

now the best part comes

how a developer should handle this

see express is not having anything inbuilt to handle this

but there is one module:

`multer`

it helps us convert that raw bit into proper data

kinda like this:

{
  fieldname: 'image',
  originalname: 'cat.png',
  encoding: '7bit',
  mimetype: 'image/png',
  destination: 'uploads/',
  filename: 'a8f91c.png',
  path: 'uploads/a8f91c.png',
  size: 34567
}

let see how multer does that

Multer acts as Middleware between request and route handler.

multer parse this stream manually like:

Reads chunks
Detects boundaries
Separates parts
Reads headers
Extracts metadata
Writes file bytes to disk

How File Is Recreated

Suppose multer extracts:

89 50 4E 47 ...

(this data is after cleaning all the other data this is only the file data)

These are PNG bytes.

It simply writes them into a file using:

fs.writeFile()
or stream pipe

Because files ARE just bytes.

yes it is that simple 😭

SUPER IMPORTANT UNDERSTANDING

A file is NOT special.

A file is just:

Raw bytes + metadata

Example:

cat.png

is just:

[bytes] stored on disk

now this is how you implment multer code

first : Install Multer

npm install multer

Step 2: Basic Express Setup

like Create a server.js file and write this code inside it

Code:

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

const app = express();

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

Step 3: Create Uploads Folder

Inside project create a /uploads folder (basically here we are going to save the data)

project/
│
├── uploads/
├── server.js
└── package.json

inshort: This (/uploads) folder stores uploaded files.

Step 4: Basic Multer Setup

as u can sence the multer is a function and we are destcting it and giving the dest paramter a value

const upload = multer({
  dest: "uploads/"
});

this is Very basic configuration.

What dest Does ?

it just say store data inside uploads

dest: "uploads/"

means:

"Store uploaded files inside uploads folder"

Step 5: Single File Upload

app.post("/upload", upload.single("image"), (req, res) => {
  res.send("File uploaded");
});

first Understanding upload.single()

upload.single("image")

it means:

Accept only one file from frontend
frontend Input field name must be "image"

this is how Frontend HTML Form look likes

<form action="/upload" method="POST" enctype="multipart/form-data">

  <input type="file" name="image" />

  <button type="submit">
    Upload
  </button>

</form>

Important thing to notice:

enctype

This is very critical

enctype="multipart/form-data"

Without this File upload fails.

after all this thing Uploaded file appears inside uploads/

Example:

8f3a12d8a91b2c.png

Multer auto-generates random names by default.

this is how you Access Uploaded File Info

After upload req.file contains file metadata.

Example:

console.log(req.file);

Example req.file Object

{
  fieldname: 'image',
  originalname: 'photo.png',
  encoding: '7bit',
  mimetype: 'image/png',
  destination: 'uploads/',
  filename: 'a83b12d81.png',
  path: 'uploads/a83b12d81.png',
  size: 12000
}

Step 6: Custom Storage Configuration

Basic dest works

But usually developers need:

Custom names
Better folder control

Use:

diskStorage()

Custom Storage Setup

const storage = multer.diskStorage({

  destination: function (req, file, cb) {
    cb(null, "uploads/");
  },

  filename: function (req, file, cb) {
    cb(null, Date.now() + "-" + file.originalname);
  }

});

first Understand destination()

destination(req, file, cb)

its just work same as dest it define where the folder should be kept

second think to notice is Understanding filename()

filename(req, file, cb)

so using this we can make your own custom file name

Use Date.now()

because Without unique naming:

image.png
image.png
image.png

Files might overwrite each other.

Using Date.now() prevents collisions.

Connect Storage to Multer

const upload = multer({
  storage: storage
});

Complete Single Upload Example

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

const app = express();

const storage = multer.diskStorage({

  destination: function (req, file, cb) {
    cb(null, "uploads/");
  },

  filename: function (req, file, cb) {
    cb(null, Date.now() + "-" + file.originalname);
  }

});

const upload = multer({ storage });

app.post("/upload", upload.single("image"), (req, res) => {

  console.log(req.file);

  res.send("Upload successful");

});

app.listen(3000);

Multiple File Uploads

Sometimes users upload multiple files.

Example:

Product gallery
Multiple PDFs
Photo collections

Use upload.array() it basically help to take multiple file from frontend

Example

app.post("/uploads", upload.array("images", 5), (req, res) => {

  console.log(req.files);

  res.send("Files uploaded");

});

upload.array("images", 5)

basically means:

Field name = "images"
Maximum 5 files

Frontend will handle it like this

<input type="file" name="images" multiple />

for accessing Single upload we can use req.file

but for Multiple uploads we can use req.files

because files become an array

3) Uploading Different Fields

so now comes when the user upload data from diff types like JPG , PNG , pdf ,etc so to handle that we can use upload.fields()

Example

app.post("/profile", upload.fields([
  { name: "avatar", maxCount: 1 },
  { name: "resume", maxCount: 1 }
]), (req, res) => {

  console.log(req.files);

  res.send("Uploaded");

});

this is how u can access it

req.files.avatar
req.files.resume

File Validation

Very important.

now there are some precaution u can take like Never trust uploads blindly.

1) Restrict File Types

in this only certain file type are allowed to be entered into the server

this is how u can implement that

const fileFilter = (req, file, cb) => {

  if (file.mimetype.startsWith("image")) {
    cb(null, true);
  }

  else {
    cb(new Error("Only images allowed"));
  }

};

Connect Filter

const upload = multer({
  storage,
  fileFilter
});

File Size Limits

2) Prevent huge uploads.

see the stoarage has a limit and if user uplaod data which is in high amount there is a huge possiblity that stoarage limit will get hit so to restrict that we can use limits

like this

const upload = multer({
  storage,

  limits: {
    fileSize: 5 * 1024 * 1024
  }

});

5MB limit

3) Serving Uploaded Files

Uploading alone is not enough

Browser must access files too then we can use the express.static() function

any folder name passed inside static the data inside that folder will be accessable to the user

app.use("/uploads", express.static("uploads"));

Access File via URL

Suppose file:

uploads/photo.png

URL:

http://localhost:3000/uploads/photo.png

Now browser can open uploaded image.

Folder Structure

project/
│
├── uploads/
│   ├── image1.png
│   ├── image2.jpg
│
├── server.js
└── package.json

Common Multer Methods

Method	Purpose
single()	One file
array()	Multiple files
fields()	Multiple named fields
none()	Only text fields
any()	Accept all files

What is upload.any() ?

upload.any() accepts every uploaded file.

really Not recommended for beginners like there will be so many issue u cannot imagine stik to the traditional part

Common Beginner Mistakes

1. Forgetting uploads Folder

Multer cannot save files without giving a proper place to store it

2. Wrong Field Name

Frontend:

name="photo"

Backend:

upload.single("image")

Upload will fails.

Names must match.

3. Missing enctype

( ooh i have done this so many times)

Without multipart/form-data file upload breaks.

rember this properly

4. Forgetting express.static()

Files upload successfully but URLs fail.

5. Using Original Filenames

( atleast use Date.now()) dont be lazy

Upload Flow Diagram

User Selects File
        ↓
Browser Sends multipart/form-data
        ↓
Multer Middleware Executes
        ↓
File Saved in uploads/
        ↓
req.file Created
        ↓
Route Handler Executes
        ↓
Response Sent Back

Final Understanding

Multer is middleware that helps Express handle:

multipart/form-data

It processes uploaded files, stores them, and makes file metadata available inside request objects.

so this is the end of the blog if u liked the blog with comment it down and if there is something bad just let me know

and also like the blog follow for more such blog

bye bye

Storing Uploaded Files and Serving Them in Express

Shivam Yadav — Fri, 08 May 2026 11:56:17 +0000

yooo its me shivam

and today we are going to talk about file uploads yessss

it might sound a piece of shit topic but it is hard okay so lets start 😭

first lets start with frontend and backend flow

frontend send the file to the backend

backend receives

thing to be handled:

taking the data properly (and when i say data i mean file)
after that store them properly
and in the end serve that data to the user properly

okay this is the main goal

first let understand one thing

and that is how the data will come from frontend to backend

Normal HTTP requests usually send:

{
  "name": "shivam"
}

This is easy.

But files are NOT text.

A PNG file is raw binary bytes:

89 50 4E 47 ...

So browsers needed a special way to send everything in proper way:

text
files
metadata

all together in ONE request.

and that will be done using:

`multipart/form-data`

why called multipart?

because it contain multi form data 😭

yes this is why it is called like that

Example

Part 1 → username

Part 2 → image file

Part 3 → another field

Each part is separated by using a special string called:

Boundary

like for example

When browser sends:

const form = new FormData();

form.append("username", "shivam");
form.append("image", file);

The browser internally creates something like:

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKit123

this is how the body look like

------WebKit123
Content-Disposition: form-data; name="username"

shivam

------WebKit123
Content-Disposition: form-data; name="image"; filename="cat.png"
Content-Type: image/png

<binary file bytes here>

------WebKit123--

Now Let’s Break This Down

Part 1

------WebKit123
Content-Disposition: form-data; name="username"

shivam

This means:

{
  username: "shivam"
}

Part 2 (File)

------WebKit123
Content-Disposition: form-data; name="image"; filename="cat.png"
Content-Type: image/png

This is metadata.

It tells:

field name = image
filename = cat.png
mime type = image/png

Then comes:

(binary bytes)

Actual file data.

How Data Actually Travels

HTTP body travels as STREAMS

NOT like a giant packet.

Instead:

Chunk 1
Chunk 2
Chunk 3
Chunk 4

Like:

------WebKit123
Content-Dispo

then:

sition: form-data;

then:

name="image"

Everything arrives gradually.

Node.js Receives It as Stream

Inside Node.js req is actually a readable stream.

You can literally do:

req.on("data", chunk => {
   console.log(chunk);
});

Example you may see:

<Buffer 2d 2d 2d 2d 57 65 62 4b>

These are raw bytes.

now the best part comes

how a developer should handle this

see express is not having anything inbuilt to handle this

but there is one module:

`multer`

it helps us convert that raw bit into proper data

kinda like this:

{
  fieldname: 'image',
  originalname: 'cat.png',
  encoding: '7bit',
  mimetype: 'image/png',
  destination: 'uploads/',
  filename: 'a8f91c.png',
  path: 'uploads/a8f91c.png',
  size: 34567
}

let see how multer does that

multer parse this stream manually like:

Reads chunks
Detects boundaries
Separates parts
Reads headers
Extracts metadata
Writes file bytes to disk

How File Is Recreated

Suppose multer extracts:

89 50 4E 47 ...

(this data is after cleaning all the other data this is only the file data)

These are PNG bytes.

It simply writes them into a file using:

fs.writeFile()
or stream pipe

Because files ARE just bytes.

yes it is that simple 😭

SUPER IMPORTANT UNDERSTANDING

A file is NOT special.

A file is just:

Raw bytes + metadata

Example:

cat.png

is just:

[bytes] stored on disk

now this is how the multer code looks like

Backend Setup

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

const app = express();

const storage = multer.diskStorage({
  destination: function (req, file, cb) {
    cb(null, "uploads/");
  },

  filename: function (req, file, cb) {
    cb(null, Date.now() + "-" + file.originalname);
  }
});

const upload = multer({ storage: storage });

app.post("/upload", upload.single("image"), (req, res) => {
  console.log(req.file);

  res.send("File uploaded");
});

app.listen(3000);

Understanding `upload.single("image")`

This means:

expect ONE file
field name should be "image"

Frontend looks like this:

<input type="file" name="image" />

must match exactly.

lets understand this code

first there is:

multer.diskStorage()

this means what it says:

going to store on disk 😭

this code specify the destination

here it is /uploads folder

destination: function (req, file, cb) {
  cb(null, "uploads/");
}

then comes filename

(just give a name to that file)

filename: function (req, file, cb) {
  cb(null, Date.now() + "-" + file.originalname);
}

then passing that into multer function

and in the end using it as middleware like:

upload.single("image")

req.file

and one more thing

in the next route handler u can access the file using:

req.file

it contains:

{
  fieldname: 'image',
  originalname: 'cat.png',
  mimetype: 'image/png',
  destination: 'uploads/',
  filename: '8f91c.png',
  path: 'uploads/8f91c.png',
  size: 34567
}

Multer creates this object manually.

everything in short

`destination`

Defines where files will be stored.

uploads/

`filename`

Creates unique file names.

Example:

171523432-photo.png

This prevents filename collisions.

Without unique names:

image.png
image.png
image.png

Files would overwrite each other.

Creating Upload Middleware

const upload = multer({ storage });

Upload Route

app.post("/upload", upload.single("image"), (req, res) => {
  res.send("File uploaded successfully");
});

Understanding `upload.single()`

upload.single("image")

This means:

Expect one file
Field name must be "image"

Frontend:

<input type="file" name="image" />

Names must match.

Folder Structure After Upload

project/
│
├── uploads/
│   ├── 171523432-profile.png
│   └── 171523500-resume.pdf
│
├── server.js
└── package.json

Visual Flow

Browser Request
       ↓
/uploads/photo.png
       ↓
Express Static Middleware
       ↓
Find File in uploads Folder
       ↓
Return File Response

now one of the best parts

storing that file 😭

we have two option whenever it comes to storing any file

Local Storage
External Storage

1. Local Storage

Files are stored directly inside the server filesystem.

Example structure:

project/
│
├── uploads/
│   ├── image1.png
│   ├── profile.jpg
│   └── resume.pdf
│
├── server.js
└── package.json

The uploaded file physically exists inside the project folder.

2. External Storage

Instead of storing files on the server:

Files are stored in external services like:

AWS S3
Cloudinary
Firebase Storage
DigitalOcean Spaces

Flow:

User Upload
     ↓
Express Server
     ↓
Cloud Storage

The Problem After Uploading

Now files exist on the server.

But users still cannot access them from browser.

Why?

Because Express does NOT expose folders automatically.

Serving Static Files in Express

To make uploaded files accessible:

Use:

express.static()

Static File Serving

app.use("/uploads", express.static("uploads"));

This line is extremely important.

It tells Express:

"Serve files inside uploads folder publicly"

How Static Serving Works

Suppose file exists:

uploads/photo.png

Now browser can access:

http://localhost:3000/uploads/photo.png

Express automatically serves the file.

Important Security Considerations

File uploads are dangerous if handled carelessly 😭

Never trust uploaded files blindly.

1. Validate File Types

Users may upload:

virus.exe
malware.js
dangerous.php

Instead of images.

Use file filtering.

Example:

const fileFilter = (req, file, cb) => {
  if (file.mimetype.startsWith("image")) {
    cb(null, true);
  } else {
    cb(new Error("Only images allowed"));
  }
};

2. Limit File Size

Huge uploads can crash servers.

Example:

const upload = multer({
  storage,
  limits: {
    fileSize: 5 * 1024 * 1024
  }
});

5MB limit.

3. Rename Uploaded Files

Never trust original filenames.

Bad:

myvirus.exe

Good:

171523432-file.png

4. Avoid Executable Uploads

Never allow:

.exe
.bat
.sh
.php

These may become security risks.

5. Store Sensitive Files Privately

Not all uploads should be public.

Examples:

Aadhaar cards
Passports
Medical documents

These should NOT use public static serving.

Instead:

Store privately
Add authentication before access

Public vs Private File Access

Public Access

/uploads/image.png

Anyone with URL can access it.

Used for:

Product images
Profile photos
Blog thumbnails

Private Access

but only this it require is authorization 😭

Example flow:

User Login
    ↓
Authentication Check
    ↓
Server Sends File

Used for sensitive documents.

final flow of working

High-Level Upload Flow

User Selects File
        ↓
Frontend Sends Multipart Request
        ↓
Multer Processes File
        ↓
File Stored in uploads/
        ↓
Express Static Middleware Exposes File
        ↓
Browser Accesses File via URL

one thing i did not talk about

when we store data on external provider so how user will get that data?

best thing is:

when u upload user file to that provider that provider gives u a URL of that image

so u just need to send that to frontend

and that URL can be inside image tag

then u can see it 😭

so everything is done:

how to take the data
how to store it
how to give it back to the user

so i think this is the end

if u like the blog please let me know in comment

and like the blog

and subscribe me 😭

i have alot of knowledge i want to share

so if u want to be part of it then subscribe