We'll go through:

1. What problem the Virtual DOM solves

2. Difference between Real DOM vs Virtual DOM

3. Initial render process in React

4. How state or props change triggers re-render

5. Creation of a new Virtual DOM tree

6. What diffing (reconciliation) means

7. How React finds minimal required changes

8. Updating only changed nodes in the Real DOM

9. Why this approach improves performance

10. High-level overview of React render → diff → commit flow

So before directly jumping on the above mentioned topics, let's have a quick intro to react.

Introduction to React.js

React.js is a JavaScript library that helps to build and manage complex UI. and according to the react.js docs ------

"The library for web and native user interfaces".

React.js follows component-based architecture - meaning everything on UI is a component which then accumulate to entire screens, pages, and apps. (cool right ?)

So react makes something called Virtual DOM, but why? let's see ...

What problem the Virtual DOM solves?

Browsers have document object model (DOM) to render the UI, which is heavy and relatively slow. To be more accurate - frequent updates on DOM is really expensive. That is where the concept of Virtual DOM comes to play its role in react. Instead of directly working with DOM react works with the lightweight, in-memory representation of the real DOM.

Difference between Real DOM vs Virtual DOM

The Real DOM is the actual structure used by the browser to render the UI on the screen.

The Virtual DOM, on the other hand, is a lightweight JavaScript representation of the real DOM maintained by React.

Real DOM

• Directly represents the UI in the browser

• DOM updates can be expensive due to layout recalculations (reflow) and repainting

• Frequent or unnecessary updates can impact performance

Virtual DOM

• Exists in memory as a JavaScript object

• Updates are first made here instead of the real DOM

• React compares the new Virtual DOM with the previous version (diffing)

• Only the necessary changes are applied to the real DOM

The key difference is that the Virtual DOM minimizes direct manipulation of the real DOM by ensuring that only the required updates are performed.

Initial render process in React

The initial render in react happens in a process - step by step:

1. Entry Point (index.js / main.jsx)

   import ReactDOM from "react-dom/client";
   import App from "./App";
   
   const root = ReactDOM.createRoot(document.getElementById("root"));
   root.render(<App />);
   

Here:

• React finds the <div id="root"></div> in HTML

• Prepares a root container

2. Component Execution Starts

function App() {
  return <h1>Hello World</h1>;
}

Here React:

• Calls App() like a normal function

• Gets JSX output

3. JSX → React Elements

JSX:

<h1>Hello World</h1>

becomes:

React.createElement("h1", null, "Hello World");

This creates a Virtual DOM object

React builds a tree like:

{
  type: "h1",
  props: {
    children: "Hello World"
  }
}

4. Reconciliation (Initial Phase)

• React prepares how UI should look

• No comparison yet (first render)

5. Commit Phase (Real DOM Creation)

React now:

• Creates actual DOM nodes (<h1>)

• Inserts them into the real DOM

• Browser paints it on screen

How state or props change triggers re-render

In React, the UI is driven by state and props.

so Whenever:

• a component’s state changes, or

• it receives new props

React re-runs that component function

setCount(count + 1)

This does not directly update the DOM.

Instead, it tells React: “Something changed — recalculate the UI.”

Creation of a New Virtual DOM Tree

After a state/prop change:

1. React calls the component again

2. JSX is returned again

3. A new Virtual DOM tree is created

Important:

• React does not modify the old tree

• It creates a fresh new version

Think of it like:

Old UI snapshot
New UI snapshot

Now React has two versions to compare.

What Diffing (Reconciliation) Means

Diffing (also called Reconciliation) is the process where React: compares old Virtual DOM vs new Virtual DOM

Find what actually changed

Instead of re-rendering everything, React asks:

• Did this element change?

• Did text update?

• Did a component get replaced?

How React Finds Minimal Required Changes?

React uses a smart comparison strategy:

1. Same element type?

• <div> → <div> → reuse

• <div> → <span> → replace

2. Compare props

Only update changed attributes

3. Keys in lists

items.map(item => <li key={item.id}>{item.name}</li>)

Keys help React:

• Track elements

• Avoid unnecessary re-renders

-- React builds a list of minimal changes (diff)

Updating Only Changed Nodes in the Real DOM

After diffing:

React enters the commit phase

It:

• Updates only changed elements

• Leaves everything else untouched

Example:

If only text changes:

<h1>Hello</h1> → <h1>Hello World</h1>

React updates only text node, not entire

Why This Approach Improves Performance

Without Virtual DOM:

• Every update → direct DOM manipulation

• Expensive + slow

With React:

• Changes happen in memory first (fast)

• Only necessary updates go to real DOM

• Multiple updates are batched together

This give faster UI updates, smooth user experience and better scalability

High-Level Flow: Render → Diff → Commit

Here’s the full cycle:

State/Props Change
        ↓
Render Phase (create new Virtual DOM)
        ↓
Diff Phase (compare old vs new)
        ↓
Commit Phase (update real DOM)
        ↓
Browser paints updated UI

To sum it up

React does not blindly update the UI.

Instead, it: Recreates the UI in memory Compares it efficiently Updates only what is necessary

This is what makes React apps fast and efficient. Understanding this internal flow not only helps in writing better React code, but also in debugging performance issues and answering deeper interview questions with confidence.

In this blog, you will understand the event loop in a simple and clear way.

1. What the Event Loop Is

The event loop is a mechanism that continuously checks:

• Is the main thread free?

• Are there any tasks waiting to be executed?

If both conditions are met, it picks a task and runs it.

In simple terms:

• It is like a manager that decides what runs next

2. Why Node.js Needs an Event Loop

Node.js is single-threaded, meaning:

• Only one piece of code runs at a time

But real applications involve:

• File reading

• Database calls

• API requests

These operations take time.

If Node.js waited for each task to complete, everything would slow down.

The event loop solves this by:

• Allowing Node.js to handle other tasks while waiting

• Managing when and how tasks are executed

3. Call Stack vs Task Queue (Conceptual)

To understand the event loop, you need to know two basic concepts:

Call Stack

• Where functions are executed

• Works in order (last in, first out)

• Only one function runs at a time

Task Queue

• Stores completed async tasks

• Waits for the call stack to be empty

Flow:

1. Code runs in the call stack

2. Async tasks are handled outside

3. Once done, they are added to the task queue

4. Event loop moves them to the call stack when it is free

4. How Async Operations Are Handled

When Node.js encounters an async operation:

Example:

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

What happens internally:

1. setTimeout is sent to a background system

2. Node.js continues executing other code

3. After 2 seconds, the callback is placed in the task queue

4. Event loop checks if the call stack is empty

5. If yes, it executes the callback

This ensures the main thread is never blocked.

5. Timers vs I/O Callbacks (High Level)

Different types of async tasks are handled in different phases.

Timers

• Functions like setTimeout and setInterval

• Executed after a specified delay

I/O Callbacks

• File operations

• Network requests

• Database operations

These are handled when the operation completes.

The event loop processes these tasks in phases, ensuring efficient execution.

6. Role of Event Loop in Scalability

The event loop is the main reason why Node.js scales well.

How it helps:

• Does not block while waiting for tasks

• Handles multiple requests efficiently

• Uses fewer resources compared to multi-threaded systems

• Keeps the server responsive

Example:

• 100 users send requests

• Some require database access (slow)

• Others are simple (fast)

Node.js:

