DEV Community: Shivam Yadav

How ChatGPT Understands Your Questions

Shivam Yadav — Wed, 01 Jul 2026 15:33:55 +0000

From Words to Tokens: Understanding How Large Language Models Think

Every day, millions of people ask ChatGPT questions like:

"Write me a React application."

"Explain recursion like I'm five."

"Help me prepare for my interview."

Within a few seconds, ChatGPT responds with what often feels like a thoughtful answer.

But have you ever wondered:

How does ChatGPT actually understand your question?

Does it search Google?

Does it have every webpage memorized?

Does it understand English the way humans do?

The answer is fascinating.

Behind every response is a series of mathematical operations that convert your words into numbers, analyze relationships between those numbers, and predict what should come next.

At the center of this process are three important ideas:

Large Language Models (LLMs)
Tokenization
Transformers

In this article, we'll explore how ChatGPT processes your questions—from the moment you press Enter until you receive a response.

You don't need any background in AI or machine learning. We'll keep everything beginner-friendly and focus on understanding the concepts rather than complex mathematics.

What is an LLM?

LLM stands for:

Large Language Model

Let's understand each word.

Large

These models are trained using enormous amounts of text from books, articles, documentation, websites, research papers, and publicly available sources.

The word large also refers to the enormous number of parameters (internal values learned during training) that help the model recognize patterns in language.

Language

The model works with human language.

Examples include:

English
Hindi
Spanish
Japanese
Programming languages like JavaScript and Python

Language is simply the information the model learns to process.

Model

A model is a mathematical system that has learned patterns from training data.

Instead of memorizing exact answers, it learns relationships such as:

Which words commonly appear together
How sentences are structured
How ideas connect
How conversations usually flow

This allows the model to generate new responses instead of repeating stored ones.

What Problems Do LLMs Solve?

LLMs are designed to understand and generate human language.

They help with tasks like:

Answering questions
Writing emails
Summarizing documents
Translating languages
Explaining concepts
Generating code
Fixing bugs
Brainstorming ideas

Instead of building separate AI systems for every language task, one large model can perform many of them.

Popular Examples of LLMs

Today, several organizations have built powerful LLMs.

Some well-known examples include:

ChatGPT
Gemini
Claude
Llama
Mistral
DeepSeek

Although they differ in training methods and capabilities, most modern LLMs are based on the same fundamental Transformer architecture.

Common Applications in Daily Life

Even if you don't realize it, you've probably already interacted with LLMs.

Examples include:

AI chatbots
Coding assistants
Smart email writing
Customer support bots
AI search engines
Document summarization
Language translation
Meeting note generation

As AI becomes more common, LLMs are becoming part of everyday software.

What Happens When You Send a Message to ChatGPT?

Let's imagine you type:

Explain React Hooks simply.

What happens next?

Many people think ChatGPT searches the internet and copies an answer.

That isn't how it normally works.

Instead, several processing steps occur.

Step 1: You Type a Prompt

Everything begins with your prompt.

Example:

Explain React Hooks simply.

The prompt becomes the input for the model.

Step 2: Your Message Is Processed

The model cannot work directly with human-readable text.

Before any reasoning begins, your message is prepared for the AI system.

This involves:

Breaking text into smaller pieces
Converting those pieces into numbers
Sending those numbers into the neural network

We'll soon see why this conversion is necessary.

Step 3: The Model Generates a Response

The model predicts the most appropriate next token repeatedly until the response is complete.

It doesn't generate the entire paragraph at once.

Instead, it predicts:

First token

↓

Second token

↓

Third token

↓

...

↓

Final response

One token at a time.

Does ChatGPT Copy Answers From the Internet?

A common misconception is that ChatGPT searches websites and copies information.

Generally, that's not how it works.

During normal conversations, the model generates responses based on patterns it learned during training.

It predicts likely continuations rather than retrieving and copying documents.

Some AI systems can also use external tools such as web search, but language generation itself is still handled by the model.

Why Computers Don't Understand Human Language

Humans naturally understand words.

Computers do not.

For a computer:

Hello

is not meaningful.

Neither is:

JavaScript

React

A computer only understands numbers.

Everything—including text, images, audio, and video—must eventually be represented numerically.

Text vs Numbers

Imagine you ask:

What is React?

Humans instantly recognize:

"What"
"is"
"React"

A computer sees only characters.

Before it can process meaning, the text must become numbers.

This conversion is one of the first steps inside every LLM.

Introducing Tokens

You might think each word becomes one number.

Sometimes that's true.

But often it isn't.

Instead, language models break text into tokens.

A token is a small unit of text.

Depending on the word, a token might represent:

A whole word
Part of a word
A punctuation mark
A number
A special symbol

Tokens are the actual language units used by LLMs.

Why Tokenization Is Needed

Languages contain millions of unique words.

People also invent new words every day.

Rather than storing every possible word, tokenization breaks text into reusable pieces.

This makes processing much more efficient.

It also allows the model to understand unfamiliar words by combining smaller parts.

What Is Tokenization?

Tokenization is the process of splitting text into tokens.

Example:

Input:

I love programming.

Possible tokens:

[I]

[love]

[programming]

[.]

Each token is then converted into a numeric ID.

Words vs Tokens

One word is not always one token.

Example:

JavaScript

might become:

Java

Script

A longer word might be divided into several smaller pieces.

Even punctuation becomes tokens.

For example:

Hello!

may become:

Hello

!

This flexibility helps models efficiently process many different languages and writing styles.

A Simple Tokenization Example

Suppose you type:

I love AI.

The processing pipeline looks like this:

Input Text

↓

Tokens

↓

Numeric IDs

↓

AI Model

Notice that the model never directly works with the original sentence.

It works with numbers representing those tokens.

Why Tokens Matter

Every LLM has a context window, which limits how many tokens it can consider at once.

This is why prompts have length limits.

Long conversations, documents, and code are all measured in tokens rather than characters or words.

Understanding tokens helps explain:

Why prompts have limits
Why responses can stop
Why very long conversations eventually lose earlier context

