DEV Community: Shivam Yadav

How Instagram Stores Reels, Photos, and Drafts Behind the Scenes

Shivam Yadav — Sun, 31 May 2026 17:26:12 +0000

Imagine recording a 30-second Reel on Instagram.

You spend several minutes adding music, trimming clips, applying filters, and writing a caption. Just before posting, your phone battery drops to 2%.

You decide to save the Reel as a draft and close the app.

The next day, you open Instagram again and your draft is still there exactly as you left it.

How does that happen?

Where are the video files stored?

Why don't drafts disappear when the app restarts?

How does Instagram handle millions of photos and videos uploaded every day while still providing a fast user experience?

In this article, we'll explore the architecture and system design concepts behind how social media applications like Instagram manage media storage, drafts, uploads, caching, and content delivery.

Why Social Media Apps Need Efficient Media Storage

Unlike messaging apps that mostly deal with text, social media platforms are heavily media-driven.

Every day users upload:

Photos
Reels
Stories
Videos
Profile pictures
Live stream recordings

A single high-quality video can easily consume hundreds of megabytes.

Now imagine millions of users uploading content simultaneously.

Without efficient storage systems, the platform would face:

High storage costs
Slow uploads
Increased bandwidth usage
Poor user experience
Device storage issues

This is why modern social media applications invest heavily in storage architecture and media optimization.

The goal is simple:

Store large amounts of media efficiently while keeping the app fast and responsive.

The Journey of Recording a Reel

Let's start with a common scenario.

A user records a Reel.

At this moment, the video exists only on the device.

The platform has not received anything yet.

The process usually looks like this:

Record Reel
      |
      v
Store Locally
      |
      v
Edit Content
      |
      v
Save Draft
      |
      v
Upload Later
      |
      v
Cloud Storage
      |
      v
View By Other Users

Understanding this journey helps explain most of the architecture behind media-heavy applications.

How Photos and Videos Are Stored Before Upload

When you record a Reel or select a photo from your gallery, the media is first stored locally on your device.

This is important because uploading begins only after the user confirms the post.

Imagine recording a 2-minute Reel.

Uploading immediately while editing would create problems:

Wasted bandwidth
Unfinished uploads
Frequent upload cancellations
Poor user experience

Instead, the application stores the media locally while the user edits it.

The stored media may include:

Original video
Edited version
Selected music
Filters
Captions
Metadata

Everything remains on the device until the user decides to publish.

Why Media Is Stored Locally First

There are several reasons.

Faster User Experience

Reading files from device storage is much faster than continuously communicating with a remote server.

Offline Support

Users can continue editing without internet access.

Reduced Network Usage

Only finalized content gets uploaded.

Better Reliability

If the network disconnects, work is not lost.

The app behaves as if everything is happening instantly because most operations are occurring locally.

What Happens When a User Saves a Draft

Saving a draft is one of the most useful features in social media applications.

When the user taps "Save Draft," the application stores:

Media files
Editing information
Captions
Selected filters
Audio choices
Upload settings

The content is usually written into local storage.

Conceptually:

Draft
 ├── Video File
 ├── Caption
 ├── Music Selection
 ├── Filters
 ├── Timestamp
 └── Draft ID

The draft becomes a recoverable project.

Instead of storing only the final video, the app preserves enough information to recreate the editing session.

How Drafts Survive App Restarts

Many beginners assume drafts remain in memory.

That would be risky.

Memory is cleared when:

The app closes
The phone restarts
The operating system kills the app

Instead, drafts are saved to persistent local storage.

Possible storage systems include:

SQLite databases
Device file system
Realm database
Internal app storage

Because the data exists on disk, it survives app restarts.

The next time the application launches, it simply reloads draft information from storage.

Local Storage vs Cloud Storage

One of the most important concepts in modern applications is understanding the difference between local and cloud storage.

Local Storage

Stored directly on the user's device.

Examples:

Drafts
Cached images
Temporary files
Downloaded content

Advantages:

Fast access
Works offline
Lower latency

Disadvantages:

Limited space
Data can be lost if app data is deleted

Cloud Storage

Stored on remote servers.

Examples:

Uploaded posts
Reels
Stories
User media archives

Advantages:

Accessible anywhere
Highly scalable
Reliable backups

Disadvantages:

Requires internet
Higher latency than local storage

Local Storage vs Cloud Storage Architecture

               User Device
                     |
       ---------------------------
       |                         |
       v                         v

 Local Storage             Cloud Storage

 Drafts                    Reels
 Cached Images             Photos
 Temporary Files           Stories
 Offline Data              User Uploads