• Sends slow tasks to background

• Continues handling fast requests

• Processes results when ready

This allows Node.js to handle high traffic smoothly.

Final Understanding

• The event loop manages execution of tasks in Node.js

• It works with the call stack and task queue

• It ensures async tasks are handled without blocking

• It separates timers and I/O operations into different phases

• It enables Node.js to handle multiple requests efficiently

Summary

The event loop is the core mechanism that powers Node.js performance. It allows a single-threaded system to manage multiple operations by scheduling and executing tasks efficiently. By coordinating between the call stack and task queues, it ensures that asynchronous operations do not block the system. This design makes Node.js highly scalable and suitable for applications that need to handle many users, such as APIs, real-time services, and data-driven platforms. Understanding the event loop is essential to mastering how Node.js works internally.

Let’s break it down in a simple and practical way.

1. What Blocking Code Means

Blocking code is when a task stops the execution of the program until it is finished.

In simple terms:

• The system waits

• Nothing else can run during that time

Example:

const fs = require('fs');

const data = fs.readFileSync('file.txt', 'utf-8');
console.log(data);

console.log('This runs after file is read');

What happens:

• File is read completely first

• Only then the next line runs

This blocks the main thread.

2. What Non-Blocking Code Means

Non-blocking code allows the program to continue executing while a task is running in the background.

Instead of waiting:

• The task is started

• The program moves forward

• Result is handled later

Example:

const fs = require('fs');

fs.readFile('file.txt', 'utf-8', (err, data) => {
  console.log(data);
});

console.log('This runs before file is read');

What happens:

• File reading starts

• Program continues immediately

• Result is printed later

3. Why Blocking Slows Servers

In Node.js, everything runs on a single thread.

If one request uses blocking code:

• It stops the thread

• Other requests must wait

Example scenario:

• User A → file read (blocking)

• User B → simple request

User B will have to wait until User A’s task is finished.

This leads to:

• Slow response times

• Poor scalability

• Bad user experience

4. Async Operations in Node.js

Node.js is designed to use asynchronous (async) operations.

Instead of blocking:

• Tasks are handled in the background

• Callbacks, Promises, or async/await are used

Example with async/await:

const fs = require('fs/promises');

async function readFile() {
  const data = await fs.readFile('file.txt', 'utf-8');
  console.log(data);
}

readFile();
console.log('This runs first');

Even though await looks like it pauses execution, Node.js is still handling it efficiently without blocking other operations.

5. Real-World Examples

a) File Reading

Blocking:

fs.readFileSync('data.txt');

Non-blocking:

fs.readFile('data.txt', callback);

b) Database Calls

Blocking (bad practice):

• Waiting for database response before doing anything else

Non-blocking (correct approach):

db.query('SELECT * FROM users', (err, result) => {
  console.log(result);
});

Or using async/await:

const users = await db.query('SELECT * FROM users');

c) API Calls

Non-blocking example:

fetch('/api/data')
  .then(res => res.json())
  .then(data => console.log(data));

console.log('Runs immediately');

Final Understanding

• Blocking code stops execution until a task finishes

• Non-blocking code allows other tasks to run in parallel

• Blocking operations slow down Node.js servers

• Node.js is built around asynchronous, non-blocking behaviour

• Real-world applications rely heavily on non-blocking code

Summary

Understanding blocking vs non-blocking code is essential for writing efficient Node.js applications. Since Node.js uses a single-threaded model, blocking operations can freeze the entire server and delay all incoming requests. Non-blocking code solves this by allowing tasks to run in the background while the system continues processing other requests. By using asynchronous patterns like callbacks, promises, and async/await, you can build fast, responsive, and scalable applications that handle multiple users efficiently.

In this blog, we will break down the reasons in a simple and clear way.

1. What Makes Node.js Fast

Node.js is designed for speed and efficiency.

Some key reasons include:

• It uses the V8 engine (from Google) which compiles JavaScript into machine code

• It follows a non-blocking architecture

• It uses an event-driven model

• It handles multiple requests without creating multiple threads

All these together make Node.js highly performant.

2. Non-Blocking I/O Concept

One of the biggest reasons behind Node.js speed is non-blocking I/O.

What does this mean?

Normally, when a server performs a task like:

• Reading a file

• Fetching data from a database

It waits until the task is completed before moving forward.

This is called blocking.

In Node.js:

• It starts the task

• Does not wait

• Moves on to handle other requests

• Comes back when the task is done

Example idea:

• Request A (slow task) → sent to background

• Request B (fast task) → handled immediately

This allows Node.js to handle many requests efficiently.

3. Event-Driven Architecture

Node.js follows an event-driven architecture.

This means:

• Everything is based on events (like requests, responses, data arrival)

• A central system (event loop) listens for these events

• When an event occurs, a corresponding function is executed

Why this is powerful:

• No unnecessary waiting

• Efficient use of resources

• Better performance under heavy load

4. Single-Threaded Model Explanation

Node.js uses a single thread to execute JavaScript.

At first, this might sound like a limitation. But combined with non-blocking I/O, it becomes an advantage.

Traditional servers:

• Create a new thread for each request

• High memory usage

• Context switching overhead

Node.js:

• Uses one thread

• Handles multiple requests using async operations

• Avoids overhead of multiple threads

This leads to:

• Faster performance

• Lower resource usage

5. Where Node.js Performs Best

Node.js is especially good for applications that involve a lot of I/O operations.

Best use cases:

1. APIs

• Fast REST APIs for web and mobile apps

2. Real-time applications

• Chat apps

• Live notifications

• Collaboration tools

3. Streaming applications

• Video streaming

• Audio streaming

4. Microservices

• Lightweight and scalable services

Not ideal for:

• CPU-heavy tasks like:

  • Video processing

  • Complex calculations

6. Real-World Companies Using Node.js

Many large companies use Node.js in production.

Examples:

• Netflix → for fast streaming services

• Uber → for handling real-time data

• PayPal → for scalable APIs

• LinkedIn → for backend services

These companies chose Node.js because it handles high traffic efficiently.

Final Understanding

• Node.js is fast because of its non-blocking and event-driven design

• It uses a single thread but handles many requests efficiently

• It is ideal for I/O-heavy applications

• It scales well with high user traffic

• Many top companies rely on Node.js for performance

Summary

Node.js is a powerful choice for building fast web applications because it combines multiple performance-focused concepts into one system. Its use of the V8 engine ensures quick execution of JavaScript, while its non-blocking I/O model allows it to handle many operations without waiting. The event-driven architecture further improves efficiency by processing tasks only when needed. Even though it uses a single thread, it avoids the overhead of managing multiple threads, making it lightweight and scalable. For applications that require handling many users, real-time updates, or frequent data requests, Node.js provides a reliable and high-performance solution.

If you understand middleware properly, you can control how requests are processed, validated, and handled in your application.

1. What Middleware is in Express

Middleware is simply a function that runs between the request and the response.

It has access to:

• req (request)

• res (response)

• next (a function to move to the next step)

Basic structure:

function middleware(req, res, next) {
  // do something
  next();
}

Middleware can:

• Modify request or response

• Execute some logic

• End the request-response cycle

• Pass control to the next middleware

2. Where Middleware Sits in Request Lifecycle

When a client sends a request, it does not go directly to the route handler.

Instead, it passes through a chain of middleware functions.

Flow:

Request → Middleware → Middleware (if there in another one) → Route Handler → Response

Each middleware gets a chance to:

• Process the request

• Decide whether to continue or stop

3. Types of Middleware

Express provides different types of middleware based on how and where they are used.

a) Application-Level Middleware

These are applied to the entire app.

const express = require('express');
const app = express();

app.use((req, res, next) => {
  console.log('App-level middleware');
  next();
});

This runs for every request.

b) Router-Level Middleware

These are applied to specific routes using a router.

const router = express.Router();

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

router.get('/users', (req, res) => {
  res.send('Users route');
});

app.use('/api', router);

This runs only for routes under /api.

c) Built-in Middleware

Express provides some built-in middleware.

Examples:

app.use(express.json());
app.use(express.urlencoded({ extended: true }));

These help in:

• Parsing JSON

• Handling form data

4. Execution Order of Middleware

Middleware runs in the order it is defined.

Example:

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

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

app.get('/', (req, res) => {
  res.send('Done');
});

Output:

First
Second

If the order changes, the behaviour also changes.

5. Role of next() Function

The next() function is used to pass control to the next middleware.

If you do not call next():

• The request will stop

• The client will not get a response (request hangs)

Example:

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

You can also stop the flow:

app.use((req, res) => {
  res.send('Request ended here');
});

6. Real-World Examples

Middleware is used in almost every backend application.

a) Logging

app.use((req, res, next) => {
  console.log(`\({req.method} \){req.url}`);
  next();
});

Logs every incoming request.

b) Authentication

function auth(req, res, next) {
  const isLoggedIn = true;

  if (!isLoggedIn) {
    return res.status(401).send('Unauthorized');
  }

  next();
}

app.get('/profile', auth, (req, res) => {
  res.send('Protected profile');
});

Only allows access if the user is authenticated.

c) Request Validation

app.post('/user', (req, res, next) => {
  if (!req.body.name) {
    return res.status(400).send('Name is required');
  }
  next();
}, (req, res) => {
  res.send('User created');
});

Ensures correct data before processing.

Final Understanding

• Middleware is a function that runs between request and response

• It sits in the request lifecycle before the final handler

• There are different types: application-level, router-level, and built-in

• Middleware executes in order

• next() controls the flow

• It is used for logging, authentication, validation, and more

Summary

Middleware is the backbone of Express applications. It allows you to break down request handling into small, reusable steps that process data, enforce rules, and control application flow. By chaining middleware functions together, you can build scalable and maintainable systems. Whether it is logging requests, checking authentication, or validating input, middleware gives you full control over how your application behaves at every stage of a request.

Let’s understand everything step by step.

1. Why File Uploads Need Middleware

When a client uploads a file, the request is sent as multipart/form-data, not JSON.

Express by default can handle:

• JSON data (express.json())

• URL-encoded data

But it cannot handle multipart/form-data directly.

This creates two problems:

• You cannot access file data using req.body

• The server cannot process or store uploaded files properly

To solve this, we use middleware that can:

• Parse incoming file data

• Store files on the server

• Make file info available in req.file or req.files

2. What Multer is

Multer is a middleware for Express used to handle file uploads.

It helps you:

• Parse multipart/form-data

• Store files locally or in memory

• Access uploaded file details easily

Install Multer:

npm install multer

Import it:

const multer = require('multer');
//or
import multer  from "multer"

3. Handling Single File Upload

First, you need to configure Multer.

Basic setup:

import multer from "multer"
import express from "express"

const app = express();

// store files in "uploads" folder
const upload = multer({ dest: 'uploads/' });

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

app.listen(3000);

Important:

• 'file' is the name of the input field in your form

Access file info:

console.log(req.file);

Multer stores details like:

• filename

• path

• size

• mimetype

4. Handling Multiple File Uploads

To upload multiple files, use .array().

Example:

app.post('/upload-multiple', upload.array('files', 3), (req, res) => {
  res.send('Multiple files uploaded');
});

• 'files' → input field name

• 3 → maximum number of files

Access files:

console.log(req.files);

You will get an array of file objects.

5. Storage Configuration Basics

Instead of using default storage, you can customize how files are stored.

Disk storage example:

const storage = multer.diskStorage({
  destination: function (req, file, cb) {
    cb(null, 'uploads/');
  },
  filename: function (req, file, cb) {
    const uniqueName = Date.now() + '-' + file.originalname;
    cb(null, uniqueName);
  }
});

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

What this does:

• destination → where file is stored

• filename → how file is named

This helps avoid filename conflicts and organize files better.

6. Serving Uploaded Files

After uploading files, you often want to access them in the browser.

Use Express static middleware:

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

Now you can access files like:

http://your.domain/uploads/filename.jpg

This makes uploaded files publicly accessible.

Final Understanding

• File uploads require middleware because Express cannot handle multipart/form-data by default

• Multer is used to process and store uploaded files

• You can handle single and multiple file uploads easily

• Storage configuration helps control file naming and location

• Uploaded files can be served using static middleware

Summary

Handling file uploads in Express becomes simple with Multer. It acts as a bridge between incoming file data and your server by parsing multipart requests and storing files efficiently. By understanding how to upload single and multiple files, configure storage, and serve uploaded content, you can build features like profile image uploads, document submissions, and media sharing systems. Multer is an essential tool for creating real-world applications that deal with user-generated content.

In this blog, you will understand what Node.js is, why JavaScript was originally limited to browsers, and how Node.js changed that.

1. What Node.js is

Node.js is a runtime environment that allows you to run JavaScript outside the browser, especially on servers.

This means:

• You can build backend applications using JavaScript

• You can create APIs, servers, and full-stack applications

• You use the same language for both frontend and backend

Node.js is not a programming language. It is a tool that runs JavaScript.

2. Why JavaScript Was Originally Browser-Only

When JavaScript was created, its main purpose was to:

• Add interactivity to web pages

• Handle user actions like clicks and form inputs

It ran inside the browser because:

• Browsers had built-in JavaScript engines

• JavaScript was tightly connected to the DOM (Document Object Model)

At that time, backend development was handled by other languages like:

• Java

• PHP

• Python

JavaScript had no way to access system resources like files or networks outside the browser.

3. How Node.js Made JavaScript Run on Servers

Node.js changed everything by allowing JavaScript to run outside the browser.

It did this by:

• Embedding a JavaScript engine (V8)

• Providing system-level APIs (file system, network, etc.)

Now JavaScript could:

• Read and write files

• Handle HTTP requests

• Communicate with databases

This made it possible to use JavaScript for backend development.

4. V8 Engine Overview (High Level)

At the core of Node.js is the V8 engine, which was developed by Google.

What V8 does:

• Converts JavaScript code into machine code

• Executes it very fast

In simple terms:

• You write JavaScript

• V8 understands and runs it efficiently

Node.js uses V8 to execute your code outside the browser.

5. Event-Driven Architecture Idea

Node.js follows an event-driven architecture.

This means:

• The system responds to events (like requests, clicks, or data arrival)

• It does not block while waiting for tasks to complete

Instead:

• Tasks are handled asynchronously

• A central system (event loop) manages execution

Example idea:

• A user sends a request

• Node.js starts processing it

• If something takes time (like database call), it continues handling other requests

• When the result is ready, it responds

This makes Node.js efficient and fast.

6. Real-World Use Cases of Node.js