Transformers: The Technology That Changed AI Forever

So far we've learned that ChatGPT doesn't read words directly.

Instead, your message goes through this process:

Your Message
      ↓
Tokenization
      ↓
Numbers

But what happens after the text becomes numbers?

This is where the real intelligence begins.

The technology responsible for this is called the Transformer.

If Large Language Models are the brain of modern AI, then the Transformer is the engine that makes that brain work.

Almost every major language model today—including ChatGPT, Gemini, Claude, Llama, Mistral, and DeepSeek—is built on the Transformer architecture.

What is a Transformer?

A Transformer is a deep learning architecture introduced in 2017 by researchers at Google in the famous paper:

"Attention Is All You Need."

Before Transformers, AI models struggled with understanding long sentences and maintaining context.

Transformers solved this problem by allowing models to understand relationships between words, regardless of how far apart they appear in a sentence.

Instead of reading text one word at a time, Transformers analyze the entire sequence together.

This was a major breakthrough in Natural Language Processing (NLP).

Why Transformers Changed AI

Earlier language models had several limitations:

They struggled with long paragraphs.
They often forgot information mentioned earlier.
Training was slower.
Parallel processing was difficult.

Transformers introduced a new way of processing language that made training much faster and improved understanding of context.

This single innovation enabled the creation of today's powerful LLMs.

Understanding Context

Let's look at a simple sentence:

The trophy didn't fit into the suitcase because it was too big.

What does "it" refer to?

The trophy?
The suitcase?

As humans, we understand that "it" refers to the trophy.

Why?

Because we understand the relationship between the words.

A Transformer tries to learn these relationships statistically during training.

Instead of looking at one word in isolation, it considers the surrounding context.

Thinking About Relationships

Imagine reading this sentence:

Shivam is learning React because he wants to build mobile apps.

When the model reaches the word "he", it needs to know who "he" refers to.

A Transformer learns that "he" is closely related to "Shivam."

Similarly, when it encounters "React," it recognizes that "mobile apps" is related to technologies often used in application development.

The model builds these relationships across the entire sentence.

The Idea of Attention

One of the biggest innovations in Transformers is something called Attention.

Think about how humans read.

When reading a sentence, we don't give every word equal importance.

Some words matter more than others.

Example:

The cat chased the mouse.

If someone asks:

Who chased the mouse?

You immediately focus on:

cat
chased
mouse

You ignore less important words.

Transformers try to do something similar.

They learn which words should receive more attention when predicting the next token.

This is why the architecture is called a Transformer based on the attention mechanism.

A Simple Analogy

Imagine you're reading a mystery novel.

On page 200, the author mentions a clue introduced on page 20.

You remember that earlier clue because it is important.

Similarly, a Transformer can learn that a word appearing much earlier in the input is still relevant to understanding the current word.

This ability to connect distant pieces of information is one of the reasons Transformers perform so well.

From Tokens to Understanding

Once your message has been tokenized, the Transformer processes all the tokens together.

At a high level, the workflow looks like this:

Input Text
      ↓
Tokenization
      ↓
Tokens
      ↓
Transformer
      ↓
Next Token Prediction
      ↓
Response

The Transformer doesn't "understand" language the way humans do.

Instead, it learns incredibly complex statistical patterns between tokens.

Predicting the Next Token

One of the most surprising facts about ChatGPT is that it doesn't generate an entire answer all at once.

Instead, it repeatedly asks itself:

"Given everything I've seen so far, what is the most likely next token?"

Suppose your prompt is:

React is a JavaScript...

The model predicts something like:

library

Now the sentence becomes:

React is a JavaScript library...

Next prediction:

for

Then:

building

Then:

user

Then:

interfaces

This process continues one token at a time until the response is complete.

What is a Context Window?

While generating a response, the model doesn't remember every conversation you've ever had.

Instead, it only considers a limited amount of recent information.

This limit is called the context window.

Think of it as the model's working memory.

Example:

Conversation

Message 1
Message 2
Message 3
Message 4
Message 5

──────────────
Context Window
──────────────

Everything inside the context window can influence the next response.

Older information may eventually fall outside this window if the conversation becomes very long.

Why Context Matters

Consider these two prompts.

Prompt 1:

Explain JavaScript.

Prompt 2:

Explain it again, but this time for beginners.

The second prompt only makes sense if the model remembers the first one.

Because both prompts are inside the context window, the model can connect them.

This is why conversations feel natural.

Temperature: Why AI Can Give Different Answers

Another interesting concept is temperature.

Temperature controls how predictable or creative the generated text is.

Think of it as a creativity dial.

Low Temperature

A low temperature makes the model choose the most likely next token.

Example:

Prompt:

What is HTML?

Possible response:

HTML is the standard markup language used to create web pages.

If you ask again, the answer will probably be very similar.

Low temperatures produce more consistent and deterministic outputs.

High Temperature

A higher temperature allows the model to consider less likely tokens.

Prompt:

Write a story about a robot.

Possible responses may vary significantly each time.

One response might be humorous.

Another might be emotional.

Another could become a science-fiction adventure.

Higher temperatures increase creativity but can also make responses less predictable.

Complete High-Level Workflow

Let's put everything together.

When you ask ChatGPT a question, this is what happens at a high level:

You Type a Prompt
        ↓
Text is Tokenized
        ↓
Tokens Become Numbers
        ↓
Transformer Processes Relationships
        ↓
Model Predicts Next Token
        ↓
Another Token
        ↓
Another Token
        ↓
Complete Response Generated

Every response follows this same overall process.

Why ChatGPT Feels Intelligent

ChatGPT often feels like it's reasoning the way humans do.

In reality, its responses come from learning patterns across enormous amounts of text during training.

It has learned:

Grammar
Sentence structure
Programming languages
Writing styles
Question-answer patterns
Logical relationships
Problem-solving patterns

Using those learned patterns, it predicts the next token repeatedly to construct a response.

This combination of large-scale training, tokenization, and Transformers is what creates the conversational experience we see today.

Key Takeaways