Modern applications combine both approaches to achieve the best user experience.

Uploading Large Media Files Efficiently

Uploading large videos is challenging.

Imagine uploading a 500 MB Reel.

Problems include:

Network interruptions
Upload failures
Slow mobile connections
Battery consumption

Uploading the entire file in one request would be risky.

Instead, platforms often break uploads into smaller chunks.

Example:

Video File
      |
      v

Chunk 1
Chunk 2
Chunk 3
Chunk 4
Chunk 5

If the connection drops after Chunk 3, the upload can resume from Chunk 4 rather than starting over.

This dramatically improves reliability.

Media Processing and Compression

Raw media files are enormous.

A video recorded on a modern smartphone may be hundreds of megabytes.

Storing millions of such videos would be extremely expensive.

Before upload or after reaching the server, media is usually compressed.

Compression reduces:

File size
Storage requirements
Bandwidth usage
Loading times

The goal is finding a balance between:

Quality
Storage cost
Network performance

This is why uploaded videos often appear slightly different from the original recording.

Thumbnail Generation and Previews

When scrolling through Instagram, you see previews before opening a Reel.

These previews come from thumbnails.

A thumbnail is a small image generated from a video.

Example:

Video
  |
  v

Generate Thumbnail
  |
  v

Preview Image

Benefits include:

Faster loading
Lower bandwidth usage
Better browsing experience

Instead of downloading a full video, users initially receive only a lightweight preview image.

Media Upload and Processing Pipeline

A simplified version of the upload pipeline looks like this:

Record Media
      |
      v
Store Locally
      |
      v
Save Draft
      |
      v
Upload
      |
      v
Media Processing
      |
      v
Compression
      |
      v
Thumbnail Generation
      |
      v
Cloud Storage
      |
      v
Available To Viewers

Each stage helps optimize storage and performance.

Caching Frequently Viewed Content

Imagine opening Instagram and repeatedly viewing the same Reel.

Downloading it every time would be inefficient.

Instead, applications use caching.

A cache is temporary storage used for quick access.

Example:

User Watches Reel
        |
        v
Store In Cache
        |
        v
Watch Again
        |
        v
Load From Cache

Because the media already exists on the device, loading becomes much faster.

Benefits of Caching

Caching improves:

Speed
Battery efficiency
Network usage
User experience

Users often perceive cached content as "instant."

In reality, the app is simply avoiding another network request.

Cache Lifecycle

Download Content
        |
        v
Store In Cache
        |
        v
Reuse Frequently
        |
        v
Cache Expiration
        |
        v
Remove Old Content

Applications continuously clean old cache entries to free storage space.

Content Delivery Using CDNs

Suppose a creator uploads a Reel in India.

Now users from:

India
Japan
Germany
Brazil
United States

all want to watch it.

Serving every request from a single server would be slow.

This is where Content Delivery Networks (CDNs) become important.

A CDN stores copies of media across multiple geographical locations.

Instead of downloading from one central server, users receive content from a nearby location.

CDN-Based Content Delivery Flow

Creator Uploads Reel
          |
          v
Cloud Storage
          |
          v
CDN Replication
          |
    ------------------
    |       |       |
    v       v       v

India   Europe   America
 Server  Server   Server
    |       |       |
    --------|--------
            |
            v
          Viewer

This reduces:

Latency
Loading times
Server load

and improves viewing performance worldwide.

Managing Storage, Performance, and User Experience

Social media applications constantly balance three competing goals:

Storage Efficiency

Store massive amounts of content economically.

Performance

Load content quickly and smoothly.

User Experience

Make everything feel instant and reliable.

Achieving all three simultaneously requires:

Local storage
Draft management
Compression
Caching
Cloud storage
CDN distribution

These systems work together behind the scenes every time a user records, saves, uploads, or watches content.

Why This Architecture Matters

Users expect social media apps to feel seamless.

They don't want to think about:

Upload pipelines
Cloud storage
Compression algorithms
CDN networks

They simply expect:

Drafts to remain safe
Videos to upload successfully
Reels to load quickly
Content to be available everywhere

The architecture exists to make those expectations possible.

Conclusion

When you record a Reel, save a draft, upload a video, or scroll through your feed, a complex storage architecture is working behind the scenes. Media is first stored locally, drafts are persisted on the device, uploads are optimized through compression and chunking, cloud storage preserves content permanently, CDNs distribute media globally, and caches ensure frequently viewed content loads instantly.