Node.js is widely used in modern applications.

Common use cases:

1. Building APIs

• REST APIs for web and mobile apps

2. Real-time applications

• Chat apps

• Live notifications

• Online gaming

3. Streaming applications

• Video streaming

• Audio streaming

4. Microservices

• Breaking applications into smaller services

5. Full-stack development

• Using JavaScript for both frontend and backend

Final Understanding

• Node.js allows JavaScript to run on the server

• It removed the limitation of JavaScript being browser-only

• It uses the V8 engine for fast execution

• It follows an event-driven, non-blocking architecture

• It is widely used for scalable and modern applications

Summary

Node.js transformed JavaScript from a browser-only language into a powerful tool for backend development. By combining the V8 engine with system-level capabilities, it enabled developers to build servers, APIs, and scalable applications using a single language. Its event-driven and non-blocking nature makes it especially effective for handling multiple users and real-time interactions. Understanding Node.js is a key step toward becoming a full-stack developer and building modern web applications.

In this blog, you will understand what authentication is, what JWT is, and how it works in a simple and practical way.

1. What Authentication Means

Authentication is the process of verifying a user’s identity.

In simple terms:

• User provides credentials (like email and password)

• Server checks if they are correct

• If valid, the user is allowed to access the system

Example:

• Logging into a website

• Accessing your profile

• Making a secure API request

Without authentication, any user could access any data, which is not safe.

2. What JWT is

JWT stands for JSON Web Token.

It is a compact, secure way of transmitting information between client and server.

Instead of storing session data on the server, JWT allows the server to send a token to the client. The client then sends this token with every request.

This makes the system stateless, meaning:

• Server does not need to remember user sessions

• Each request carries its own authentication data

3. Structure of a JWT

A JWT consists of three parts separated by dots:

Header.Payload.Signature

Each part has a specific purpose.

a) Header

The header contains metadata about the token.

Example:

{
  "alg": "HS256",
  "typ": "JWT"
}

• alg → algorithm used for signing

• typ → token type

b) Payload

The payload contains the actual data (claims).

Example:

{
  "userId": "123",
  "email": "user@example.com"
}

This data is encoded but not encrypted, so it should not contain sensitive information like passwords.

c) Signature

The signature ensures that the token is secure and not tampered with.

It is created using:

• Header

• Payload

• Secret key

Example concept:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

If someone tries to change the payload, the signature will not match.

4. Login Flow Using JWT

Let’s understand how JWT works during login.

Step-by-step flow:

1. User sends login request (email + password)

2. Server verifies credentials

3. If valid, server creates a JWT token

4. Token is sent back to the client

5. Client stores the token (localStorage, cookies, etc.)

Example (Node.js with Express):

const jwt = require('jsonwebtoken');