Let's quickly recap everything we've learned.

Large Language Models (LLMs)

LLMs are AI models trained to understand and generate human language.

They solve tasks such as answering questions, writing code, summarizing text, translating languages, and much more.

Tokenization

Computers cannot directly understand words.

They first split text into smaller units called tokens, then convert those tokens into numbers.

Transformers

Transformers analyze relationships between tokens using attention mechanisms.

This allows models to understand context and generate coherent responses.

Context Window

The context window represents the information currently available to the model while generating a response.

Longer context windows allow the model to remember more of the ongoing conversation.

Token Prediction

ChatGPT generates responses one token at a time.

Each new token is predicted based on all the tokens that came before it.

Final Thoughts

When you press Enter after typing a question, it may seem like ChatGPT instantly understands what you mean.

Behind the scenes, however, an incredible sequence of steps takes place.

Your words become tokens.

Tokens become numbers.

Those numbers flow through a Transformer model that analyzes relationships, context, and patterns learned during training.

Finally, the model predicts one token after another until a complete response appears on your screen.

Understanding this process doesn't just help you appreciate modern AI—it also helps you become a better prompt writer.

The better you understand how Large Language Models process information, the better you'll be able to communicate with them and unlock their full potential.

The next time ChatGPT answers your question, you'll know that it isn't searching the internet or copying text.

It's performing billions of mathematical operations to predict the most appropriate next token—one small piece at a time.

Mastering TypeScript: Interfaces, Generics, Unions Explained

Shivam Yadav — Tue, 30 Jun 2026 17:50:58 +0000

If JavaScript works, why was TypeScript created?

Imagine you're building a small calculator app using JavaScript. Everything works perfectly. You write a few functions, display some buttons, and you're done in a couple of hours.

Now imagine you're building something much larger—a banking application, an e-commerce platform like Amazon, or a social media platform like Instagram. Thousands of files. Hundreds of developers. Millions of users.

Suddenly, JavaScript starts showing its limitations.

A small mistake in one file might not be discovered until someone actually uses that feature. A function expecting a number might accidentally receive a string. A property name could be misspelled. An API might return unexpected data.

The browser won't complain until the code runs.

That's where TypeScript changes everything.

TypeScript doesn't replace JavaScript—it improves it. Think of it as a smart assistant that checks your code before it ever reaches the browser. It catches mistakes early, provides better tooling, and makes large projects much easier to maintain.

Today, TypeScript powers projects at companies like Microsoft, Google, Airbnb, Shopify, Discord, and countless startups. If you're learning modern web development with React, Next.js, Angular, or Node.js, TypeScript has become an essential skill.

In this article, we'll build a strong foundation by understanding:

Why TypeScript was created
How static typing works
Type annotations and type inference
Interfaces and type aliases
Union and intersection types
Generic functions
The purpose of tsconfig.json
How TypeScript becomes JavaScript

By the end, you'll understand not just how TypeScript works, but why developers around the world rely on it every day.

What is TypeScript?

TypeScript is an open-source programming language developed by Microsoft.

The simplest way to understand TypeScript is this:

TypeScript is JavaScript with an additional type system.

That means every valid JavaScript program is also a valid TypeScript program.

For example, this JavaScript code works perfectly in TypeScript:

function greet(name) {
return "Hello " + name;
}

console.log(greet("Shivam"));

TypeScript doesn't force you to rewrite everything. Instead, it lets you gradually add types whenever you need them.

Here's the same code written in TypeScript:

function greet(name: string): string {
return Hello ${name};
}

console.log(greet("Shivam"));

Notice the difference?

name: string

and

): string

These tell TypeScript:

The parameter name must be a string.
The function will always return a string.

These simple additions allow TypeScript to detect mistakes before your application even runs.

JavaScript vs TypeScript

Let's compare them side by side.

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

add(10, 20);
add("10", 20);

Output:

30
1020

The second call isn't an error.

JavaScript simply converts the number into a string and concatenates them.

Sometimes this is useful.

Sometimes it's a nightmare.

Now look at TypeScript.

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

add(10, 20);
add("10", 20);

Immediately, your editor shows:

Argument of type 'string'
is not assignable to parameter of type 'number'.

The mistake is caught before your code runs.

This is one of the biggest reasons developers love TypeScript.

JavaScript Workflow
Developer
│
▼
Write JavaScript
│
▼
Browser Runs Code
│
▼
Runtime Error (maybe)

If something is wrong, you'll only know after executing the application.

TypeScript Workflow
Developer
│
▼
Write TypeScript
│
▼
TypeScript Compiler
│
├── Errors Found ❌
│
└── JavaScript Generated ✅
│
▼
Browser Executes

Instead of discovering problems at runtime, you fix them during development.

Why TypeScript Exists

To understand why TypeScript exists, let's first understand the problems JavaScript faces in large applications.

JavaScript is an amazing language. It's flexible, easy to learn, and runs almost everywhere—from browsers to servers.

However, flexibility comes with trade-offs.

Problem 1: Dynamic Typing

JavaScript variables can change their type at any time.

let age = 20;

age = "Twenty";

age = true;

age = {};

JavaScript allows all of this without any warnings.

While this flexibility is convenient, it can also lead to confusing bugs.

Imagine a function that calculates someone's birth year.

function getBirthYear(age) {
return 2026 - age;
}

console.log(getBirthYear(20));

Works perfectly.

But someone accidentally calls:

getBirthYear("Twenty");

The result?

NaN

The error isn't discovered until the function actually executes.

In TypeScript:

function getBirthYear(age: number): number {
return 2026 - age;
}

getBirthYear("Twenty");

Error:

Argument of type 'string'
is not assignable to parameter of type 'number'.

The bug never reaches production.

Problem 2: Runtime Errors

One of the biggest issues in JavaScript is that many mistakes are only discovered while the application is running.

Example:

const user = {
name: "Shivam"
};

console.log(user.email.toLowerCase());

The application crashes.

Cannot read property 'toLowerCase' of undefined

The code looked fine.