This combination of local storage, cloud infrastructure, media processing, caching, and content delivery allows modern social media platforms like Instagram to handle billions of photos and videos while maintaining a fast and reliable user experience. The next time you save a Reel draft and find it waiting for you the next day, you'll know that a carefully designed storage system made it possible.

How WhatsApp Works Without Internet: Offline Messaging and Synchronization Explained

Shivam Yadav — Sun, 31 May 2026 17:24:25 +0000

Imagine you're traveling on a flight with airplane mode enabled. You type a message to your friend:

"Hey, I just landed. Will call you soon."

You tap Send, and surprisingly the message immediately appears in your chat window. There is no internet connection, yet the message seems to have been sent.

How is that possible?

The answer lies in a design approach called offline-first architecture, where applications are designed to work even when network connectivity is unavailable. Modern messaging applications such as WhatsApp, Telegram, Signal, and Messenger rely heavily on this concept to provide a smooth user experience.

In this article, we'll explore what happens behind the scenes when you send messages without internet and how those messages eventually reach the recipient once connectivity returns.

Why Messaging Apps Need Offline Support

Internet connectivity is not always reliable.

Users may experience:

Airplane mode
Weak mobile networks
Temporary signal loss
Wi-Fi disconnections
Underground travel
Network congestion

If messaging applications depended entirely on a live internet connection, users would constantly encounter errors and failed actions.

Instead, modern messaging platforms are designed to continue functioning locally and synchronize changes later.

This provides several benefits:

Faster user experience
Better reliability
Reduced frustration
Consistent interface behavior
Ability to continue using the app even during network interruptions

The goal is simple:

Let users continue their work immediately and handle synchronization in the background.

A Simple Scenario: Sending a Message in Airplane Mode

Let's walk through a real-world example.

Suppose Alice opens WhatsApp while her phone is in airplane mode.

She sends:

"Are we meeting tomorrow?"

Although the device has no internet access, several things happen internally.

Step 1: Message Is Created Locally

The moment Alice presses the send button, the application creates a message object.

It may contain:

Message ID
Sender ID
Chat ID
Message content
Timestamp
Current status

Example:

{
  "id": "msg_101",
  "text": "Are we meeting tomorrow?",
  "sender": "Alice",
  "timestamp": "10:15 AM",
  "status": "pending"
}

At this stage, the message exists only on Alice's device.

The server has not seen it yet.

Step 2: Message Is Stored in Local Storage

The app immediately saves the message in local storage.

This local database could be:

SQLite
Realm
MMKV
Core Data (iOS)
Room Database (Android)

The purpose is persistence.

Even if:

The app crashes
The phone restarts
The battery dies

the message remains safely stored.

Why Local Storage Is Important

Without local storage:

User sends message
Phone loses power
Message disappears forever

With local storage:

User sends message
Message is saved locally
Device restarts
Message still exists

This creates a reliable experience.

Step 3: Message Appears Instantly in the Chat

This is the part users notice.

The message instantly shows up in the conversation.

Why?

Because the application displays data from local storage rather than waiting for server confirmation.

From the user's perspective:

You: Are we meeting tomorrow?
✓ Sending...

The app is essentially saying:

"I have recorded your message. I'll deliver it when possible."

This creates the illusion of immediate responsiveness.

Message Queueing on the Device

Now the message enters a queue.

A queue is simply a list of pending actions waiting to be processed.

Example:

Queue

1. Message A
2. Message B
3. Message C

Since there is no internet connection, these messages cannot reach the server.

Instead, they wait patiently inside the queue.

Offline Message Queue Lifecycle

User Sends Message
         |
         v
Saved Locally
         |
         v
Added To Queue
         |
         v
Waiting For Internet
         |
         v
Connection Restored
         |
         v
Sent To Server
         |
         v
Queue Removed

This queue is one of the most important parts of offline messaging systems.

What Happens When Internet Returns?

Eventually Alice reconnects to Wi-Fi.

The app detects connectivity.

A synchronization process begins.

The sync engine:

Reads pending messages
Processes them in order
Sends them to the server
Waits for acknowledgments
Updates message status

This entire process usually happens automatically.

Users often don't even notice it.

Synchronization Flow

Phone Reconnects
       |
       v
Sync Engine Starts
       |
       v
Read Pending Messages
       |
       v
Send To Server
       |
       v
Receive Confirmation
       |
       v
Update Local Database

The user simply sees status indicators changing.

Understanding Delivery States

Messaging applications use message states to inform users about delivery progress.

These states help answer an important question:

"Has my message reached the other person?"

1. Pending

The message exists only on the sender's device.