app.post('/login', (req, res) => {
  const { email, password } = req.body;

  // assume user is valid
  const token = jwt.sign(
    { email: email },
    'secretKey', // remember to store it in .env 
    { expiresIn: '1h' }
  );

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

5. Sending Token with Requests

After login, the client must send the token with every protected request.

Usually, the token is sent in the Authorization header:

Authorization: Bearer <token>

Example request:

fetch('/profile', {
  headers: {
    Authorization: `Bearer ${token}`
  }
});

This allows the server to identify the user making the request.

6. Protecting Routes Using Tokens

To protect routes, the server verifies the token before allowing access.

Example middleware:

const jwt = require('jsonwebtoken');

function authenticate(req, res, next) {
  const authHeader = req.headers.authorization;

  if (!authHeader) {
    return res.status(401).send('Token missing');
  }

  const token = authHeader.split(' ')[1];

  try {
    const decoded = jwt.verify(token, 'secretKey');
    req.user = decoded;
    next();
  } catch (err) {
    res.status(403).send('Invalid token');
  }
}

Using middleware:

app.get('/profile', authenticate, (req, res) => {
  res.send(`Welcome ${req.user.email}`);
});

Only users with a valid token can access this route.

Final Understanding

• Authentication verifies user identity

• JWT is a token-based authentication method

• It contains Header, Payload, and Signature

• Server generates token after login

• Client sends token with every request

• Protected routes verify the token before access

Summary

JWT provides a simple and scalable way to handle authentication in Node.js applications. Instead of maintaining sessions on the server, all necessary information is stored inside the token itself. This makes the system stateless and efficient. By understanding how tokens are generated, sent, and verified, you can build secure APIs and protect sensitive routes in your application. JWT is widely used in modern web development and is an essential concept for building real-world backend systems.

Let’s understand this step by step.

1. What Express.js is

Express.js is a minimal and flexible web framework for Node.js.

It helps you:

• Create servers easily

• Handle routes (URLs)

• Manage requests and responses

• Build APIs quickly

Instead of writing long and repetitive code using Node’s http module, Express gives you simple methods to handle everything.

2. Why Express Simplifies Node.js Development

Without Express, creating a server looks like this:

const http = require('http');

const server = http.createServer((req, res) => {
  if (req.url === '/about') {
    res.end('About Page');
  }
});

server.listen(3000);

As your application grows, this becomes hard to manage.

With Express, the same thing becomes:

const express = require('express');
const app = express();

app.get('/about', (req, res) => {
  res.send('About Page');
});

app.listen(3000);

Express provides:

• Cleaner syntax

• Easy routing

• Built-in middleware support

• Better organization of code

3. Creating Your First Express Server

First, install Express:

npm init -y
npm install express

Now create a file app.js:

const express = require('express');
const app = express();

// basic route
app.get('/', (req, res) => {
  res.send('Welcome to Express Server');
});

// start server
app.listen(3000, () => {
  console.log('Server running on port 3000');
});

Run the server:

node app.js

Open browser:

http://localhost:3000

You will see your response.

4. Handling GET Requests

GET requests are used to fetch data from the server.

Example:

app.get('/users', (req, res) => {
  res.send('List of users');
});

You can also access query data:

app.get('/search', (req, res) => {
  const keyword = req.query.keyword;
  res.send(`Searching for ${keyword}`);
});

5. Handling POST Requests

POST requests are used to send data to the server.

Before handling POST data, remember to enable JSON parsing

app.use(express.json());

Example:

app.post('/users', (req, res) => {
  const user = req.body;
  res.send(`User received: ${JSON.stringify(user)}`);
});

You can test POST requests using tools like Postman or frontend forms.

6. Sending Responses

Express provides different methods to send responses:

Send text:

res.send('Hello World');

Send JSON:

res.json({ message: 'Success' });

Send status:

res.status(200).send('OK');

Send file:

res.sendFile(__dirname + '/index.html');

These methods make it easy to control what the client receives.

Final Understanding

• Express.js is a lightweight framework built on Node.js

• It simplifies server creation and routing

• You can easily handle GET and POST requests

• Request data can be accessed using req

• Responses are sent using res methods

• It helps organize backend code in a clean and scalable way

Summary

Express.js removes much of the complexity involved in using Node.js directly. Instead of manually handling request URLs and responses, you define clear routes using simple methods like app.get() and app.post(). This makes your code easier to read, maintain, and scale. By learning how to create routes and handle requests in Express, you take an important step toward building real-world backend applications such as REST APIs, authentication systems, and full-stack projects.

1. Installing Node.js

To begin, you need to install Node.js on your system.

• Go to the official website: https://nodejs.org

• Download the LTS (Long Term Support) version (recommended for beginners)

• Run the installer and follow the default steps

The installation also includes npm (Node Package Manager), which is used to install libraries.

2. Checking Installation Using Terminal

After installing, you should verify that Node.js is correctly installed.

Open your terminal or command prompt and run:

node -v

This will show the installed Node.js version.

Next, check npm:

npm -v

If both commands return versions, your setup is successful.

3. Understanding Node REPL

Node.js provides a built-in environment called REPL.

REPL stands for:

• Read

• Evaluate

• Print

• Loop

It allows you to run JavaScript code directly in the terminal.

Start REPL:

node

Now you can type JavaScript:

2 + 3

Output:

5

You can also try:

console.log("Hello from REPL");

To exit REPL:

.exit

REPL is useful for quick testing and learning.

4. Creating Your First JavaScript File

Now let’s create your first Node.js program.

1. Create a new folder (for example: node-app)

2. Inside the folder, create a file named:

app.js

1. Add the following code:

console.log("Hello, Node.js!");

5. Running Script Using Node Command

To run your file, open terminal in the same folder and execute:

node app.js

Output:

Hello, Node.js!

This is your first Node.js program running successfully.

6. Writing a Hello World Server

Now let’s create a simple server using Node.js.

Update your app.js file:

const http = require('http');

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

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

What this code does:

• Imports the built-in http module

• Creates a server

• Sends a response when a request comes

• Starts listening on port 3000

Run the server:

node app.js

Now open your browser and go to:

http://localhost:3000

You will see:

Hello World from Node.js Server

Final Understanding

• You installed Node.js and npm on your system

• Verified the installation using terminal commands

• Learned how to use the REPL environment for quick experimentation

• Created your first JavaScript file and executed it using Node

• Built a basic HTTP server and understood how it responds to requests

• Learned how Node.js runs outside the browser and can be used to create backend applications

Summary

By completing these steps, you have built a strong foundation in Node.js. You now understand how to set up the environment, run JavaScript outside the browser, and create a working server. This is the first step toward building real-world applications such as APIs, web servers, and full-stack projects. From here, you can start exploring frameworks like Express.js, working with databases, and building scalable backend systems.

If Node.js is single-threaded, how does it handle thousands of requests at the same time?

At first glance, this sounds impossible. In many traditional systems, handling multiple users usually means using multiple threads. But Node.js takes a completely different approach.

Let’s understand this step by step in a clear and detailed way.

1. Single-Threaded Nature of Node.js

Node.js executes JavaScript code on a single main thread. This means:

• Only one piece of JavaScript code runs at a time

• There is no parallel execution of JavaScript like in multi-threaded environments

• All synchronous code runs line by line

Example:

console.log("Start");
console.log("Processing...");
console.log("End");

Output:

Start
Processing...
End

This behaviour is straightforward. The code runs from top to bottom.

However, this creates a concern: If one task takes a long time, will everything else stop?

If Node.js worked only like this, it would not scale. But this is where its architecture becomes powerful.

2. The Role of the Event Loop

The Event Loop is the core mechanism that allows Node.js to handle concurrency.

Instead of blocking the main thread while waiting for operations like file reading or database queries, Node.js uses an event-driven system.

Node.js does not wait for slow operations. It registers them and moves on.

Example:

console.log("Start");

setTimeout(() => {
  console.log("Timeout finished");
}, 2000);

console.log("End");

Output:

Start
End
Timeout finished

Here is what actually happens:

1. "Start" is printed

2. The setTimeout is handed off to the system

3. Node.js continues execution and prints "End"

4. After 2 seconds, the callback is pushed into a queue

5. The Event Loop picks it up and executes it

The Event Loop constantly checks:

• Is the main thread free?

• Are there any completed tasks waiting?

If yes, it processes them.

3. Delegating Tasks to Background Workers

Node.js uses a library called libuv to manage asynchronous operations.

When Node.js encounters tasks such as:

• File system operations (reading/writing files)

• Database queries

• Network requests (API calls)

• Timers

It does not handle them directly on the main thread.

Instead, it delegates these tasks to:

• The operating system

• A thread pool managed by libuv

Flow of execution:

1. A request comes in

2. Node.js identifies if the task is blocking or non-blocking

3. If it is time-consuming, it sends it to a background worker

4. The main thread continues handling other tasks

5. Once the background task is complete, its callback is placed in a queue

6. The Event Loop executes the callback when the main thread is free

This design ensures that the main thread is never stuck waiting.

4. Handling Multiple Client Requests

Let’s understand this with a real-world scenario.

Imagine three users send requests to a server:

• User A: requests a simple response (fast)

• User B: requests data from a database (slow)

• User C: requests another simple response (fast)

In a blocking system:

1. User A is processed

2. User B starts and blocks the server

3. User C has to wait until User B is done

This leads to delays and poor performance.

In Node.js:

1. User A is processed immediately

2. User B’s database request is sent to a background worker

3. User C is processed without waiting

4. When User B’s data is ready, the response is sent

Node.js can keep accepting and processing new requests while waiting for slower ones to complete.

This is called non-blocking I/O.

5. Why Node.js Scales Well

Node.js is designed to handle large numbers of concurrent connections efficiently.

Reasons for high scalability:

1. Non-blocking architecture Node.js does not stop execution for slow operations.

2. Event-driven model Instead of creating new threads for each request, it uses events and callbacks.

3. Low memory usage Traditional servers create a new thread per request, which consumes memory. Node.js avoids this.

4. Efficient handling of I/O-heavy tasks Most web applications involve I/O operations (API calls, database queries), which Node.js handles very well.

Where Node.js performs best:

• REST APIs

• Real-time applications (chat apps, notifications)

• Streaming services

• Microservices architecture

Where Node.js is not ideal:

• CPU-intensive operations (e.g., video processing, heavy calculations)

In such cases, the single thread can become a bottleneck.

6. Putting It All Together

Here is the complete flow of how Node.js handles multiple requests:

1. A client sends a request

2. Node.js receives it on the main thread

3. If the task is fast, it processes it immediately

4. If the task is slow, it delegates it to background workers

5. Node.js continues handling other incoming requests

6. Once background tasks are complete, callbacks are queued

7. The Event Loop executes them when the main thread is available

This cycle continues continuously, allowing Node.js to serve many users efficiently.

Final Understanding

• Node.js uses a single thread for executing JavaScript

• It relies heavily on asynchronous programming

• The Event Loop manages task execution

• Slow operations are handled outside the main thread

• Multiple requests are processed without blocking

One-Line Summary

Node.js handles multiple requests efficiently by using a single thread combined with an event loop, non-blocking operations, and background workers.

1. What URL parameters are

2. What query parameters are

3. Differences between them

4. Accessing params in Express

5. Accessing query strings in Express

6. When to use params vs query

What does we understand by the query string and URL parameters ? When you start working with backend using Express.js, one thing you’ll see very often is URL parameters and query strings. At first, both look similar, but they are used for different purposes.

Let’s understand them in a simple way

1. What are URL Parameters?

URL parameters are part of the URL path itself. They are used to identify a specific resource.

Example:

/users/101

Here, 101 is a URL parameter.

In Express, we define it using :

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

If you open:

/users/101

You’ll get:

User ID is 101

• Used to identify specific data

• Mandatory (usually required in route)

2. What are Query Parameters?

Query parameters come after the ? in a URL and are used to send extra information.

Example:

/products?category=shoes&price=1000

Here:

• category=shoes

• price=1000

In Express:

app.get('/products', (req, res) => {
  const category = req.query.category;
  const price = req.query.price;

  res.send(`Category: \({category}, Price: \){price}`);
});

If you open:

/products?category=shoes&price=1000

You’ll get:

Category: shoes, Price: 1000

• Used for filtering, sorting, optional data

• Optional (can be missing)

3. Differences Between URL Params and Query Strings

4. Accessing URL Params in Express

app.get('/posts/:postId', (req, res) => {
  console.log(req.params);
  res.send(req.params.postId);
});

If URL is:

/posts/55

Output:

55

5. Accessing Query Strings in Express

app.get('/search', (req, res) => {
  console.log(req.query);
  res.send(req.query.keyword);
});

If URL is:

/search?keyword=react

Output:

react

6. When to Use Params vs Query?

This is where most beginners get confused, so remember this simple rule

Use URL Params when:

• You are fetching specific resource

• Example:

  • /users/101

  • /posts/45

Use Query Strings when:

• You are filtering or customizing results

• Example:

  • /products?category=electronics

  • /users?page=2&limit=10

Final Understanding

• Params = "Which exact item?"

• Query = "How do you want the data?"

Bonus Tip

Both can be used together:

/users/101?active=true

• 101 → specific user (param)

• active=true → extra condition (query)

That’s it! Once you understand this difference, working with APIs in Express becomes much easier!

But what happens after upload is where most beginners get confused:

• Where does the file go?

• How do we access it later?

• How does Express serve it?

Let’s break this down step by step.

Where Uploaded Files Are Stored

When you upload a file using something like multer, the file doesn’t magically stay in memory.

It is stored somewhere — usually on your server.

Common approach

const storage = multer.diskStorage({
  destination:"uploads/",
  filename: (req,file,cb) => {
cb(null,Date.now()+"-"+file.originalname);
  }
});

What this does

• destination → folder where files go

• filename → how file is named

So if a user uploads image.png, it might become:

uploads/1713950000000-image.png

Key point

• Files are stored on your server filesystem

• You control where and how

Local Storage vs External Storage

This is an important concept.

1. Local Storage (on your server)

Files are saved in your project folder:

project/
 ├── uploads/
 │    ├── file1.jpg
 │    ├── file2.png

Pros

• Simple to implement

• No extra services needed

Cons

• Not scalable

• Files lost if server restarts or crashes

• Not suitable for multiple servers

2. External Storage (Cloud)

Files are stored outside your server.

Examples:

• Amazon S3

• Cloudinary

• Google Cloud Storage

Pros

• Highly scalable

• Reliable and persistent

• CDN support (faster delivery)

Cons

• Slightly complex setup

• Cost involved

Simple understanding

• Local = “files live with your server”

• External = “files live somewhere else”

Serving Static Files in Express

Now you have files stored.

But how do users access them?

By default, Express does NOT expose your folders.

You have to explicitly allow it.

Solution: static middleware

import express from "express";

const app = express();

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

What this means

• You are telling Express:

  “Anything inside uploads/ can be accessed via /uploads URL”

Accessing Uploaded Files via URL

Now suppose your file is stored as:

uploads/1713950000000-image.png

With static setup:

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

You can access it like:

http://localhost:3000/uploads/1713950000000-image.png

Key point

• File path → becomes URL

• No extra route needed

Security Considerations for Uploads

This is where most people mess up.

Uploading files without validation is risky.

1. File Type Validation

Never trust file extensions.

Use mimetype:

const fileFilter= (req,file,cb) => {
const allowed= ["image/jpeg","image/png"];

if (allowed.includes(file.mimetype)) {
cb(null,true);
  }else {
cb(newError("Invalid file type"));
  }
};

2. File Size Limit

Prevent huge uploads:

limits: {fileSize:5*1024*1024 }// 5MB

3. Avoid Executable Files

Never allow:

• .js

• .exe

• .sh

These can be dangerous if executed.

4. Rename Files

Don’t trust original names:

cb(null,Date.now()+"-"+file.originalname);

Prevents:

• overwriting files

• malicious filenames

5. Store Outside Root (Advanced)

Instead of:

public/uploads

Use:

uploads/

And expose only via controlled routes if needed.

6. Authentication (Important)

Not all files should be public.

For sensitive files:

• Don’t use express.static

• Create protected routes

Final Understanding

• Upload → file saved on server or cloud

• Storage → local or external

• Serving → using express.static

• Access → via URL

• Security → must not be ignored

Simple Mental Model

• Upload = “file comes in”

• Storage = “file is saved somewhere”

• Static serving = “file becomes accessible via URL”

But the confusion usually starts here:

• What are sessions?

• What are cookies?

• What is JWT?

• And why do people argue about them so much?

Let’s break everything down step by step.

What Sessions Are

A session is a way for the server to remember a user.

When a user logs in:

1. Server creates a session (some data stored on server)

2. Server generates a unique session ID

3. Sends that session ID to the client (usually via cookies)

Now for every request:

• Client sends session ID

• Server looks it up

• If found → user is authenticated

Example flow

User logs in → Server creates session → Session stored in DB/memory
             → Session ID sent to browser

Next request → Browser sends session ID → Server validates → Access granted

Key point

• Data is stored on the server

• Client only holds a reference (session ID)

What Cookies Are

A cookie is just a small piece of data stored in the browser.

That’s it.

Cookies are not authentication by themselves — they are just a storage mechanism.

What cookies can store:

• Session IDs

• JWT tokens

• User preferences

Example

Set-Cookie: sessionId=abc123

Browser automatically sends cookies with every request to that domain.

Important

Cookies are used with both sessions and JWT.

What JWT Tokens Are

JWT stands for JSON Web Token.

It’s a self-contained token that carries user data.

Structure of JWT

header.payload.signature

Example:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJ1c2VySWQiOjEyMywicm9sZSI6InVzZXIifQ
.signature

What happens during login:

1. User logs in

2. Server generates JWT

3. Sends it to client

4. Client stores it (cookie/localStorage)

5. Client sends JWT in every request

Server verification

Server does NOT store anything.

It just verifies the token:

jwt.verify(token,SECRET_KEY);

If valid → user is authenticated

Key point

• Data is stored inside the token

• Server does not need to remember anything

Stateful vs Stateless Authentication

This is the core difference.

Stateful (Sessions)

• Server stores user data

• Needs memory/database

• Every request depends on server state

Client → Session ID → Server → Lookup session → Response

Stateless (JWT)

• Server stores nothing

• Token contains everything

• Each request is independent

Client → JWT → Server → Verify → Response

Differences: Session vs JWT

1. Storage

Session

• Stored on server

JWT

• Stored on client

2. Scalability

Session

• Harder to scale (needs shared session store like Redis)

JWT

• Easy to scale (no storage needed)

3. Security

Session

• Safer by default

• Server controls everything

JWT

• Risky if token is leaked

• Cannot be invalidated easily

4. Performance

Session

• Requires DB/memory lookup

JWT

• Faster (just verify token)

5. Logout Handling

Session

• Easy → delete session

JWT

• Hard → need blacklist or expiry

When to Use Each Method

Use Sessions when:

• You want better security control

• You are building traditional web apps

• You need easy logout handling

• You don’t care much about scaling yet

Use JWT when:

• You are building APIs

• You need scalability

• You have multiple services (microservices)

• You want stateless architecture

Use Cookies when:

• You need automatic request sending

• You are working with browsers

• You want secure storage (HttpOnly, Secure flags)

Final Understanding

• Cookies → storage mechanism

• Sessions → stateful authentication (server-based)

• JWT → stateless authentication (token-based)

If you remember just this, you’re already ahead of most beginners.

Simple Mental Model

• Session = “Server remembers you”

• JWT = “You carry your identity”

• Cookie = “Browser stores stuff for you”

What we are going to learn

• Why async code exists in Node.js

• Callback-based async execution

• Problems with nested callbacks

• Promise-based async handling

• Benefits of promises

What is Async Code and Why It Exists

Let’s start with a basic question:

Why doesn’t Node.js execute everything line by line like traditional programs?

Because Node.js is single-threaded.

This means:

• It can run only one task at a time

• But it still needs to handle multiple users, requests, file operations, and API calls

Now imagine this:

const data = readFileSync("largeFile.txt");
console.log(data);

If the file is large, Node.js will:

• Stop execution

• Wait until the file is fully read

• Then move forward

This creates a problem:

While waiting, the server cannot handle other requests.

Solution: Asynchronous Code

Instead of waiting, Node.js uses async code.

The idea is simple:

Start a task, and when it finishes, notify me. Meanwhile, I will continue doing other work.

Example:

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

console.log("This runs first");

Output:

This runs first
(file content later)

Node.js does not block execution, which makes it fast and efficient.

Callback-Based Async Execution

The first approach to handling async operations in Node.js was callbacks.

A callback is simply a function passed as an argument to another function, which is executed later.

Example:

function fetchData(callback) {
setTimeout(() => {
callback("Data received");
  },2000);
}

fetchData((data) => {
console.log(data);
});

Flow:

1. The async task starts

2. Node.js continues execution

3. Once the task finishes, the callback runs

Problems with Nested Callbacks (Callback Hell)

Now consider multiple dependent async operations:

loginUser((user) => {
getProfile(user, (profile) => {
getPosts(profile, (posts) => {
console.log(posts);
    });
  });
});

This structure is called callback hell.

Problems:

• Code becomes deeply nested

• Hard to read and understand

• Debugging becomes difficult

• Error handling is inconsistent

This pattern is often called the "pyramid of doom".

Promise-Based Async Handling

To solve the problems of callbacks, JavaScript introduced promises.

A promise represents a value that will be available in the future.

It has three states:

• Pending

• Resolved

• Rejected

Example using Promise

function fetchData() {

return new Promise((resolve,reject) => {

setTimeout(() => {
resolve("Data received");
    },2000);
  });
}

fetchData()
.then((data) => {
console.log(data);
  })
.catch((err) => {
console.error(err);
  });

Chaining Promises

loginUser()
.then((user) =>getProfile(user))
.then((profile) =>getPosts(profile))
.then((posts) =>console.log(posts))
.catch((err) =>console.error(err));

This removes nesting and creates a clear, linear flow.

Benefits of Promises

1. Better readability

Code is flatter and easier to understand compared to nested callbacks.

2. Centralized error handling

Instead of handling errors at every step, a single .catch() can handle failures.

3. Easy chaining of async operations

Multiple async steps can be connected in a clean sequence.

4. Foundation for async/await

Promises enable modern syntax like async/await:

async function run() {
const data = await fetchData();
console.log(data);
}

This looks like synchronous code but works asynchronously.

Final Thoughts

• Node.js uses async code to avoid blocking execution

• Callbacks were the first solution but led to complex and unreadable code

• Promises improved structure and made async code easier to manage

• Today, async/await is the most commonly used approach, built on top of promises

What we are going to learn:

• What Map is

• What Set is

• Difference between Map and Object

• Difference between Set and Array

• When to use Map and Set

What Map is?

A Map is a collection of key-value pairs, just like an object — but more powerful and flexible.

The main difference is:
In a Map, keys can be of any type (not just strings).

Example:

const map = new Map();

map.set("name", "Josh");
map.set(1, "number key");
map.set(true, "boolean key");

console.log(map.get("name")); // Josh
console.log(map.get(1)); // number key

Important methods:

map.set(key, value)   // add value
map.get(key)          // get value
map.has(key)          // check if key exists
map.delete(key)       // remove key
map.clear()           // remove all

What Set is?

A Set is a collection of unique values.

It automatically removes duplicates.

Example:

const set = new Set([1, 2, 2, 3, 4, 4]);

console.log(set); // {1, 2, 3, 4}

Important methods:

set.add(value)     // add value
set.has(value)     // check value
set.delete(value)  // remove value
set.clear()        // remove all

Difference between Map and Object

Example:

const obj = {};
obj[1] = "one";   // converted to string "1"

const map = new Map();
map.set(1, "one"); // stays number

So Map keeps the original type of keys.

Difference between Set and Array

Example:

const arr = [1, 2, 2, 3];
const set = new Set(arr);

console.log(arr); // [1, 2, 2, 3]
console.log(set); // {1, 2, 3}

When to use Map and Set

Use Map when:

• You need key-value pairs

• Keys are not just strings (like numbers, objects)

• You need better performance for frequent updates

Example:

const userRoles = new Map();

userRoles.set("user1", "admin");
userRoles.set("user2", "editor");

Use Set when:

• You need unique values only

• You want to remove duplicates

• You just care about existence (not position)

Example:

const numbers = [1, 2, 2, 3, 4];
const uniqueNumbers = new Set(numbers);

console.log(uniqueNumbers); // {1, 2, 3, 4}

Final Thoughts

• Map is like an advanced object with more flexibility

• Set is perfect when you only care about unique values

Both are very useful in real-world applications, especially when working with data.

Start using them in small projects, and you’ll quickly understand where they fit best.

1. What destructuring means

2. Destructuring arrays

3. Destructuring objects

4. Default values

5. Benefits of destructuring

What Destructuring means?

Destructuring mean unpacking values from arrays, or properties from objects, into variables. For example you have a bag pack that contains your things, so you take things out of it when you need them , destructuring is just like that. Now let's see how we can destructure values in JavaScript with simple example:

let p, q, rest;
[p,q] = [10, 20]
console.log(p) // 10
console.log(q) // 20

[p,q, rest] = [10, 20, 30, 40, 50]
console.log(rest)  // [30, 40, 50]  

Destructuring arrays

Using destructuring syntax we can easily unpack the the values form arrays.

const [a, b, c, d, e] = [10, 20, 30, 40, 50]

console.log(a, b, c, d, e)  // 10, 20, 30, 40, 50

Destructuring objects

We can also use destructuring syntax to easily extract values from the objects:

const user = {
name: "Josh",
age: 20,
address: "Paris",
phone: "4903XXXXXXX"
}

const { name, age, phone } = user

console.log(name, age, phone) // Josh, 20, 4903XXXXXXX

As you can see in the example, we can easily unpack the desired values from the objects using destructuring syntax.

Default values

While destructuring we can also give default values to any property. As each property can have a default value:

const [a = 1] = []  // a is 1
const { b = 2 } = { b: undefined } // b is 2
const {c = 3 } = { c: null }  // c is null 
// if you are confuse why c is null ---> because null is a deliberate give empty value whereas undefined is the default value assigned by JavaScript when we do not give any value.

Benefits of destructuring

So why should we use destructuring syntax instead of the normal way?

Let’s understand this step by step.

1. Cleaner and shorter code

Without destructuring:

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

const name = user.name; 
const age = user.age;

With destructuring:

const { name, age } = user;

You can see how much cleaner and shorter it becomes.

2. Easy to pick only what you need

Sometimes objects have many properties, but you only need a few.

const user = {
 name: "Josh",
 age: 20, 
address: "Paris", 
phone: "12345" };

const { name, phone } = user;

console.log(name, phone);

You don’t need to access everything manually.

3. Works great with functions

Destructuring is very useful when working with functions.

Without destructuring:

function printUser(user) {
 console.log(user.name, user.age);
 }

With destructuring:

function printUser({ name, age }) { 
console.log(name, age);
 }

This makes your function parameters cleaner and easier to read.

4. Helps avoid repetition

Instead of writing the same object name again and again:

console.log(user.name);
console.log(user.age);

You can do:

const { name, age } = user;

console.log(name); console.log(age);

Less repetition = better readability.

5. Useful with APIs and real-world data

When working with APIs, you often get large objects.

Destructuring helps you quickly extract only what you need:

const response = { data: { 
id: 1, 
title: "Post", 
author: "John" 
} };

// vs

const { title, author } = response.data;

Final Thoughts

Destructuring might look confusing at first, but once you understand it, it becomes one of the most useful features in JavaScript.

It helps you:

write cleaner code reduce repetition make your code easier to read work better with objects and arrays

Start using it in small examples, and slowly you’ll feel comfortable using it in real projects.

Type a command → press enter → get output.

But during this assignment, my thinking changed.

Instead of asking:
“What command should I run?”

I started asking:
“What is actually happening inside the system when I run this?”

That small shift completely changed how I understand Linux.

Linux is Not a Black Box

Earlier, I treated Linux like a black box.

Now I see it differently.

Linux does not hide things. It exposes almost everything through files.

Processes, networking, users, hardware, system behavior — everything is visible if you know where to look.

/etc — Where System Rules Live

At first, /etc looked like a random directory.

But when I explored it:

cat /etc/hosts
cat /etc/resolv.conf
cat /etc/passwd

I realized something important:

/etc is where Linux stores its rules.

Examples:

• /etc/hosts maps domains to IP addresses

• /etc/resolv.conf defines DNS servers

• /etc/passwd stores user information

These are not passive files.

They are actively used by the system.

If you change them, system behavior changes.

So Linux is not fixed. It is configurable.

DNS — What Happens When You Open a Website

When you type a domain like google.com, the system needs an IP address.

Flow:

1. System reads /etc/resolv.conf

2. Contacts DNS server

3. Gets IP address

4. Starts connection

Important observation:

If DNS is misconfigured:

• Internet appears broken

• But the issue is only name resolution

Many network problems are actually DNS problems.

Routing — How Data Finds Its Path

After getting an IP, the system must decide where to send data.

This is handled by routing.

cat /proc/net/route

Routing table defines:

• destination

• gateway

• interface

Flow:

• Application sends request

• Kernel checks routing table

• Kernel decides path

Applications do not control routing. The kernel does.

/proc — Live System Data

This was the most interesting part.

echo $$
ls /proc/$$
cat /proc/meminfo
cat /proc/cpuinfo

At first, /proc looks like a normal directory.

But it is not.

It is created dynamically by the kernel.

There are no real files stored on disk.

What it provides:

• Real-time system information

• Process-specific data

• Instant updates

When you read /proc, you are reading live kernel data.

/dev — Hardware as Files

In Linux, hardware is also represented as files.

ls /dev
echo "hello" > /dev/null

Examples:

• disks

• input devices

• system devices

Special case:

• /dev/null discards all data written to it

Linux follows one core idea:

Everything is treated as a file.

This simplifies how the system interacts with hardware.

Users — Simple and Transparent

cat /etc/passwd

This file contains:

• username

• user ID

• home directory

Passwords are stored separately in /etc/shadow.

Linux stores user data in structured files instead of hiding it.

Permissions — Built-in Security

ls -l file.txt
chmod 000 file.txt
cat file.txt

Result: access denied.

Reason:

The kernel checks permissions before allowing access.

Commands do not enforce security. The kernel does.

Services — Background System Operations

systemctl status
ls /etc/systemd

Observations:

• Services run in the background

• They start automatically

• They are controlled through configuration

Linux systems are structured. Nothing runs randomly.

Boot Process — Where Everything Starts

ls /boot

Contains:

• kernel

• bootloader files

Boot flow:

1. Bootloader loads kernel

2. Kernel initializes system

3. Services start

This is the starting point of the system.

Final Understanding

Everything connects like this:

Command → Kernel → File System → Hardware

Each part has a role:

• /etc controls behavior

• /proc shows system state

• /dev connects hardware

• /var/log records activity

Conclusion

Earlier:

Linux = commands

Now:

Linux = a transparent, structured system

The key realization:

Linux does not hide complexity.

It organizes it in a way that can be explored and understood.

Once you understand this structure, Linux becomes logical and much easier to work with.

1. What problem promises solve

2. Promise states (pending, fulfilled, rejected)

3. Basic promise lifecycle

4. Handling success and failure

5. Promise chaining concept

We use promises to handle an asynchronous operations ...but wait can't we do the work without them ? of course we can and to do that work we used to use callbacks.

let's see an example:

getUser(function(user) {
  getPosts(user, function(posts) {
    getComments(posts, function(comments) {
      console.log(comments);
    });
  });
});

As you can see from above code, how difficult it is to manage it and understand it. This many callbacks give rise to callback hell. That is where promises come.

Promises solve this by:

• Making async code clean & readable

• Handling success and errors properly

• Allowing chaining instead of nesting

Promises has 3 states:

• pending: initial state, neither fulfilled nor rejected.

• fulfilled: meaning that the operation was completed successfully.

• rejected: meaning that the operation failed.

Promise lifecycle

First a promise is created that starts as pending by default. Then if it resolves to success it gets fulfilled. Otherwise it gets rejected.

const promise = new Promise ((resolve,reject) => {
let success = true;
if(success){
resolve("Task completed")
} else {
reject("Task failed")
 }
});

Handling success and failure

To handle success and failure in promises we use .then() and .catch(). To handle success we use .then() whereas to to handle failure we use .catch(), let's see with an example:

promise
.then((result)=> {
console.log(result)  // success
})
.catch((error)=> {
console.log(error)   // failure
})

Remember -

• .then() runs when fulfilled

• .catch() runs when rejected

Promise chaining concept

Promise chaining concept is really a very powerful concept of JavaScript. Instead of using nesting which makes code hard to read and maintain we use chaining.

getUser()
  .then((user) => {
    return getPosts(user);
  })
  .then((posts) => {
    return getComments(posts);
  })
  .then((comments) => {
    console.log(comments);
  })
  .catch((error) => {
    console.log(error);
  });

Here each .then() returns a new promise, data flow step wise and error gets caught in catch(). As you can see this is much better than the callbacks.

Final Thought

Promises help us write clean code for asynchronous work - which is easy to read, understand and maintain. Promises have 3 states - pending, fulfilled and rejected. And we can use .then() to return many new promises and all errors are caught in .catch() block.