But the object didn't contain an email property.

Now let's define the structure using TypeScript.

interface User {
name: string;
email: string;
}

const user: User = {
name: "Shivam"
};

TypeScript immediately reports:

Property 'email'
is missing.

Instead of discovering the issue after deployment, you fix it while writing the code.

Compile-Time Errors vs Runtime Errors

Understanding this difference is one of the most important concepts in TypeScript.

Compile-Time Error

A compile-time error is detected before the program runs.

Example:

let age: number = "Twenty";

TypeScript immediately stops you.

Type 'string'
is not assignable to type 'number'
Runtime Error

A runtime error occurs after the application starts.

Example:

const numbers = null;

console.log(numbers.length);

Output:

Cannot read property 'length' of null

The browser discovers the problem only after executing the code.

Visual Comparison
JavaScript

Write Code
│
▼
Run Program
│
▼
Error Appears
TypeScript

Write Code
│
▼
Compiler Checks
│
├── Error Found
│
▼
Fix Code
│
▼
Run Program

TypeScript shifts many common errors from runtime to compile time, saving debugging time and improving reliability.

Benefits of Static Typing

Static typing is the core feature that makes TypeScript so valuable.

When you specify the type of your variables, functions, and objects, TypeScript can understand your code better and provide useful feedback.

Here are some key benefits:

Fewer Bugs

TypeScript catches many mistakes before your application runs.

let price: number = 999;

price = "999";

Error immediately.

Better Autocomplete

Because TypeScript knows the structure of your objects, editors like VS Code can provide intelligent suggestions.

const user = {
name: "Shivam",
age: 20,
city: "Mumbai"
};

user.

The editor instantly suggests:

name
age
city

No need to remember every property.

Easier Refactoring

Imagine changing a property name in a project with 500 files.

Without TypeScript, you might accidentally miss several references.

With TypeScript, every broken reference is highlighted automatically.

Better Team Collaboration

When another developer reads this function:

function createOrder(order: Order): Promise

They immediately understand:

What goes in
What comes out
Which data structure is expected

The code becomes self-documenting.

Improved Maintainability

Large projects often stay active for years.

Developers join and leave.

Features are added constantly.

Strong typing helps ensure that changes in one part of the application don't unintentionally break another.

TypeScript Is a Superset of JavaScript

A common misconception is that TypeScript replaces JavaScript.

It doesn't.

Instead, TypeScript builds on top of JavaScript.

Think of JavaScript as the foundation and TypeScript as an extra safety layer.

      TypeScript
┌───────────────────┐
│  Types            │
│  Interfaces       │
│  Generics         │
│  Enums            │
│  Compiler Checks  │
└───────────────────┘
        ▲
        │
  JavaScript

Every valid JavaScript program can be renamed from .js to .ts and still work. You can then gradually introduce TypeScript features as your project grows.

Why Modern Companies Choose TypeScript

Large applications demand reliability, maintainability, and developer productivity. That's why TypeScript has become the standard choice for modern web development.

Some key reasons include:

Early error detection before deployment
Better IDE support with autocomplete and refactoring
Improved code readability and self-documentation
Safer collaboration across large teams
Easier maintenance of long-term projects
Excellent integration with frameworks like React, Next.js, Angular, and Node.js

As projects grow in size and complexity, these advantages save countless hours of debugging and reduce the likelihood of production bugs.

In the next part, we'll dive into Type Annotations—learning how to add types to variables, functions, objects, arrays, and how TypeScript's powerful type inference works. We'll also compare explicit and inferred types with practical examples before moving on to Interfaces and Type Aliases.

next
Understanding Type Annotations

Now that we know why TypeScript exists, it's time to learn how TypeScript actually understands our code.

The biggest feature of TypeScript is its type system.

When we tell TypeScript what kind of data a variable should store, it can warn us whenever we accidentally use the wrong type.

This process is called Type Annotation.

What is a Type Annotation?

A type annotation is simply a way of telling TypeScript the expected type of a variable, parameter, or return value.

The syntax is very simple:

variableName: Type

For example,

let username: string = "Shivam";

Here,

username is the variable.
string is its type.
"Shivam" is the value.

Now TypeScript knows that username should always contain a string.

If we try to assign another type, TypeScript immediately reports an error.

username = 20;
Type 'number' is not assignable to type 'string'

Instead of waiting until the application runs, the mistake is caught while we're writing the code.

Why Are Type Annotations Important?

Imagine you're building an e-commerce application.

Each product has a price.

let price = 999;

Months later another developer accidentally writes

price = "999";

JavaScript happily accepts it.

Later your discount calculation breaks because it expected a number.

With TypeScript:

let price: number = 999;

price = "999";

Immediately:

Type 'string' is not assignable to type 'number'

A bug that could have reached production is stopped instantly.

Common Primitive Types

TypeScript provides several built-in types.

string

Stores text.

let firstName: string = "Shivam";

let city: string = "Mumbai";

let course: string = "Web Development";
number

Stores integers and decimal values.

let age: number = 20;

let salary: number = 50000;

let temperature: number = 35.6;

Unlike some languages, JavaScript and TypeScript have only one number type.

There is no separate int, float, or double.

boolean

Represents true or false.

let isLoggedIn: boolean = true;

let isAdmin: boolean = false;

Very commonly used for authentication and feature flags.

bigint

For very large integers.

let views: bigint = 12345678901234567890n;
symbol

Used to create unique identifiers.

let id: symbol = Symbol("id");

Most beginners won't use this often, but it's part of the language.

Arrays

An array stores multiple values of the same type.

JavaScript
const numbers = [1,2,3,4];

JavaScript doesn't enforce that future values remain numbers.

You could accidentally do:

numbers.push("Hello");

Now your array contains mixed data.

TypeScript
const numbers: number[] = [1,2,3,4];

Trying to push a string:

numbers.push("Hello");

Produces:

Argument of type 'string'
is not assignable to parameter of type 'number'

Another syntax:

const names: Array = [
"Shivam",
"Rahul",
"Ankit"
];

Both are correct.