Example:

⏳ Sending...

This often happens while offline.

2. Sent

The server has received the message.

✓ Sent

The message successfully left the sender's device.

However, the recipient may not have received it yet.

3. Delivered

The recipient's device has received the message.

✓✓ Delivered

Now the message exists on both devices.

4. Read

The recipient has opened the conversation and viewed the message.

✓✓ Read

This state is usually updated after the recipient's app sends a read acknowledgment.

Message State Transition Diagram

Pending
   |
   v
Sent
   |
   v
Delivered
   |
   v
Read

Each transition represents successful communication between devices and servers.

Handling Media Uploads While Offline

Text messages are relatively small.

Photos, videos, and documents are different.

A video may be:

20 MB
100 MB
500 MB

Uploading such files requires special handling.

Offline Media Workflow

When a user sends media while offline:

File is stored locally
Upload task is created
Upload enters queue
App waits for connectivity
Upload begins later

Example:

Photo Selected
       |
       v
Saved Locally
       |
       v
Upload Queued
       |
       v
Internet Returns
       |
       v
Upload Starts

Users typically see:

Uploading...
Waiting for connection...

until synchronization occurs.

Conflict Resolution

Offline systems introduce a new challenge.

What if multiple changes happen before synchronization?

Consider this example.

Alice changes a group name while offline.

Bob changes the same group name online.

Now two different versions exist.

Which one should win?

This is called a conflict.

Common Conflict Resolution Strategies

Last Write Wins

The most recent update replaces older versions.

Example:

Alice: Study Group
Bob: Final Project Group

If Bob's change arrived later:

Final Project Group

becomes the final value.

Server Authority

The server decides which update is correct.

Clients accept the server's version.

Merge Strategy

Used in more complex systems.

Both changes are combined when possible.

Messaging apps generally avoid complicated conflicts by keeping operations simple.

Message Ordering

Suppose three messages are sent offline.

Message 1
Message 2
Message 3

When connectivity returns, they should appear in the same order.

Maintaining order is critical because conversations depend on sequence.

Apps typically use:

Timestamps
Sequence numbers
Server ordering mechanisms

to ensure conversations remain readable and consistent.

Eventual Consistency Explained Simply

One important concept behind synchronization systems is eventual consistency.

This means:

Different devices may temporarily show different data, but they will eventually become consistent after synchronization.

Example:

Initially:

Alice Device:
Hello
How are you?

Bob Device:
Hello

After synchronization:

Alice Device:
Hello
How are you?

Bob Device:
Hello
How are you?

Both devices now contain the same information.

The system was temporarily inconsistent but eventually became consistent.

That is why the concept is called eventual consistency.

Why Messages Appear Instantly Even When Offline

Many users assume their message has already reached the server.

In reality, the application is simply showing locally stored data.

The sequence is:

User Sends Message
       |
       v
Stored Locally
       |
       v
Displayed Immediately
       |
       v
Network Sync Happens Later

This approach dramatically improves perceived performance.

Users feel the application is fast because they receive immediate visual feedback.

Reliability vs Real-Time Delivery

There is always a tradeoff.

Prioritizing Real-Time Delivery

Advantages:

Faster communication
Instant updates

Disadvantages:

Fails during connectivity loss
Poor user experience

Prioritizing Reliability

Advantages:

Works offline
Prevents data loss
Better user experience

Disadvantages:

Synchronization complexity
Temporary delays

Modern messaging apps attempt to balance both goals.

How Offline-First Architecture Improves Usability

Offline-first architecture focuses on the user experience rather than the network.

The philosophy is:

Assume the network may fail at any moment.

Benefits include:

Faster interface response
Better reliability
Reduced user frustration
Improved battery efficiency
Safer data persistence
Smooth recovery after disconnections

This is one of the reasons messaging applications feel seamless even in poor network conditions.

Conclusion

When you send a WhatsApp message without internet, the message is not magically transmitted. Instead, the application stores it locally, displays it immediately, and places it inside a queue waiting for connectivity.

Once the internet becomes available, a synchronization engine uploads pending messages, updates delivery states, handles media transfers, and ensures conversations remain consistent across devices.

This approach is known as offline-first architecture and is one of the most important design principles behind modern messaging applications. By combining local storage, message queues, synchronization mechanisms, and eventual consistency, apps can provide a reliable and responsive experience even when networks are unreliable.

The next time you send a message in airplane mode and see it appear instantly, remember that a sophisticated synchronization system is quietly working behind the scenes, waiting for the perfect moment to deliver your message.

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 😭