Most developers prefer

string[]

because it's shorter.

Objects

Objects become much safer in TypeScript.

JavaScript:

const user = {
name: "Shivam",
age: 20
};

Nothing prevents someone from writing

user.age = "Twenty";

TypeScript:

const user: {
name: string;
age: number;
} = {
name: "Shivam",
age: 20
};

Now

user.age = "Twenty";

gives an error.

Functions

Functions are where TypeScript becomes incredibly useful.

We can specify

parameter types
return types
JavaScript
function greet(name){
return "Hello " + name;
}

No one knows what type name should be.

TypeScript
function greet(name: string): string {
return Hello ${name};
}

Let's understand this carefully.

name: string

means

The parameter must be a string.

): string

means

This function always returns a string.

Calling the function correctly

greet("Shivam");

works perfectly.

But

greet(10);

shows

Argument of type 'number'
is not assignable to parameter of type 'string'
Multiple Parameters
function add(
a: number,
b: number
): number {

return a + b;

}

Usage

add(10,20);

Wrong

add("10",20);

Error immediately.

Optional Parameters

Sometimes a value isn't always available.

For example,

function greet(name: string, city?: string) {

if(city){
    return `Hello ${name} from ${city}`;
}

return `Hello ${name}`;

}

Now both calls are valid.

greet("Shivam");

greet("Shivam","Mumbai");

The ? means the parameter is optional.

Default Parameters
function greet(
name: string,
city: string = "Mumbai"
){

return `Hello ${name} from ${city}`;

}

Now

greet("Shivam");

returns

Hello Shivam from Mumbai
Void Return Type

Some functions don't return anything.

function printMessage(message: string): void {

console.log(message);

}

The return type is

void

meaning

This function performs an action but returns nothing.

Never Return Type

The never type is used for functions that never successfully finish.

Example:

function throwError(message: string): never {

throw new Error(message);

}

Because an error is thrown, the function never reaches the end.

Any Type

Sometimes we don't know the type.

TypeScript provides

any
let value: any;

value = 10;

value = "Hello";

value = true;

value = {};

This behaves almost exactly like JavaScript.

However,

avoid using any whenever possible.

Using any disables TypeScript's safety checks.

Think of it as turning off your seatbelt.

Unknown Type

Instead of any, TypeScript introduced unknown.

let value: unknown;

Unlike any, you cannot use it directly.

value.toUpperCase();

Error.

You must first check its type.

if(typeof value === "string"){

console.log(value.toUpperCase());

}

This makes your code much safer.

Type Inference

One of TypeScript's smartest features is Type Inference.

Sometimes you don't even have to write the type.

Example

let age = 20;

Notice we didn't write

let age: number = 20;

Yet TypeScript already knows

age → number

If you later write

age = "Twenty";

You still get an error.

TypeScript automatically inferred the type.

Another example

const city = "Mumbai";

TypeScript infers

city: string

Functions also benefit from inference.

function multiply(a: number,b: number){

return a*b;

}

We didn't write the return type.

TypeScript automatically infers

number
Explicit Types vs Inferred Types

There are two ways to define types.

Explicit

You manually specify the type.

let username: string = "Shivam";

Everything is written clearly.

Inferred

TypeScript figures it out.

let username = "Shivam";

Both produce the same result.

Which One Should You Use?

A common question is:

Should I always write types?

The answer is no.

Use inference whenever the type is obvious.

Good example

const age = 20;

No need to write

const age: number = 20;

But when writing functions, APIs, exported variables, or complex objects, explicit types improve readability.

function createUser(
name: string,
age: number
): User {

}

Anyone reading the code immediately understands what is expected.

Best Practices
Let TypeScript Infer Simple Types

Good

const username = "Shivam";

Not necessary

const username: string = "Shivam";
Always Type Function Parameters
function login(email: string,password: string){

}

Avoid

function login(email,password){

}
Avoid any

Instead of

let response: any;

prefer

let response: unknown;

or define a proper interface.

Always Specify Return Types for Public Functions
function calculateTotal(): number{

}

This improves readability and prevents accidental changes.

Common Beginner Mistakes
Using any Everywhere
let data:any;

This removes almost every benefit of TypeScript.

Forgetting Function Return Types

Large projects become difficult to understand.

Mixing Types
let age:number=20;

age="Twenty";

TypeScript exists specifically to prevent mistakes like this.

Overusing Explicit Types

Writing

const city:string="Mumbai";

everywhere makes code unnecessarily verbose.

Trust TypeScript's inference when appropriate.

Summary

Type annotations are the foundation of TypeScript. They allow you to describe the shape of your data, making your code more predictable and easier to maintain. Combined with TypeScript's powerful type inference, they strike a balance between safety and developer productivity.

By understanding how to annotate variables, functions, arrays, and objects—and knowing when to rely on inference—you'll write cleaner, more reliable applications with fewer runtime surprises.

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

Shivam Yadav — Mon, 22 Jun 2026 16:48:39 +0000

When most developers start building mobile applications, their folder structure usually looks something like this:

app/
components/
screens/
hooks/
utils/

For a small project, this works perfectly.

But imagine building:

Instagram with millions of posts
WhatsApp with billions of messages
Uber with realtime location updates
Netflix with massive content catalogs

Suddenly that simple folder structure starts falling apart.

Files become difficult to find.

Features become tightly coupled.

Navigation becomes messy.

Performance problems appear.

And onboarding new developers becomes painful.

The challenge is no longer writing screens.

The challenge becomes:

How do we organize a codebase that can survive years of development and dozens of engineers?

This is where architecture matters.

In this article we'll explore how modern large-scale applications could be structured today using Expo Router and modern React Native practices.

The goal is not to clone Instagram or Uber.

The goal is to understand the architectural thinking behind production-grade mobile applications.

Why Simple Folder Structures Fail at Scale

Most beginner applications are organized by file type.

Example:

components/
screens/
hooks/
services/
utils/

Initially this feels clean.

But after a few months:

components/
 ├── PostCard.tsx
 ├── UserAvatar.tsx
 ├── RideCard.tsx
 ├── PaymentCard.tsx
 ├── MessageBubble.tsx
 ├── VideoPlayer.tsx

Hundreds of files accumulate.

Finding related functionality becomes difficult.

The application becomes harder to maintain.

Small App Thinking vs Production Thinking

Small App Thinking:

Organize by file type

Production Thinking:

Organize by business feature

Large companies think in terms of:

Feed
Chat
Profile
Payments
Notifications
Authentication

Not buttons and screens.

Why Architecture Matters

Good architecture provides:

Scalability

Features can grow independently.

Maintainability

Developers know exactly where code belongs.

Team Collaboration

Multiple engineers can work simultaneously.

Performance

Systems remain efficient as complexity grows.

Developer Experience

Development stays predictable.

The Modern Expo Router Approach

Expo Router changed how React Native applications handle navigation.

Instead of manually defining navigation trees:

<Stack.Navigator>

Routes become file-system based.

Folders define application structure.

This encourages cleaner organization.

Production-Grade Expo Router Structure

A large application might look like:

app/
│
├── (public)/
│   ├── login.tsx
│   ├── register.tsx
│
├── (protected)/
│   ├── (tabs)/
│   │   ├── home.tsx
│   │   ├── profile.tsx
│   │   ├── settings.tsx
│
│   ├── chat/
│   ├── notifications/
│   ├── payments/
│
├── _layout.tsx
│
features/
│
├── auth/
├── feed/
├── chat/
├── profile/
├── notifications/
├── payments/
│
shared/
│
├── components/
├── hooks/
├── lib/
├── utils/

Notice something important.

Navigation and business logic are separated.

This becomes crucial at scale.

Feature-Based Architecture

Feature-based architecture is one of the most common patterns in large applications.

Instead of:

components/
screens/
services/

We organize by domain.

features/

├── auth/
├── feed/
├── chat/
├── profile/
├── payments/

Each feature owns its logic.

Example Feature Structure

features/chat/

├── components/
├── hooks/
├── services/
├── store/
├── types/
├── api/

Everything related to chat lives together.

This makes development significantly easier.

Authentication Flow Architecture

Every large application begins with authentication.

Examples:

Instagram Login
WhatsApp Registration
Uber Authentication
Netflix Profiles

A common route structure:

Expo Router route groups make this extremely clean.

Protected Routes

app/

(public)

(protected)

Users without authentication remain inside public routes.

Authenticated users gain access to protected routes.

This pattern scales extremely well.

Shared Layouts and Nested Routing

Large applications often share UI structures.

Example:

Instagram:

Bottom Tabs

Home
Search
Create
Reels
Profile

Every tab shares the same layout.

Expo Router handles this through nested layouts.

(tabs)

_layout.tsx
home.tsx
search.tsx
profile.tsx

This reduces duplication.

State Management at Scale

Small apps often rely only on React state.

useState()

Large applications require more structure.

State usually falls into three categories.

Server State

Data coming from APIs.

Examples:

Feed posts
Messages
Movies
User profiles

Typical solution:

TanStack Query

Client State

UI-related state.

Examples:

Modal visibility
Theme preferences
Navigation state

Typical solutions:

Zustand

Redux Toolkit

Persistent State

Data stored between app launches.

Examples:

Authentication tokens
Cached preferences
Offline data

Typical storage:

AsyncStorage

SecureStore

API Layer Architecture

A common mistake is calling APIs directly from screens.

Bad:

FeedScreen.tsx
     ↓
Fetch API

This creates tight coupling.

A better structure:

Example:

This separation improves testing and maintainability.

How Instagram Would Be Structured

Instagram appears simple.

But internally it contains multiple systems.

Feed System

Responsible for:

Posts
Likes
Comments
Media

Possible feature structure:

features/feed/

├── api/
├── components/
├── hooks/
├── store/

Media System

Handles:

Image uploads
Video uploads
Compression
Caching

A completely separate domain.

Notification System

Handles:

Likes
Comments
Follows
Mentions

Usually implemented as its own feature.

How WhatsApp Would Be Structured

WhatsApp is fundamentally a realtime system.

The complexity comes from messaging.

Not screens.

Chat Architecture

The realtime layer continuously synchronizes messages.

Realtime Messaging Flow

This flow repeats millions of times daily.

Offline Messaging

Messages must survive:

No internet
App crashes
Device restarts

Architecture:

Offline-first thinking becomes essential.

How Uber Would Be Structured

Uber introduces a different challenge.

Realtime location.

Ride Tracking Architecture

Updates happen continuously.

State Management Challenges

Uber manages:

User location
Driver location
Route data
Ride status

All changing simultaneously.

Efficient state updates become critical.

Realtime Location Updates

Typical flow:

This architecture must remain efficient for thousands of concurrent rides.

How Netflix Would Be Structured

Netflix introduces another challenge.

Content delivery.

Content Discovery

Features:

Home Feed
Categories
Search
Recommendations

Each acts as an independent module.

Media Performance

Video streaming dominates architecture decisions.

Focus areas:

Caching
Prefetching
Lazy loading
Memory management

The challenge is not rendering UI.

The challenge is delivering content efficiently.

Offline Downloads

Netflix-style downloads require:

A dedicated subsystem is usually required.

Offline-First Architecture

Many successful mobile apps work even without internet.

Examples:

WhatsApp
Uber
Spotify
Netflix

Cache Synchronization Flow

The user experiences immediate feedback.

App Startup Optimization

Large applications often feel slow because too much work happens during startup.

Common Startup Problems

Authentication Check

API Calls

Fonts

Analytics

Remote Config

Feature Flags

All competing for resources.

Optimized Startup Flow

Prioritization matters.

Performance Considerations

Production applications optimize relentlessly.

Reduce Re-renders

Avoid unnecessary updates.

Code Splitting

Load features only when needed.

Image Optimization

Compress and cache media.

Virtualized Lists

Essential for feeds and chats.

Examples:

Instagram Feed

WhatsApp Chats

Netflix Catalogs

Shared Components

Create reusable building blocks.

Avatar
Button
Modal
Loader

Avoid duplicate implementations.

Scalability Challenges

Each application scales differently.

Instagram

Challenge:

Media + Feed Ranking

Challenge:

Realtime Messaging

Uber

Challenge:

Realtime Location

Netflix

Challenge:

Massive Content Delivery

Tradeoffs Teams Make

Every architecture decision involves tradeoffs.

More Abstraction

Pros:

Cleaner code
Better reuse

Cons:

Increased complexity

More Caching

Pros:

Faster experience

Cons:

Data consistency challenges

More Features

Pros:

Better user experience

Cons:

Larger maintenance burden

Final Thoughts

Most developers focus on building screens.

Large companies focus on building systems.

Instagram, WhatsApp, Uber, and Netflix succeed not because their UI is complex, but because their architecture allows thousands of engineers and millions of users to work together efficiently.

The progression usually looks like:

Small App

Screens
Components
Hooks

Medium App

Features
Services
State Management

Large App

Feature Architecture
Realtime Systems
Caching
Offline Support
Performance Optimization
Scalable Navigation

Expo Router fits naturally into this evolution.

Its file-based routing, nested layouts, route groups, and shared layouts make it an excellent foundation for large React Native applications.

The biggest lesson is simple:

Don't organize your application around screens.

Organize it around business features.

That's the mindset that separates tutorial projects from production-grade mobile applications.

what is realtime system ?

Shivam Yadav — Sun, 21 Jun 2026 15:52:19 +0000

Imagine you're chatting with a friend on WhatsApp.You send a message.
Within milliseconds, it appears on their screen.

No refresh button No page reload No waiting
It just happens.

But have you ever wondered:

How does WhatsApp know exactly when to deliver that message?

How does Instagram instantly notify you about a new follower?

How does Google Docs show someone else's typing cursor in real time?

How does Uber update your driver's location every few seconds?

The answer lies in a collection of communication patterns and architectures that power modern realtime systems.
(inshort it all depend on what architecture they use for relative system)

In this article, we'll explore:

Polling
Long Polling
Server-Sent Events (SSE)
WebSockets
Publish-Subscribe (Pub/Sub)

We'll understand how they work, where they shine, their tradeoffs, and how large-scale applications combine them to build highly responsive experiences.

What Makes a System "Realtime"?

A realtime system is one where information is delivered as soon as a change occurs.
(inshort Realtime is the ability to react to anything that occurs as it occurs, before it loses its importance.)

The goal is to minimize the delay between:

An event happening → The user seeing the update

Examples:

Chat messages
Social media notifications
Live sports scores
Ride tracking
Stock market dashboards
Collaborative editors

Realtime vs Near Realtime

Realtime

Updates are delivered almost immediately.

Example:

WhatsApp messages
Online gaming
Google Docs collaboration

Delay:

Milliseconds to a few seconds

Near Realtime

Updates arrive shortly after they happen.

Example:

Analytics dashboards
Email inbox refresh
Reporting systems

Delay:

Several seconds or minutes

Not every system requires strict realtime communication.

Choosing the correct approach depends on business requirements.

Traditional Request-Response Communication

Before understanding realtime communication, let's understand how most web applications work.

Normal HTTP Flow

Example:

User opens a webpage.
Browser sends request.
Server returns data.
Connection closes.

The server only responds when the client asks.

This model works great for:

Login systems
Forms
E-commerce websites
CRUD applications

But it struggles with realtime updates.

The Realtime Problem

Suppose a user is waiting for a new message.

How does the browser know a new message arrived?

The server cannot suddenly push information because the connection has already been closed.

The browser has two choices:

Keep asking repeatedly
Keep a connection open

The evolution of realtime systems is essentially the story of solving this problem~ shivam yadav.

Polling

Polling is the simplest solution.

How Polling Works

The client repeatedly asks the server:

"Anything new?"

Every few seconds.

Example

A notification system checks every 5 seconds.

setInterval(() => {
   fetch('/notifications')
}, 5000)

Advantages

Simple

Easy to understand and implement.

Works Everywhere

Uses standard HTTP requests.

No Special Infrastructure

Can run on almost any backend.

Disadvantages

Wasteful

Most requests return:

"No updates."

Yet resources were consumed.

Delayed Updates

If polling every 10 seconds:

A message may wait 10 seconds before being seen.

High Server Load

100,000 users polling every few seconds creates enormous traffic.

When Polling Is Enough

Polling is often sufficient for:

Admin dashboards
Analytics pages
Low-frequency notifications
Internal tools

If updates are rare, polling may be the simplest and most practical solution.

Long Polling

Polling wastes requests.

Engineers looked for a better solution.

This led to Long Polling.

How Long Polling Works

Instead of immediately replying:

"No updates"

The server waits.


The client immediately opens another request.

Client ---> Server
Server waits

Server ---> Client

Client ---> Server
Server waits

Long Polling Flow

Benefits

Fewer Unnecessary Requests

Requests stay open longer.

Faster Than Polling

Updates arrive immediately after an event occurs.

Works Over HTTP

No special protocol required.

Drawbacks

Many Open Connections

Each waiting request consumes resources.

More Complex

Timeouts and reconnections must be handled.

Doesn't Scale Easily

Large numbers of users can create server pressure.

Real-World Uses

Historically used by:

Early chat systems
Notification systems
Messaging applications before WebSockets became popular

Server-Sent Events (SSE)

Long Polling improved things.

But browsers still kept reopening requests.

SSE introduced a better model.

What is SSE?

Server-Sent Events allow a server to continuously push updates to the browser through a single HTTP connection.

The client opens one connection.

The server streams updates whenever they occur.

SSE Architecture

One request.

Many updates.

Communication Model

SSE is:

Server → Client

Only.

The client cannot send messages over the same stream.

Advantages

Lightweight

Uses plain HTTP.

Automatic Reconnection

Browsers reconnect automatically.

Easy to Implement

Simpler than WebSockets.

Efficient for Updates

Excellent when information flows mostly one direction.

Limitations

One-Way Communication

Client cannot send realtime data back.

Browser Connection Limits

Can become restrictive with many tabs.

Not Ideal for Interactive Systems

Chat applications need two-way communication.

Perfect Use Cases

Notifications
Live dashboards
Monitoring systems
News feeds
Build logs
AI streaming responses

For example:

When ChatGPT streams tokens while generating a response, SSE is often a great choice.

WebSockets

At this point we still have a limitation.

Clients need to send information too.

Chat applications require:

Sending messages
Receiving messages

Simultaneously.

This is where WebSockets shine.

What Are WebSockets?

WebSockets create a persistent connection between client and server.
and when i say persistent i mean to say continues

Instead of repeatedly opening connections:

One connection stays alive.

Connection Lifecycle

Client <===============> Server

Data flows both ways.

Bidirectional Communication

Client ---- Message ----> Server

Client <--- Message ----- Server

Client ---- Message ----> Server

Client <--- Message ----- Server

No repeated requests.

No repeated handshakes.

Why Chat Applications Use WebSockets

Consider WhatsApp.

User A sends a message.

User A --> Server --> User B

The server instantly pushes the message.

No refresh.

No polling.

No waiting.

This requires bidirectional communication.

Benefits

Low Latency

Messages arrive almost instantly.

Efficient

Connection established once.

Full Duplex

Both sides communicate anytime.

Ideal for Realtime Apps

Perfect for highly interactive experiences.

Limitations

Connection Management

Servers must track active connections.

Scaling Complexity

Millions of open connections require specialized infrastructure.

Load Balancing Challenges

Connection state must be managed carefully.

Common Use Cases

Chat applications
Multiplayer games
Collaborative editing
Live trading systems
Ride tracking

Pub/Sub Systems

Polling, SSE, and WebSockets describe communication methods.

Pub/Sub is different.

Pub/Sub is an architectural pattern.

What is Publish-Subscribe?

Instead of services directly talking to each other:

They communicate through topics.

Core Components

Publisher

Produces events.

Topic

Channel where events are sent.

Subscriber

Receives events.

Architecture

Publishers don't know subscribers.

Subscribers don't know publishers.

Everything is decoupled.

Example: Notification System

User receives a message.

Message Service
       |
       v
   "new-message"
       |
       v
 Notification Service

 Mobile Push Service

 Analytics Service

One event.

Multiple consumers.

Benefits

Loose Coupling

Services remain independent.

Scalability

Consumers can grow independently.

Reliability

Messages can be retried.

Event Driven

Perfect for modern distributed systems.

Real Examples

Popular Pub/Sub systems include:

Apache Kafka
Redis Pub/Sub
RabbitMQ
Google Pub/Sub
AWS SNS/SQS

Comparing All Approaches

Polling vs Long Polling

Feature	Polling	Long Polling
Requests	Frequent	Fewer
Latency	Higher	Lower
Complexity	Simple	Moderate
Resource Usage	Wasteful	Better

Long Polling vs SSE

Feature	Long Polling	SSE
Connection	Reopened repeatedly	Persistent
Server Push	Limited	Excellent
Complexity	Higher	Lower

SSE vs WebSockets

Feature	SSE	WebSockets
Direction	One-way	Two-way
Complexity	Simpler	More Complex
Notifications	Excellent	Excellent
Chat Apps	Poor	Excellent

WebSockets vs Pub/Sub

Feature	WebSockets	Pub/Sub
Protocol	Yes	No
Client Communication	Yes	Usually No
Architecture Pattern	No	Yes
Service Coordination	Limited	Excellent

Building Realtime Systems at Scale

Building a realtime system for 100 users is easy.

Building one for millions is hard.

Handling Thousands of Connections

Every WebSocket connection consumes:

Memory
CPU
Network resources

Large systems distribute users across multiple servers.

Horizontal Scaling

Instead of:

1 Server

We use:

Load Balancer

 /   |   \
S1  S2  S3

Traffic spreads across machines.

The Connection State Problem

Suppose:

User A is connected to Server 1.

User B is connected to Server 3.

How does Server 1 know where User B lives?

A shared messaging layer becomes necessary.

Pub/Sub Enables Scaling

Server 1
    \
     \
      Kafka
     /
    /
Server 2

Server 3

A message published by one server becomes visible to all others.

This is how large chat systems coordinate delivery.

Reliability Considerations

Large-scale systems must address:

Message ordering
Duplicate messages
Failed deliveries
Reconnection handling
Offline users
Data persistence

Realtime communication is not only about speed.

It's also about correctness.

Choosing the Right Approach

There is no universal winner.

The correct solution depends on requirements.

Chat Applications

Recommended:

WebSockets
Pub/Sub for scaling

Examples:

WhatsApp
Discord
Slack

Notification Systems

Recommended:

SSE
Polling for simpler systems

Examples:

GitHub notifications
Social media alerts

Live Sports Scores

Recommended:

SSE
WebSockets

Updates are frequent but mostly one-way.

Stock Market Dashboards

Recommended:

WebSockets

Need low latency and high update frequency.

Collaborative Applications

Recommended:

WebSockets
Pub/Sub

Examples:

Google Docs
Figma

IoT Systems

Recommended:

WebSockets
Pub/Sub

Thousands of devices continuously exchange events.

And this is the end

The evolution of realtime communication follows a natural progression:

Polling → Long Polling → SSE → WebSockets

As systems grow, another layer appears:

Pub/Sub

Each solution exists because it solves a specific problem.

Polling is simple.
Long Polling reduces waste.
SSE enables efficient server-to-client streaming.
WebSockets enable true bidirectional communication.
Pub/Sub enables systems to scale across many services and servers.

The next time a WhatsApp message arrives instantly, a stock price updates live, or a Google Docs cursor moves across your screen, you'll know the engineering patterns making that experience possible.

The best realtime architecture is not the most advanced one.

it's what suites your business

if u like the blog then comment a heart and meet u in the next blog bye

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.