This about this keyword and how it change.

What this Represents

this = reference to caller. Who call function? That who this is.

Simple Definition

this = the object that calling the function. Not the function itself. The thing that call it.

Real Analogy

Waiter in restaurant:

Customer say "I want coffee"
Waiter say "Who want coffee?"
Customer say "Me, I want coffee"

So "I" = the customer (the caller)

In JavaScript:

user.greet()  // user calling greet()
              // So "this" inside greet = user

this = who call the method.

Why this Matter

this let function know who calling it. Function can behave different for different callers.

const user1 = {
  name: 'Alice',
  greet() {
    console.log(`Hello, I'm ${this.name}`);
  }
};

const user2 = {
  name: 'Bob',
  greet() {
    console.log(`Hello, I'm ${this.name}`);
  }
};

user1.greet();  // "Hello, I'm Alice"
                // this = user1

user2.greet();  // "Hello, I'm Bob"
                // this = user2

Same function logic. Different this. Different output.

this in Global Context

In global scope, this = global object.

Browser Global

In browser, global object = window.

console.log(this);  // window (in browser)
console.log(this === window);  // true

console.log(this.innerHeight);  // window.innerHeight

Top level code run in window context. So this = window.

Node.js Global

In Node.js, global object = global (or module context).

console.log(this);  // {} (module context in Node.js)
                    // NOT global in strict module

console.log(global);  // global object

Node.js = different. But usually don't use this in global scope.

Function in Global Scope

function greet() {
  console.log(this);
}

greet();  // Browser: window
          // Node.js: global (in strict mode: undefined)

No caller = default caller = global object.

Problem: Losing this

const user = {
  name: 'Alice',
  greet() {
    console.log(this.name);
  }
};

const func = user.greet;  // Extract method
func();  // undefined (or error)

// Why?
// func() have no caller object
// So this = global or undefined
// global.name = undefined

When extract method = lose context = lose this.

this Inside Objects

this = the object calling method.

Method Call

Object call its own method. this = object.

const user = {
  name: 'Alice',
  age: 25,
  
  greet() {
    console.log(`I'm ${this.name}`);
  },
  
  haveBirthday() {
    this.age++;
    console.log(`Now ${this.age}`);
  }
};

user.greet();         // this = user
                      // "I'm Alice"

user.haveBirthday();  // this = user
                      // Now 26

user.greet() = user calling greet = this = user.

Accessing Object Properties

Method use this to access own properties.

const car = {
  brand: 'Toyota',
  speed: 0,
  
  accelerate() {
    this.speed += 10;
    console.log(`\({this.brand} speed: \){this.speed}`);
  }
};

car.accelerate();  // "Toyota speed: 10"
car.accelerate();  // "Toyota speed: 20"

console.log(car.speed);  // 20

this.speed refer to car's speed property. this.brand refer to car's brand property.

Multiple Objects, Same Method

const person1 = {
  name: 'Alice',
  introduce() {
    console.log(`I'm ${this.name}`);
  }
};

const person2 = {
  name: 'Bob',
  introduce() {
    console.log(`I'm ${this.name}`);
  }
};

person1.introduce();  // "I'm Alice" (this = person1)
person2.introduce();  // "I'm Bob"   (this = person2)

Different objects, same method logic. this different.

Nested Objects

const company = {
  name: 'TechCorp',
  owner: {
    name: 'Alice',
    greet() {
      console.log(`I'm ${this.name}`);  // this = owner (not company)
    }
  }
};

company.owner.greet();  // "I'm Alice"
                        // this = owner object (immediate caller)

this = immediate caller. Not parent object.

this Inside Functions

Function context different from object context.

Regular Function Call

function greet() {
  console.log(this);
}

greet();  // Browser: window
          // Node.js: undefined (strict mode) or global

// No object call it = default context

Function standalone = no object caller = this = global or undefined.

Function with Caller

const user = { name: 'Alice' };

function greet() {
  console.log(`Hi, I'm ${this.name}`);
}

// Call function with user context
greet.call(user);  // "Hi, I'm Alice"
                   // Force this = user

.call() = force who caller is.

Method vs Function

const user = {
  name: 'Alice',
  
  method() {
    console.log(this.name);  // this = user (method call)
  },
  
  getFunction() {
    function inner() {
      console.log(this.name);  // this = global/undefined (function call)
    }
    return inner;
  }
};

user.method();        // "Alice" (this = user)

const func = user.getFunction();
func();               // undefined (this = global)

Method = this = caller. Nested function = this = global (lose context).

How Calling Context Change this

this depend on how function called. Three way to call function.

1. Method Call: obj.func()

Object call function. this = object.

const user = {
  name: 'Alice',
  greet() {
    console.log(`Hi, ${this.name}`);
  }
};

user.greet();  // this = user

2. Function Call: func()

Direct call. this = global (or undefined in strict).

function greet() {
  console.log(this);
}

greet();  // this = window (browser) or undefined (strict mode)

3. Using .call() or .apply()

Explicitly set this.

const user1 = { name: 'Alice' };
const user2 = { name: 'Bob' };

function greet() {
  console.log(`Hi, ${this.name}`);
}

greet.call(user1);   // this = user1 → "Hi, Alice"
greet.call(user2);   // this = user2 → "Hi, Bob"

.call(obj) = call function with this = obj.

Difference Visualized

user.greet()
  │
  └─ user calling greet
     └─ this = user

greet()
  │
  └─ no one calling (function call)
     └─ this = global

greet.call(user)
  │
  └─ explicitly set caller
     └─ this = user

Same function. Different caller. Different this.

Arrow Functions and this

Arrow function different from regular function. Arrow function = inherit this from outer scope.

Regular Function

const user = {
  name: 'Alice',
  
  greet() {
    function inner() {
      console.log(this);  // this = global (function call)
    }
    inner();
  }
};

user.greet();  // this inside inner = global (lose context)

Nested function = lose this.

Arrow Function

const user = {
  name: 'Alice',
  
  greet() {
    const inner = () => {
      console.log(this);  // this = user (inherit from greet)
    };
    inner();
  }
};

user.greet();  // this inside inner = user (keep context)

Arrow function = inherit this from parent scope.

When Use Arrow vs Regular

const user = {
  name: 'Alice',
  
  // Regular function = this = user
  greet() {
    console.log(this.name);  // "Alice"
  },
  
  // Arrow function = this inherit from outer
  introduce: () => {
    console.log(this.name);  // undefined (this = window/global)
  }
};

user.greet();      // "Alice" (use regular function in object)
user.introduce();  // undefined (arrow lose this context)

Rule:

• Object method = use regular function (get this = object)
• Nested callback = use arrow function (inherit this)

Practical Example

const button = {
  label: 'Click me',
  
  // ✗ Wrong - regular function lose this
  setupWrong() {
    document.getElementById('btn').addEventListener('click', function() {
      console.log(this.label);  // this = button element (wrong)
                                // not this button object
    });
  },
  
  // ✓ Right - arrow function keep this
  setupRight() {
    document.getElementById('btn').addEventListener('click', () => {
      console.log(this.label);  // this = button object (right)
                                // inherited from setupRight
    });
  }
};

Event listener = arrow function keep this.

Common this Mistakes

Mistake 1: Losing this in Callback

const user = {
  name: 'Alice',
  
  loadData(callback) {
    setTimeout(callback, 1000);
  },
  
  fetch() {
    this.loadData(function() {
      console.log(this.name);  // this = undefined (function call)
    });
  }
};

user.fetch();  // undefined (wrong)

Fix with arrow function:

user.fetch() {
  this.loadData(() => {
    console.log(this.name);  // this = user (right)
  });
}

Mistake 2: Extracting Method Without Context

const user = {
  name: 'Alice',
  greet() {
    console.log(this.name);
  }
};

const greet = user.greet;  // Extract method
greet();  // undefined (lose this)

Fix with .bind():

const greet = user.greet.bind(user);  // Keep this = user
greet();  // "Alice" (right)

.bind() = permanently set this.

Mistake 3: Confusing this in Constructor

function User(name) {
  this.name = name;
  
  this.greet = function() {
    console.log(this.name);  // this = user instance
  };
}

const user = new User('Alice');
user.greet();  // "Alice" (this = user)

new = call function as constructor = this = new instance.

Mistake 4: this in Arrow Function at Object Level

// ✗ Wrong - arrow function at object level
const user = {
  name: 'Alice',
  
  greet: () => {
    console.log(this.name);  // this = window/global
                             // not user object
  }
};

user.greet();  // undefined (wrong)

// ✓ Right - regular function
const user = {
  name: 'Alice',
  
  greet() {
    console.log(this.name);  // this = user
  }
};

user.greet();  // "Alice" (right)

Object method = use regular function. Not arrow function.

Mistake 5: Assuming this Same in Nested Function

const user = {
  name: 'Alice',
  
  process() {
    console.log(this.name);  // "Alice" (this = user)
    
    function inner() {
      console.log(this.name);  // undefined (this = global)
    }
    
    inner();  // this change!
  }
};

user.process();  // "Alice" then undefined

Nested function = new context = this change.

Methods to Control this

1. Using .call()

Call function with specific this.

function greet(greeting) {
  console.log(`\({greeting}, I'm \){this.name}`);
}

const user = { name: 'Alice' };

greet.call(user, 'Hi');  // "Hi, I'm Alice"
                         // this = user

.call(thisArg, arg1, arg2, ...) = set this and call.

2. Using .apply()

Like .call() but arguments as array.

function greet(greeting, emoji) {
  console.log(`\({greeting}, I'm \){this.name} ${emoji}`);
}

const user = { name: 'Alice' };

greet.apply(user, ['Hi', '👋']);  // "Hi, I'm Alice 👋"
                                   // this = user

.apply(thisArg, [args]) = same as call, but array arguments.

3. Using .bind()

Create new function with locked this.

function greet() {
  console.log(`Hi, ${this.name}`);
}

const user = { name: 'Alice' };

const boundGreet = greet.bind(user);  // Create new function

boundGreet();  // "Hi, Alice"
               // this permanently = user

.bind() = don't call immediately. Return new function.

.call() and .apply() = call immediately. .bind() = return function, call later.

Practical Use: Event Listener

const user = {
  name: 'Alice',
  
  setupButton() {
    const button = document.getElementById('btn');
    
    // ✗ Lose this
    // button.addEventListener('click', this.onClick);
    
    // ✓ Keep this
    button.addEventListener('click', this.onClick.bind(this));
  },
  
  onClick() {
    console.log(`Clicked by ${this.name}`);
  }
};

.bind(this) = keep this in event listener.

this in Different Contexts

Global Scope

console.log(this);  // Browser: window, Node.js: depends on module

Inside Object Method

const obj = {
  method() {
    console.log(this);  // this = obj
  }
};

obj.method();

Inside Regular Function

function func() {
  console.log(this);  // undefined (strict) or global (non-strict)
}

func();

Inside Arrow Function

const arrow = () => {
  console.log(this);  // this = outer scope's this
};

Inside Constructor

function Constructor() {
  console.log(this);  // this = new instance
}

new Constructor();

Inside Class

class MyClass {
  method() {
    console.log(this);  // this = instance
  }
}

const obj = new MyClass();
obj.method();

Inside Class Arrow Method

class MyClass {
  method = () => {
    console.log(this);  // this = instance (arrow method)
  }
}

Practical Examples

Example 1: User Object

const user = {
  name: 'Alice',
  age: 25,
  
  greet() {
    console.log(`Hello, I'm ${this.name}`);
  },
  
  birthday() {
    this.age++;
    console.log(`Happy birthday! Now ${this.age}`);
  },
  
  describe() {
    return `\({this.name} is \){this.age} years old`;
  }
};

user.greet();      // "Hello, I'm Alice"
user.birthday();   // "Happy birthday! Now 26"
console.log(user.describe());  // "Alice is 26 years old"

// All use this = user

Example 2: Button Handler

const app = {
  count: 0,
  
  init() {
    document.getElementById('btn').addEventListener(
      'click',
      this.handleClick.bind(this)  // Keep this = app
    );
  },
  
  handleClick() {
    this.count++;
    console.log(`Clicked ${this.count} times`);
  }
};

app.init();
// Click button → "Clicked 1 times"
// Click button → "Clicked 2 times"

Without .bind(this) = this = button element (wrong).

Example 3: Method Borrowing

const user1 = { name: 'Alice' };
const user2 = { name: 'Bob' };

function greet() {
  console.log(`Hi, ${this.name}`);
}

greet.call(user1);   // "Hi, Alice"
greet.call(user2);   // "Hi, Bob"

// Same function, different this, different output

Use .call() to borrow function with different context.

Example 4: Constructor Pattern

function User(name, age) {
  this.name = name;
  this.age = age;
  
  this.greet = function() {
    console.log(`I'm ${this.name}`);
  };
}

const user1 = new User('Alice', 25);
const user2 = new User('Bob', 30);

user1.greet();  // "I'm Alice" (this = user1)
user2.greet();  // "I'm Bob"   (this = user2)

new = create instance, set this = instance.

Example 5: React Class Component

class Counter extends React.Component {
  constructor() {
    super();
    this.state = { count: 0 };
    
    // Bind to keep this = component
    this.handleClick = this.handleClick.bind(this);
  }
  
  handleClick() {
    this.setState({ count: this.state.count + 1 });
  }
  
  render() {
    return <button onClick={this.handleClick}>Count: {this.state.count}</button>;
  }
}

React = need bind or arrow function to keep this.

this Cheat Sheet

WHO CALL IT?           this = WHAT?
═════════════════      ══════════════════════
obj.method()           obj (the caller object)

func()                 undefined (strict) or global (non-strict)

new Constructor()      new instance

func.call(obj)         obj (explicitly set)

func.bind(obj)()       obj (locked in new function)

inside arrow function  outer scope's this (inherit)

inside event           element (default) or bound object
listener

inside setTimeout()    global (unless arrow)

Practice Assignment

1. Object methods:

// Create user object with:
// - name, email properties
// - greet() method (use this.name)
// - getEmail() method (use this.email)
// Test each method

2. Losing and finding this:

// Create object with method
// Extract method, call it (lose this)
// Fix using .bind()
// Verify this = object again

3. Arrow vs regular:

// Create object method that:
// - Use regular function for this = object
// - Use arrow function inside (inherit this)
// Test both work correctly

4. Event listener:

// Create button handler object
// Add click listener
// Use .bind(this) to keep context
// Verify this = object inside handler

5. Constructor pattern:

// Create User constructor function
// Add method using this.name
// Create 2 instances
// Call method on each (different this each time)

Quick Recap

• this = reference to caller. Who call function? That who this is.

• Global context = this = window (browser) or global (Node.js).

• Inside object method = this = object calling method.

• Inside function (not method) = this = global or undefined (strict).

• Caller determine this = same function, different caller, different this.

• Arrow function = inherit this from outer scope (don't create own).

• Regular function = create own this (depend on caller).

• .call(obj) = call function with this = obj (immediately).

• .apply(obj, [args]) = like call but arguments as array (immediately).

• .bind(obj) = create new function with this = obj (not immediate).

• Nested function = lose this. Use arrow function or .bind().

• Object method = use regular function (get this = object).

• Event listener = use arrow or .bind() to keep this.

• Constructor = new set this = new instance.

• Class method = this = instance automatically.

• Arrow in object = wrong. Lose this context.

• Remember = this = who calling the function.

Master this = master JavaScript.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This about understanding event loop and how it make Node.js fast.

What The Event Loop Is

Event loop = forever-running manager. Check what task ready, run it, repeat.

Simple Definition

Event loop = system that manage code execution. When one task finish, event loop grab next task. One at time, but very fast.

Real Analogy

Coffee shop barista:

Barista job = event loop

1. Customer 1 order coffee
   → Add to task queue

2. Customer 2 order coffee
   → Add to task queue

3. Customer 1 order ready
   → Grab from queue, serve customer 1

4. Customer 3 order
   → Add to task queue

5. Customer 2 order ready
   → Grab from queue, serve customer 2

Barista work one task at time.
But move very fast. Seem like doing all at once.

Event loop = barista. Task queue = order list. Node.js = coffee shop.

Single Thread Problem

Node.js run on single thread. One piece code run at time.

Normal language (blocking):
  User 1 request → Server busy (10 seconds)
                 → User 2 wait
                 → User 3 wait
                 → User 100 wait

If use blocking code, other users stuck.

Node.js (event loop):
  User 1 request → Start task, move on
  User 2 request → Start task, move on
  User 3 request → Start task, move on
  User 100 request → Start task, move on
  
  Meanwhile...
  User 1 task done → handle response
  User 2 task done → handle response
  etc.

Event loop = manage all at once without blocking.

Why Event Loop Matter

Without event loop:

// Code hang forever on slow task
fs.readFileSync('huge-file.txt');  // Block 10 seconds
// Everything wait 10 seconds

With event loop:

// Code don't wait
fs.readFile('huge-file.txt', () => {
  // Run later when file ready
});
// Continue immediately

Single Thread Limitation

Node.js only one thread. One line code run at time.

Thread = What?

Thread = worker. One thread = one worker.

Normal server:

10 threads → 10 workers → handle 10 users at once
Each user have own thread

Node.js:

1 thread → 1 worker → handle 1,000 users at once
But very smart worker (event loop)

Why Single Thread?

Advantage:

• Simple. No complicated multi-thread stuff.
• No thread collision (same variable, two threads edit = crash).
• Event loop handle many users.

Disadvantage:

• Can't do CPU-heavy work (loop 1 billion times = freeze).
• Heavy math block everything.

The Event Loop Solution

Event loop = cheat. Act like many threads but only one.

Event loop work:

Check call stack: anything running?
  Yes → Let it finish
  No → Check task queue

Task queue have jobs?
  Yes → Grab one, run it
  No → Wait

Repeat forever

User see many tasks happening. Actually one at time. But so fast, seem parallel.

Call Stack vs Task Queue

Two place where code live: call stack and task queue.

Call Stack

Call stack = where code execute right now.

function greet() {
  console.log('Hello');
}

function main() {
  greet();  // Call stack: main → greet
}

main();

Call stack during execution:

Step 1: main() call
  Stack: [main]

Step 2: main call greet()
  Stack: [main, greet]

Step 3: greet run, print "Hello"
  Stack: [main, greet]

Step 4: greet finish
  Stack: [main]

Step 5: main finish
  Stack: []

Call stack is LIFO (last in, first out). Last function added, first to finish.

Task Queue

Task queue = where async tasks wait. They not run yet.

setTimeout(() => {
  console.log('Later');
}, 1000);

console.log('Now');

Execution:

Step 1: Call setTimeout
  → Callback add to task queue (but not run yet)
  → Timer start (1 second)

Step 2: console.log('Now') run
  Print: "Now"

Step 3: 1 second pass
  → Callback in queue, ready

Step 4: Call stack empty
  → Event loop grab from task queue
  → Run callback

Step 5: Print "Later"

Call Stack vs Task Queue

CALL STACK              TASK QUEUE
═════════════════       ════════════════════
Where code run now      Where async wait

LIFO (stack)            FIFO (queue)

Run immediately         Run when stack empty

Normal function         Async callback
console.log             setTimeout
math operation          fs.readFile
                        db.query

Event Loop Execution Cycle

Event loop = forever loop. Check → run → check → run.

Step By Step

Event Loop Cycle:

1. Check call stack
   → Anything running?
      No → Go to step 2
      Yes → Wait for finish, go to step 2

2. Check task queue
   → Any callback waiting?
      Yes → Grab first callback
            Run it (add to call stack)
            Go to step 1
      No → Go to step 3

3. Check for more callbacks
   → Wait until something in queue
   → Go to step 1

Repeat forever (while Node.js alive)

Code Example: Event Loop in Action

console.log('1. Start');

setTimeout(() => {
  console.log('3. Timeout callback');
}, 0);  // Even 0ms, go to queue

console.log('2. End');

Output:

1. Start
2. End
3. Timeout callback

Why?

Step 1: console.log('1. Start') run
  Print: "1. Start"
  Call stack: [log]
  
Step 2: setTimeout call
  Callback go to task queue
  Timer (0ms) start immediately
  Call stack: empty

Step 3: console.log('2. End') run
  Print: "2. End"
  Call stack: empty

Step 4: Event loop check
  Call stack: empty
  Task queue: [callback waiting]
  
Step 5: Event loop grab callback from queue
  Run callback (print "3. Timeout callback")

Output:
1. Start
2. End
3. Timeout callback

Even setTimeout(..., 0) don't run immediately. Callback go to queue. Wait for stack empty.

Bigger Example

console.log('A');

setTimeout(() => {
  console.log('B');
}, 0);

Promise.resolve()
  .then(() => {
    console.log('C');
  });

console.log('D');

Output:

A
D
C
B

Why?

Execution:
console.log('A')        → Print "A"
setTimeout(...)         → Callback to task queue
Promise.then(...)       → Callback to microtask queue (different queue)
console.log('D')        → Print "D"

Call stack empty. Event loop check queues:

First: Microtask queue (Promise callbacks run first)
  Run callback → Print "C"

Then: Task queue (Timer callbacks run after)
  Run callback → Print "B"

Node.js have two queues actually:

• Microtask queue = Promise, async/await (run first)
• Task queue = setTimeout, setInterval (run second)

Not too deep. Just know: Promise callback run before setTimeout callback.

How Async Operations Work

Async operations use event loop. Start task, don't wait. Later callback fire.

File Read

const fs = require('fs');

console.log('1. Start');

fs.readFile('file.txt', (err, data) => {
  console.log('3. File read done');
});

console.log('2. Continue');

Output:

1. Start
2. Continue
3. File read done

Timeline:

Step 1: fs.readFile call
  → File reading start (background)
  → Callback add to task queue
  → But not run yet

Step 2: Continue immediately
  → Don't wait for file

Step 3: Call stack empty

Step 4: File reading done
  → Callback ready in queue

Step 5: Event loop run callback
  → Print "3. File read done"

Database Query

const db = require('./db');

console.log('1. Query start');

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

console.log('2. Did not wait');

Same pattern:

1. Query start (print)
2. Did not wait (print)
3. Query done: [...] (print after query finish)

Query happen background. Event loop run callback when done.

Multiple Async Operations

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

console.log('1. Start');

async function loadData() {
  const file1 = await fs.readFile('file1.txt');
  const file2 = await fs.readFile('file2.txt');
  
  console.log('3. Both files loaded');
}

loadData();

console.log('2. Continue');

Output:

1. Start
2. Continue
3. Both files loaded

Why "2" before "3"?

Step 1: loadData() call
  → First await (readFile)
  → Callback add to queue
  → Function pause (await)
  → Return immediately

Step 2: Continue (print)
  → Call stack empty

Step 3: File 1 ready
  → First await resolve
  → loadData continue
  → Second await (readFile)
  → Another callback add to queue
  → Function pause again

Step 4: File 2 ready
  → Second await resolve
  → Print "3. Both files loaded"

Each await pause function. Event loop continue other work. When callback ready, function resume.

Timers vs I/O Callbacks

Different type async operations. Different timing.

Timers: setTimeout, setInterval

setTimeout(() => {
  console.log('Timer done');
}, 1000);  // Wait 1000ms

How it work:

Event loop:

1. setTimeout call
   → Add callback to task queue
   → Timer start 1000ms

2. Event loop continue
   → Do other work

3. 1000ms pass
   → Timer ready
   → Callback can run

4. Call stack empty
   → Event loop grab callback
   → Run it

5. Print "Timer done"

Timers = time-based. Wait X milliseconds.

I/O Callbacks: File read, Database

fs.readFile('file.txt', () => {
  console.log('File done');
});

How it work:

Event loop:

1. fs.readFile call
   → File reading start (OS handle)
   → Callback add to queue (but not ready yet)

2. Event loop continue
   → Do other work

3. OS finish reading file
   → Callback marked ready
   → (Might be 10ms, might be 1 second)

4. Call stack empty
   → Event loop grab callback
   → Run it

5. Print "File done"

I/O = depends on OS. Could be slow. Could be fast. Event loop not know when.

Difference

TIMERS                      I/O
══════════════════          ════════════════════
Known wait time             Unknown wait time
Wait X milliseconds         Wait until OS done

setTimeout(...)             fs.readFile
setInterval(...)            db.query
                            http.get

Useful for delays           Useful for reading
Useful for retry            Useful for querying

Both use event loop. Both don't block. But different reason when callback fire.

Event Loop and Scalability

Event loop = why Node.js fast for many users.

The Problem: Threads

Traditional server (many threads):

100 users → 100 threads
Each thread = memory
Each thread = overhead

Total memory = high

Creates 100 threads = slow. Handle 100 users = fine. Handle 1000 users = system crash (not enough memory).

The Solution: Event Loop

Node.js (one thread, event loop):

1000 users → 1 thread + event loop
Handle first user → task go to queue
Handle second user → task go to queue
Handle third user → task go to queue
...

Event loop manage all at once.
Total memory = low
Handle 1000 users = easy
Handle 10,000 users = still working

Event loop = memory efficient.

Why Event Loop Scale Better

User come:
  Server start async operation
  User task go to queue
  Server immediately free (handle next user)

Meanwhile:
  User 1 operation running (background)
  User 2 operation running (background)
  User 3 operation running (background)
  ...

When operation done:
  Callback fire
  Server send response to user

Same 1 thread. Same code. But handle many users.

Example: Real Server Load

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

app.get('/user/:id', async (req, res) => {
  // 1. Start database query
  const user = await db.getUser(req.params.id);
  
  // 2. Query happen background (not blocking)
  
  // 3. When ready, callback fire
  
  // 4. Send response
  res.json(user);
});

app.listen(3000);

Handle 1000 requests:

Request 1 → Start DB query (background)
Request 2 → Start DB query (background)
Request 3 → Start DB query (background)
...
Request 1000 → Start DB query (background)

All queries run parallel (in background).
Server only use 1 thread.
Memory = low.
Speed = fast.

When Request 1 query done → Send response
When Request 2 query done → Send response
etc.

Without event loop:

• Request 1 query (5 seconds)
• Request 2 wait
• Request 3 wait
• ... 1000 requests wait
• Total time = 5000 seconds (impossible)

With event loop:

• All 1000 queries at same time
• Total time = ~5 seconds

That why Node.js famous for scaling.

Event Loop Problems (CPU-Heavy Code)

Event loop great for I/O. Bad for CPU-heavy code.

Problem: Long Running Code

app.get('/calculate', (req, res) => {
  // CPU heavy - loop 1 billion times
  let sum = 0;
  for (let i = 0; i < 1000000000; i++) {
    sum += i;
  }
  
  res.json({ sum });
});

What happen:

User 1 request
  → Start calculate loop
  → Block event loop (3 seconds)
  
During those 3 seconds:
  User 2 request (wait)
  User 3 request (wait)
  User 4 request (wait)
  
User 1 response send (3 seconds later)
  → Now User 2 can start
  → Now User 3 can start

CPU-heavy code = freeze event loop. Other users suffer.

Solution: Worker Threads

For heavy work, use worker threads (separate thread):

const { Worker } = require('worker_threads');

app.get('/calculate', (req, res) => {
  const worker = new Worker('./calculate.js');
  
  worker.on('message', (result) => {
    res.json({ sum: result });
  });
});

Worker thread do heavy work. Main thread (event loop) continue serve other users.

But mostly: avoid CPU-heavy code on server. Use Node.js for I/O, not math.

Event Loop in Real Code

Example 1: Simple Request

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

app.get('/hello', (req, res) => {
  console.log('Request come');
  res.json({ message: 'Hello' });
});

app.listen(3000);

Timeline:

User 1 request come
  → /hello route handler run
  → Print "Request come"
  → Send response
  → Handler finish (remove from stack)

User 2 request come
  → /hello route handler run
  → Print "Request come"
  → Send response
  → Handler finish

Event loop continue... always

Each request = separate handler. Event loop run one, then next.

Example 2: Database Request

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

app.get('/user/:id', async (req, res) => {
  console.log('1. Query start');
  
  const user = await db.query('SELECT * FROM users WHERE id = ?', [req.params.id]);
  
  console.log('2. Query done');
  res.json(user);
});

app.listen(3000);

Timeline:

User 1 request
  → Print "1. Query start"
  → await (pause here)
  → Query add to queue
  → Handler pause

User 2 request (meanwhile)
  → Print "1. Query start"
  → await (pause here)
  → Query add to queue
  → Handler pause

User 1 query done
  → Callback fire
  → Print "2. Query done"
  → Send response

User 2 query done
  → Callback fire
  → Print "2. Query done"
  → Send response

Both queries happen at same time. Event loop manage both.

Example 3: File Operations

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

async function processFiles() {
  console.log('1. Start');
  
  const files = await Promise.all([
    fs.readFile('file1.txt'),
    fs.readFile('file2.txt'),
    fs.readFile('file3.txt')
  ]);
  
  console.log('2. All done');
}

processFiles();
console.log('3. Continue');

Output:

1. Start
3. Continue
2. All done

Timeline:

processFiles() call
  → Print "1. Start"
  → Promise.all start all 3 reads
  → await (pause function)

Print "3. Continue"
  → Main code continue

File reads happen background:
  OS read file 1
  OS read file 2
  OS read file 3

All 3 files done
  → Promise.all resolve
  → Function resume
  → Print "2. All done"

One thread. Three file reads at same time. Event loop magic.

Event Loop Visualization

Step-by-Step Flow

START
  │
  ├─→ Check Call Stack
  │   │
  │   ├─ Something running?
  │   │  Yes → Wait for finish
  │   │  No → Go to next
  │   │
  │
  ├─→ Check Microtask Queue (Promise)
  │   │
  │   ├─ Anything waiting?
  │   │  Yes → Run it, go back to stack check
  │   │  No → Go to next
  │   │
  │
  ├─→ Check Task Queue (setTimeout, I/O)
  │   │
  │   ├─ Anything waiting?
  │   │  Yes → Run it, go back to stack check
  │   │  No → Sleep until something arrive
  │   │
  │
  └─→ Loop again (forever)

Code Execution Order

// What print first?

console.log('A');                    // Call stack run

setTimeout(() => {
  console.log('B');                  // Task queue (timer)
}, 0);

Promise.resolve().then(() => {
  console.log('C');                  // Microtask queue (Promise)
});

console.log('D');                    // Call stack run

Order:

1. A, D (Call stack, synchronous code)
2. C    (Microtask queue, Promises)
3. B    (Task queue, Timers)

Output:
A
D
C
B

Event loop priority:

1. Synchronous code (call stack)
2. Promises/async (microtask queue)
3. Timers/I/O (task queue)

Common Event Loop Mistakes

Mistake 1: Think Await Block Other Users

// ✗ Think this block other users
app.get('/user/:id', async (req, res) => {
  const user = await db.getUser(id);  // Blocking?
  res.json(user);
});

// ✓ Reality: don't block others
// await pause THIS function
// But event loop continue handle OTHER users

Each user have own context. Await pause one context, not all.

Mistake 2: Forget Event Loop on CPU Work

// ✗ Block event loop (bad for other users)
for (let i = 0; i < 1000000000; i++) {
  sum += i;  // CPU heavy
}

// ✓ Use worker thread or break into chunks
const chunk = async () => {
  sum += i;
  // resume later
};

CPU work can't use async. Must use worker threads or split work.

Mistake 3: Assume setTimeout(0) = Immediate

// ✗ Think callback run immediately
setTimeout(() => {
  console.log('Immediate?');
}, 0);

// ✓ Reality: callback wait in queue
// Go to task queue
// Run when stack empty
// NOT immediately

Even 0ms don't mean immediately. Go to queue. Might wait milliseconds.

Mistake 4: Not Understand Microtask Queue

// ✗ Think Promise and setTimeout same
console.log('A');

setTimeout(() => console.log('B'), 0);
Promise.resolve().then(() => console.log('C'));

console.log('D');

// ✗ Expect: A, B, C, D
// ✓ Real: A, D, C, B

Promise use microtask queue (run first). setTimeout use task queue (run second).

Different queues = different timing.

Practice Assignment

1. Event loop order:

// Predict output order
console.log('1');

setTimeout(() => console.log('2'), 0);

Promise.resolve()
  .then(() => console.log('3'))
  .then(() => console.log('4'));

console.log('5');

// What order? Why?
// Test and verify

2. Async operations:

// Write function that:
// - Read 3 files
// - Do all 3 at same time (parallel)
// - Print results when all done
// Use Promise.all or async/await

3. Understand blocking:

// Create two endpoints:
// - One with CPU loop (block)
// - One without block

// Test: which handle user faster?
// Monitor: does one slow down other?

4. Event loop trace:

// Trace execution step by step

app.get('/test', async (req, res) => {
  console.log('A');
  
  const file = await fs.readFile('file.txt');
  
  console.log('B');
  res.json(file);
});

// When do A and B print?
// What if 3 users request at same time?

5. Fix scalability:

// Given slow endpoint
// Rewrite to use event loop better
// Should handle 1000 users, not 10

// Before: server crash with 1000 users
// After: server handle 1000 users easy

Quick Recap

• Event loop = manager. Check what ready, run it, repeat.

• Single thread = one code run at time. But event loop make seem parallel.

• Call stack = where code run now. LIFO order.

• Task queue = where async callback wait. FIFO order.

• Event loop cycle: Check stack → Check queue → Run task → Repeat.

• Async operations = start, don't wait. Callback fire later.

• Microtask queue = Promise callbacks. Run before task queue.

• Task queue = setTimeout, I/O callbacks. Run after microtask.

• Timers = time-based. Wait X milliseconds.

• I/O callbacks = depends on OS. When file/DB ready.

• Scalability = event loop handle many users with 1 thread.

• No threads needed = event loop do work of many threads.

• Memory efficient = 1 thread vs 100 threads.

• CPU-heavy code = freeze event loop. Use worker threads.

• Await pause function = not block event loop. Other users continue.

• setTimeout(0) != immediate = go to task queue. Wait until stack empty.

• Promise run first = microtask queue before task queue.

• Without event loop = Node.js can't scale. Dead project.

• With event loop = 1000 users, 1 thread. That magic.

Event loop = why Node.js exist. Without it, just another server language.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This about blocking, non-blocking, and async patterns in Node.js.

What Blocking Code Means

Blocking = waiting. Code wait for operation finish before continue.

Simple Definition

Blocking code pause execution until task complete. Nothing else happen. Like stuck in line at store.

Real Analogy

Restaurant waiter without non-blocking:

Waiter take order from customer 1.
Wait for kitchen finish cooking.
[Stand there 10 minutes doing nothing]
[Customer 2 wait, customer 3 wait, customer 4 wait]
Finally food ready.
Waiter bring food to customer 1.
NOW waiter take order from customer 2.

Bad service. Customers angry. Waiter waste time.

The Problem

// Blocking code
const fs = require('fs');

console.log('Start reading file');
const data = fs.readFileSync('large-file.txt');  // BLOCK HERE
console.log('File read complete');
console.log(data);

What happen:

1. Server start
2. Start reading file [WAIT]
3. [WAIT] [WAIT] [WAIT]   <- Nothing happen for 5 seconds
4. File finally loaded
5. Print data
6. During step 3, if 100 users try access server, ALL wait

Why Blocking Kill Servers

One user read file = 5 seconds. 10 users read file = 50 seconds wait for user 10. 100 users? Server dead.

What Non-Blocking Code Means

Non-blocking = don't wait. Code start task, move on. When task done, callback fire.

Simple Definition

Non-blocking code start operation and continue. Task happen background. When done, callback tell code.

Real Analogy

Restaurant waiter WITH non-blocking:

Waiter take order from customer 1.
Send order to kitchen.
[Keep going - don't wait]
Waiter take order from customer 2.
Waiter take order from customer 3.
Kitchen finish customer 1 food.
Waiter bring food.
[Meanwhile take order from customer 4]
Kitchen finish customer 2 food.
Waiter bring food.

Good service. Customers happy. Waiter busy but move fast.

Code Example

// Non-blocking code
const fs = require('fs');

console.log('Start reading file');

fs.readFile('large-file.txt', (err, data) => {
  // This callback run LATER when file ready
  console.log('File read complete');
  console.log(data);
});

console.log('Request sent, moving on');

What happen:

1. Server start
2. Start reading file (DON'T WAIT)
3. Move to next line immediately
4. "Request sent, moving on" print
5. File load in background
6. When ready, callback fire
7. Print data

During file read, server handle other users.

Why Blocking Slow Servers Down

Timeline Comparison

Blocking (synchronous):

Time (seconds)
0s   ├─ User 1 come
     ├─ Read file [BLOCK]
5s   ├─ File done
     ├─ User 2 come [wait in line]
     ├─ Read file [BLOCK]
10s  ├─ File done
     ├─ User 3 come [wait in line]
     ├─ Read file [BLOCK]
15s  └─ File done

Total time for 3 users = 15 seconds

Non-blocking (asynchronous):

Time (seconds)
0s   ├─ User 1 come
     ├─ Start read file (don't wait)
0s   ├─ User 2 come
     ├─ Start read file (don't wait)
0s   ├─ User 3 come
     ├─ Start read file (don't wait)
5s   └─ All 3 files ready, return data to users

Total time for 3 users = 5 seconds

Real Impact

With blocking:

• 100 users = 500 seconds (8+ minutes)
• Server crash or hang

With non-blocking:

• 100 users = 5 seconds
• Server smooth

Code Proof

// BLOCKING - slow
const fs = require('fs');
console.time('Blocking');

for (let i = 0; i < 3; i++) {
  const data = fs.readFileSync('file.txt');  // Wait each time
  console.log(`Read ${i}`);
}

console.timeEnd('Blocking');
// Blocking: 3000ms (each file take ~1 second)

// NON-BLOCKING - fast
const fs = require('fs');
console.time('NonBlocking');

for (let i = 0; i < 3; i++) {
  fs.readFile('file.txt', (err, data) => {
    console.log(`Read ${i}`);
  });
}

console.timeEnd('NonBlocking');
// NonBlocking: 10ms (all start at once)

Async Operations in Node.js

Node.js have many built-in async functions. Don't use Sync version in production.

File Operations

Blocking (bad):

const fs = require('fs');

const data = fs.readFileSync('users.json');  // DON'T DO THIS
console.log(data);

Non-blocking (good):

const fs = require('fs');

fs.readFile('users.json', (err, data) => {
  if (err) {
    console.error('File error:', err);
    return;
  }
  console.log(data);
});

Database Calls

Blocking (bad):

// Fake sync DB call (most real DB have this)
const user = db.getUserSync(1);  // Block waiting for DB
console.log(user);

Non-blocking (good):

// Real async DB call
db.getUser(1, (err, user) => {
  if (err) {
    console.error('DB error:', err);
    return;
  }
  console.log(user);
});

Network Requests

Blocking (impossible, no sync version):

// This don't exist - network always async
const response = http.requestSync(url);  // Doesn't exist

Non-blocking (only way):

const http = require('http');

http.get(url, (res) => {
  let data = '';
  res.on('data', (chunk) => {
    data += chunk;
  });
  res.on('end', () => {
    console.log(data);
  });
});

Callbacks: Simple Non-Blocking Pattern

Callback = function that run later.

What is Callback?

Callback = tell Node.js "When done, run this function".

fs.readFile('file.txt', (err, data) => {
  // This function run LATER when file ready
  console.log(data);
});

Function (err, data) => { ... } = callback.

Callback Pattern

function readUserFile(callback) {
  fs.readFile('user.json', (err, data) => {
    if (err) {
      callback(err);  // Pass error to callback
      return;
    }
    callback(null, data);  // Pass data to callback
  });
}

// Use it
readUserFile((err, data) => {
  if (err) {
    console.error('Error:', err);
  } else {
    console.log('User:', data);
  }
});

Callback Hell (Problem)

Nested callbacks get messy:

fs.readFile('users.json', (err, users) => {
  if (err) console.error(err);
  
  fs.readFile('posts.json', (err, posts) => {
    if (err) console.error(err);
    
    fs.readFile('comments.json', (err, comments) => {
      if (err) console.error(err);
      
      console.log(users, posts, comments);
      // Deep nesting = hard to read
    });
  });
});

Solution = use Promises or async/await.

Promises: Better Non-Blocking Pattern

Promise = cleaner callback. Chain operations.

What is Promise?

Promise = object that represent future value.

const promise = fs.promises.readFile('file.txt');

promise
  .then((data) => {
    console.log('File read:', data);
  })
  .catch((err) => {
    console.error('Error:', err);
  });

Promise Chain

No nesting needed:

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

fs.readFile('users.json')
  .then((users) => {
    console.log('Users loaded');
    return fs.readFile('posts.json');  // Chain next operation
  })
  .then((posts) => {
    console.log('Posts loaded');
    return fs.readFile('comments.json');
  })
  .then((comments) => {
    console.log('Comments loaded');
    console.log('All data ready');
  })
  .catch((err) => {
    console.error('Error:', err);
  });

Clean. Easy read.

Promise Syntax

new Promise((resolve, reject) => {
  // Do async work
  if (success) {
    resolve(data);  // Pass data when done
  } else {
    reject(error);  // Pass error if fail
  }
});

Example:

function readFile(filename) {
  return new Promise((resolve, reject) => {
    fs.readFile(filename, (err, data) => {
      if (err) {
        reject(err);
      } else {
        resolve(data);
      }
    });
  });
}

readFile('users.json')
  .then((data) => console.log(data))
  .catch((err) => console.error(err));

Async/Await: Cleanest Non-Blocking Pattern

Async/await = write async code like sync code.

What is Async/Await?

Async/await = Promises but easier read. Look like normal code.

async function loadData() {
  try {
    const users = await fs.promises.readFile('users.json');
    console.log('Users:', users);
    
    const posts = await fs.promises.readFile('posts.json');
    console.log('Posts:', posts);
    
  } catch (err) {
    console.error('Error:', err);
  }
}

loadData();

No .then() chains. Clean.

Async Function

async keyword make function return Promise:

async function getData() {
  return 'some data';  // Auto wrapped in Promise
}

getData().then((data) => console.log(data));  // Work with Promise

Await Keyword

await pause function until Promise resolve:

async function loadFile() {
  console.log('Start');
  
  const data = await fs.promises.readFile('file.txt');
  // Wait here until file ready
  // Then continue
  
  console.log('Done');
  console.log(data);
}

loadFile();

Timeline:

1. Start (print)
2. Begin reading file
3. PAUSE (await wait)
4. File ready
5. Resume
6. Done (print)
7. Print data

Real Example: Async/Await

const express = require('express');
const fs = require('fs').promises;
const app = express();

app.get('/users/:id', async (req, res) => {
  try {
    const userId = req.params.id;
    
    // Read user file
    const userFile = await fs.readFile(`users/${userId}.json`);
    const user = JSON.parse(userFile);
    
    // Read user posts
    const postsFile = await fs.readFile(`posts/${userId}.json`);
    const posts = JSON.parse(postsFile);
    
    // Return both
    res.json({ user, posts });
    
  } catch (err) {
    res.status(500).json({ error: 'Server error' });
  }
});

app.listen(3000);

During await, server handle other users. Not blocked.

Blocking vs Non-Blocking: Side-by-Side

File Read Comparison

Blocking:

const fs = require('fs');

function readUser() {
  // This freeze whole server
  const data = fs.readFileSync('user.json');
  return data;
}

const user = readUser();
console.log(user);

Non-blocking (Promise):

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

function readUser() {
  // Return Promise
  return fs.readFile('user.json');
}

readUser()
  .then((data) => console.log(data))
  .catch((err) => console.error(err));

Non-blocking (Async/Await):

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

async function readUser() {
  try {
    const data = await fs.readFile('user.json');
    return data;
  } catch (err) {
    console.error(err);
  }
}

const user = await readUser();
console.log(user);

Database Call Comparison

Blocking (bad):

const user = db.getUserSync(1);  // Server freeze
res.json(user);

Non-blocking (good):

db.getUser(1, (err, user) => {
  if (err) return res.status(500).json({ error: err });
  res.json(user);  // Server not frozen
});

Non-blocking (async/await, best):

async function handleRequest(req, res) {
  try {
    const user = await db.getUser(1);
    res.json(user);
  } catch (err) {
    res.status(500).json({ error: err });
  }
}

Real-World Examples

Example 1: Read File and Database

Wrong (blocking):

const fs = require('fs');
const db = require('./db');

app.get('/profile/:id', (req, res) => {
  // Freeze server here
  const settings = fs.readFileSync('config.json');
  const user = db.getUserSync(req.params.id);
  
  res.json({ user, settings });
});

Timeline for 3 users:

User 1: File read (2s) → DB query (3s) = 5s total
User 2: Wait... wait... wait... (5s)
User 3: Wait... wait... wait... (10s)

Right (non-blocking):

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

app.get('/profile/:id', async (req, res) => {
  try {
    // Both start at same time (parallel)
    const [settings, user] = await Promise.all([
      fs.readFile('config.json'),
      db.getUser(req.params.id)
    ]);
    
    res.json({ user, settings });
  } catch (err) {
    res.status(500).json({ error: err });
  }
});

Timeline for 3 users:

User 1: Start both → Wait 3s → Done
User 2: Start both → Wait 3s → Done
User 3: Start both → Wait 3s → Done
Total: All 3 done in 3 seconds (not 15)

Example 2: Loop with Non-Blocking

Wrong (blocking):

const fs = require('fs');

function processFiles(filenames) {
  const results = [];
  
  for (const filename of filenames) {
    // Read each file one by one (SLOW)
    const data = fs.readFileSync(filename);
    results.push(data);
  }
  
  return results;
}

processFiles(['file1.txt', 'file2.txt', 'file3.txt']);
// Take 3 seconds (1s each)

Right (non-blocking, parallel):

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

async function processFiles(filenames) {
  // Read all files at same time
  const promises = filenames.map(filename => 
    fs.readFile(filename)
  );
  
  const results = await Promise.all(promises);
  return results;
}

await processFiles(['file1.txt', 'file2.txt', 'file3.txt']);
// Take 1 second (all run together)

Example 3: API Call with Non-Blocking

Wrong (blocking - would hang server):

// Blocking network call (doesn't exist in Node.js)
const data = http.requestSync(url);  // NO
res.json(data);

Right (non-blocking):

const axios = require('axios');

app.get('/data', async (req, res) => {
  try {
    // Don't block - wait for response
    const response = await axios.get('https://api.example.com/data');
    res.json(response.data);
  } catch (err) {
    res.status(500).json({ error: err });
  }
});

Server handle 100 users at once. Each await not block others.

Common Mistakes

Mistake 1: Using Sync Methods in Production

// ✗ Bad - freeze server
const data = fs.readFileSync('file.txt');

// ✓ Good - don't freeze
const data = await fs.promises.readFile('file.txt');

Mistake 2: Forgetting Error Handling

// ✗ Bad - error crash app
async function loadData() {
  const data = await fs.readFile('file.txt');
  console.log(data);
}

// ✓ Good - handle error
async function loadData() {
  try {
    const data = await fs.readFile('file.txt');
    console.log(data);
  } catch (err) {
    console.error('Error:', err);
  }
}

Mistake 3: Sequential When Could Be Parallel

// ✗ Bad - run one at time (3 seconds)
async function getData() {
  const users = await db.getUsers();
  const posts = await db.getPosts();
  const comments = await db.getComments();
  return { users, posts, comments };
}

// ✓ Good - run all together (1 second)
async function getData() {
  return Promise.all([
    db.getUsers(),
    db.getPosts(),
    db.getComments()
  ]);
}

Mistake 4: Callback Hell (Before Understanding Promises)

// ✗ Bad - nested and hard read
fs.readFile('file1.txt', (err, data1) => {
  fs.readFile('file2.txt', (err, data2) => {
    fs.readFile('file3.txt', (err, data3) => {
      console.log(data1, data2, data3);
    });
  });
});

// ✓ Good - use Promise.all
async function readFiles() {
  const [data1, data2, data3] = await Promise.all([
    fs.promises.readFile('file1.txt'),
    fs.promises.readFile('file2.txt'),
    fs.promises.readFile('file3.txt')
  ]);
  console.log(data1, data2, data3);
}

When to Block (Rare)

Generally: don't block.

But rare cases:

1. Server startup - Load config before start
2. CLI tools - Command line tool need blocking read
3. One-time script - Not long-running server

// OK to block on startup
const config = fs.readFileSync('config.json');

const app = express();
app.use(/* setup */);

// NOW use async everywhere
app.get('/data', async (req, res) => {
  const data = await getData();
  res.json(data);
});

app.listen(3000);

Practice Assignment

1. Fix blocking code:

// Given blocking code, rewrite with async/await
const fs = require('fs');

function loadData() {
  const users = fs.readFileSync('users.json');
  const posts = fs.readFileSync('posts.json');
  return { users, posts };
}

// Rewrite to non-blocking

2. Build async API endpoint:

// Create Express endpoint that:
// - Read user file from disk
// - Query database for user data
// - Return combined response
// Use async/await

3. Parallel operations:

// Write function that read 5 files
// Do NOT read one by one
// Read all at same time using Promise.all

4. Error handling:

// Add proper try/catch
// Handle file read errors
// Handle database errors
// Return error responses

5. Performance test:

// Create two versions:
// - Blocking (sequential read)
// - Non-blocking (parallel read)
// Test speed difference
// Measure time

Quick Recap

• Blocking code = wait for operation. Nothing else happen.

• Non-blocking code = start operation, move on. Callback when done.

• Blocking freeze server. All users wait.

• Non-blocking allow server handle many users.

• Sync methods = readFileSync, querySync. Avoid in production.

• Async methods = readFile, query. Use these.

• Callbacks = function run later. Basic async pattern.

• Promises = cleaner callbacks. Chain operations.

• Async/await = easiest pattern. Look like normal code.

• async function = return Promise automatically.

• await keyword = pause until Promise done.

• try/catch = handle errors in async code.

• Promise.all = run multiple async at once (parallel).

• Sequential = one after another (slow).

• Parallel = all together (fast).

• 3 users, 5 seconds each = blocking need 15 seconds total.

• 3 users, 5 seconds each = non-blocking do 5 seconds total.

• Most operations are I/O: files, database, network. Use async.

• Block only on startup, not during request handling.

Non-blocking code = fast servers. Fast servers = happy users.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding REST principles and building proper APIs with Express.

What REST API Means

REST stands for Representational State Transfer. It's a set of rules for building APIs.

Simple Definition

REST is a standard way to structure requests and responses between client and server using HTTP methods and resource URLs.

The Communication Problem

Without REST, APIs are chaotic:

GET /getUser?id=1
POST /fetchUserData
PUT /updateUserInfo
DELETE /removeUser?userId=1
GET /getAllUsers

Different names for similar operations. Confusing.

With REST, APIs are predictable:

GET /users/1        (get user)
POST /users         (create user)
PUT /users/1        (update user)
DELETE /users/1     (delete user)
GET /users          (get all users)

Same resource, different methods. Crystal clear.

Real Analogy

Think of a restaurant's menu (API):

Without REST:

bringSoup
bringBread
removePlate
giveBill
bringsalad

Confusing. No pattern.

With REST:

Action: BRING, Resource: SOUP
Action: BRING, Resource: BREAD
Action: REMOVE, Resource: PLATE
Action: GIVE, Resource: BILL

Clear pattern. Easy to understand.

Why REST Matters

REST makes APIs:

• Predictable (you can guess the URL)
• Consistent (same patterns everywhere)
• Easy to document
• Easy for clients to use
• Standard across the web

Resources in REST Architecture

Resources are the things your API manages.

What is a Resource?

A resource is anything your API handles: users, posts, comments, products, orders.

Resource URLs

Resources are accessed via URLs:

/users          (users resource)
/posts          (posts resource)
/comments       (comments resource)
/products       (products resource)

Specific Resources

Access specific resources with IDs:

/users/1        (user with ID 1)
/posts/42       (post with ID 42)
/comments/100   (comment with ID 100)

Nested Resources

Related resources can be nested:

/users/1/posts           (posts by user 1)
/posts/42/comments       (comments on post 42)
/users/1/posts/5/comments (comments on post 5 by user 1)

Resource Collections vs Specific Resources

/users          (collection: all users)
/users/1        (specific: user with ID 1)

/posts          (collection: all posts)
/posts/42       (specific: post with ID 42)

Naming Conventions

Use plural nouns for resources:

✓ /users        (correct)
✗ /user         (incorrect)

✓ /posts        (correct)
✗ /post         (incorrect)

✓ /comments     (correct)
✗ /comment      (incorrect)

Use lowercase and hyphens for multi-word resources:

✓ /user-profiles
✓ /blog-posts
✓ /shopping-carts

✗ /userProfiles (camelCase)
✗ /BlogPosts    (PascalCase)

HTTP Methods: GET, POST, PUT, DELETE

HTTP methods tell the server what action to perform on a resource.

GET: Retrieve Data

GET retrieves existing data. Safe and doesn't change anything.

GET /users           → Get all users
GET /users/1         → Get user with ID 1
GET /users/1/posts   → Get posts by user 1

Code Example: GET

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

// Get all users
app.get("/users", (req, res) => {
  const users = [
    { id: 1, name: "Alice" },
    { id: 2, name: "Bob" }
  ];
  res.json(users);
});

// Get specific user
app.get("/users/:id", (req, res) => {
  const userId = req.params.id;
  const user = { id: userId, name: "Alice" };
  res.json(user);
});

POST: Create Data

POST creates new resources.

POST /users              → Create new user
POST /posts              → Create new post
POST /users/1/posts      → Create post for user 1

The request body contains the data to create.

Code Example: POST

app.use(express.json());

// Create new user
app.post("/users", (req, res) => {
  const newUser = {
    id: 3,
    name: req.body.name,
    email: req.body.email
  };
  
  res.status(201).json(newUser);
});

Test with curl:

curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Charlie","email":"charlie@example.com"}'

PUT: Update Data

PUT updates entire resources.

PUT /users/1        → Update user 1
PUT /posts/42       → Update post 42

The request body contains the updated data.

Code Example: PUT

// Update entire user
app.put("/users/:id", (req, res) => {
  const userId = req.params.id;
  const updatedUser = {
    id: userId,
    name: req.body.name,
    email: req.body.email,
    age: req.body.age
  };
  
  res.json(updatedUser);
});

Test with curl:

curl -X PUT http://localhost:3000/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice Updated","email":"alice.new@example.com","age":26}'

PATCH: Partial Update

PATCH updates specific fields (not full replacement).

PATCH /users/1      → Update some fields of user 1

Code Example: PATCH

// Update specific fields
app.patch("/users/:id", (req, res) => {
  const userId = req.params.id;
  
  // Only update provided fields
  const updates = {
    id: userId,
    name: req.body.name || "Alice",  // Keep existing if not provided
    email: req.body.email || "alice@example.com"
  };
  
  res.json(updates);
});

DELETE: Remove Data

DELETE removes resources.

DELETE /users/1     → Delete user 1
DELETE /posts/42    → Delete post 42

Code Example: DELETE

// Delete user
app.delete("/users/:id", (req, res) => {
  const userId = req.params.id;
  
  res.json({ message: `User ${userId} deleted` });
});

Test with curl:

curl -X DELETE http://localhost:3000/users/1

CRUD vs HTTP Methods

CRUD Operation    HTTP Method    Example
─────────────────────────────────────────────
Create            POST           POST /users
Read              GET            GET /users/1
Update            PUT/PATCH      PUT /users/1
Delete            DELETE         DELETE /users/1

Status Codes Basics

Status codes tell the client if the request succeeded or failed.

2xx: Success

Request was successful.

200 OK              - Request succeeded
201 Created         - Resource created
204 No Content      - Success, no data to return

4xx: Client Error

Something wrong with the request.

400 Bad Request     - Invalid request data
401 Unauthorized    - Not authenticated
403 Forbidden       - Authenticated but not allowed
404 Not Found       - Resource doesn't exist

5xx: Server Error

Something wrong on the server.

500 Internal Server Error - Server error
503 Service Unavailable   - Server down

Using Status Codes

app.post("/users", (req, res) => {
  if (!req.body.email) {
    return res.status(400).json({ error: "Email required" });
  }
  
  const newUser = { id: 1, name: req.body.name };
  res.status(201).json(newUser);  // 201 Created
});

app.get("/users/:id", (req, res) => {
  const user = findUser(req.params.id);
  
  if (!user) {
    return res.status(404).json({ error: "User not found" });
  }
  
  res.status(200).json(user);  // 200 OK
});

Common Status Codes

GET request         → 200 OK
POST success        → 201 Created
No content to show  → 204 No Content
Invalid request     → 400 Bad Request
Not authenticated   → 401 Unauthorized
Resource not found  → 404 Not Found
Server error        → 500 Internal Server Error

Designing Routes Using REST Principles

Users Resource Example

GET /users                  → Get all users
GET /users/1                → Get user 1
POST /users                 → Create new user
PUT /users/1                → Update user 1
PATCH /users/1              → Partially update user 1
DELETE /users/1             → Delete user 1

Posts Resource Example

GET /posts                  → Get all posts
GET /posts/42               → Get post 42
POST /posts                 → Create new post
PUT /posts/42               → Update post 42
DELETE /posts/42            → Delete post 42

Nested Resources

User's posts:

GET /users/1/posts          → Get posts by user 1
POST /users/1/posts         → Create post for user 1
GET /users/1/posts/5        → Get post 5 by user 1
DELETE /users/1/posts/5     → Delete post 5 by user 1

Complete API Structure

Users
├─ GET /users               (list all)
├─ POST /users              (create)
├─ GET /users/1             (get one)
├─ PUT /users/1             (update)
└─ DELETE /users/1          (delete)

Posts
├─ GET /posts               (list all)
├─ POST /posts              (create)
├─ GET /posts/1             (get one)
├─ PUT /posts/1             (update)
└─ DELETE /posts/1          (delete)

User's Posts
├─ GET /users/1/posts       (user's posts)
└─ POST /users/1/posts      (user creates post)

REST Request-Response Lifecycle

Client sends request
├─ Method: POST
├─ URL: /users
└─ Body: { name: "Alice", email: "alice@example.com" }
      |
      v
Server receives request
      |
      v
Server validates data
├─ Valid? → Continue
└─ Invalid? → Return 400 error
      |
      v
Server creates resource
├─ Success? → Continue
└─ Error? → Return 500 error
      |
      v
Server sends response
├─ Status: 201 Created
└─ Body: { id: 1, name: "Alice", email: "alice@example.com" }
      |
      v
Client receives response
      |
      v
Client displays data or error

Example Resource: Users

Building a complete users API.

Simple Users API

const express = require("express");
const app = express();
app.use(express.json());

// In-memory database
let users = [
  { id: 1, name: "Alice", email: "alice@example.com" },
  { id: 2, name: "Bob", email: "bob@example.com" }
];

let nextId = 3;

// GET all users
app.get("/users", (req, res) => {
  res.json(users);
});

// GET specific user
app.get("/users/:id", (req, res) => {
  const user = users.find(u => u.id === parseInt(req.params.id));
  
  if (!user) {
    return res.status(404).json({ error: "User not found" });
  }
  
  res.json(user);
});

// POST create user
app.post("/users", (req, res) => {
  // Validate
  if (!req.body.name || !req.body.email) {
    return res.status(400).json({ error: "Name and email required" });
  }
  
  // Create
  const newUser = {
    id: nextId++,
    name: req.body.name,
    email: req.body.email
  };
  
  users.push(newUser);
  
  // Return 201 Created
  res.status(201).json(newUser);
});

// PUT update user
app.put("/users/:id", (req, res) => {
  const user = users.find(u => u.id === parseInt(req.params.id));
  
  if (!user) {
    return res.status(404).json({ error: "User not found" });
  }
  
  // Validate
  if (!req.body.name || !req.body.email) {
    return res.status(400).json({ error: "Name and email required" });
  }
  
  // Update
  user.name = req.body.name;
  user.email = req.body.email;
  
  res.json(user);
});

// PATCH partial update
app.patch("/users/:id", (req, res) => {
  const user = users.find(u => u.id === parseInt(req.params.id));
  
  if (!user) {
    return res.status(404).json({ error: "User not found" });
  }
  
  // Update only provided fields
  if (req.body.name) user.name = req.body.name;
  if (req.body.email) user.email = req.body.email;
  
  res.json(user);
});

// DELETE user
app.delete("/users/:id", (req, res) => {
  const index = users.findIndex(u => u.id === parseInt(req.params.id));
  
  if (index === -1) {
    return res.status(404).json({ error: "User not found" });
  }
  
  const deletedUser = users.splice(index, 1);
  res.json({ message: "User deleted", user: deletedUser[0] });
});

app.listen(3000, () => {
  console.log("API running on http://localhost:3000");
});

Testing the API

Get all users:

curl http://localhost:3000/users
# [{"id":1,"name":"Alice","email":"alice@example.com"},{"id":2,"name":"Bob","email":"bob@example.com"}]

Get one user:

curl http://localhost:3000/users/1
# {"id":1,"name":"Alice","email":"alice@example.com"}

Create user:

curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Charlie","email":"charlie@example.com"}'
# {"id":3,"name":"Charlie","email":"charlie@example.com"}

Update user:

curl -X PUT http://localhost:3000/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice Updated","email":"alice.new@example.com"}'
# {"id":1,"name":"Alice Updated","email":"alice.new@example.com"}

Partial update:

curl -X PATCH http://localhost:3000/users/1 \
  -H "Content-Type: application/json" \
  -d '{"email":"newemail@example.com"}'
# {"id":1,"name":"Alice Updated","email":"newemail@example.com"}

Delete user:

curl -X DELETE http://localhost:3000/users/1
# {"message":"User deleted","user":{"id":1,"name":"Alice Updated","email":"newemail@example.com"}}

API Request-Response Examples

GET Request

Request:
────────
GET /users/1 HTTP/1.1
Host: localhost:3000

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

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com"
}

POST Request

Request:
────────
POST /users HTTP/1.1
Host: localhost:3000
Content-Type: application/json

{
  "name": "Charlie",
  "email": "charlie@example.com"
}

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

{
  "id": 3,
  "name": "Charlie",
  "email": "charlie@example.com"
}

Error Response

Request:
────────
GET /users/999 HTTP/1.1
Host: localhost:3000

Response:
─────────
HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "User not found"
}

Best Practices for REST APIs

Use Correct HTTP Methods

// ✓ Correct
GET /users          (retrieve)
POST /users         (create)
PUT /users/1        (update)
DELETE /users/1     (delete)

// ✗ Wrong
GET /deleteUser?id=1     (wrong method)
POST /getUsers           (should be GET)
GET /updateUser?id=1     (wrong method)

Use Correct Status Codes

// ✓ Correct
app.post("/users", (req, res) => {
  res.status(201).json(newUser);  // 201 for create
});

app.get("/users/:id", (req, res) => {
  if (!user) {
    return res.status(404).json({ error: "Not found" });  // 404 for missing
  }
  res.json(user);  // 200 for success
});

// ✗ Wrong
app.post("/users", (req, res) => {
  res.json(newUser);  // No status (defaults to 200, should be 201)
});

Use Plural Nouns for Resources

// ✓ Correct
GET /users
POST /posts
DELETE /comments/1

// ✗ Wrong
GET /user
POST /post
DELETE /comment/1

Use Logical Nesting

// ✓ Correct (related resources)
GET /users/1/posts      (user's posts)

// ✗ Wrong (too deeply nested)
GET /users/1/posts/2/comments/3/author/replies

Validate Input

app.post("/users", (req, res) => {
  // ✓ Validate
  if (!req.body.name || !req.body.email) {
    return res.status(400).json({ error: "Invalid data" });
  }
  
  // Process...
});

Practice Assignment

1. Plan a products API:

// Design routes for products resource
// GET /products
// GET /products/:id
// POST /products
// PUT /products/:id
// DELETE /products/:id
// Write route signatures

2. Build simple users API:

// Create Express server
// Implement all CRUD operations for users
// Test each endpoint with curl
// Return correct status codes

3. Add validation:

// Add input validation to POST /users
// Check required fields
// Return 400 for invalid data
// Test with valid and invalid requests

4. Nested resources:

// Create users and posts resources
// Implement GET /users/:id/posts
// Get all posts for a specific user
// Test the nested route

5. Error handling:

// Add proper error handling
// Return 404 for missing resources
// Return 400 for bad requests
// Return 500 for server errors
// Test error scenarios

Quick Recap

• REST is a standard for building predictable, consistent APIs.

• Resources are things your API manages: users, posts, products.

• HTTP methods tell the server what action to perform: GET, POST, PUT, DELETE.

• GET retrieves data without changing anything.

• POST creates new resources.

• PUT updates entire resources.

• PATCH updates specific fields.

• DELETE removes resources.

• Status codes tell the client if the request succeeded or failed.

• 2xx codes indicate success (200 OK, 201 Created).

• 4xx codes indicate client errors (400 Bad Request, 404 Not Found).

• 5xx codes indicate server errors (500 Internal Server Error).

• Use plural nouns for resource names: /users, not /user.

• Use lowercase and hyphens for multi-word resources: /user-profiles.

• Collection endpoints return all resources: GET /users.

• Specific endpoints use IDs: GET /users/1.

• Nested resources show relationships: GET /users/1/posts.

• Request validation prevents bad data from being saved.

• Proper status codes help clients understand what happened.

• Consistent naming makes APIs predictable and easy to use.

• REST design makes APIs intuitive even for new users.

REST APIs are the standard for building modern web services.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding Map and Set and knowing when to use them.

What is Map?

Map is a data structure for storing key-value pairs. Like an object, but better.

Simple Definition

A Map is a collection of paired data: each key has a value.

// Empty Map
const map = new Map();

// Add key-value pairs
map.set("name", "Alice");
map.set("age", 25);
map.set("email", "alice@example.com");

// Get values
console.log(map.get("name"));   // "Alice"
console.log(map.get("age"));    // 25
console.log(map.get("email"));  // "alice@example.com"

Creating a Map

// Empty Map
const emptyMap = new Map();

// Map from array of pairs
const mapFromArray = new Map([
  ["name", "Alice"],
  ["age", 25],
  ["city", "NYC"]
]);

// Map from another Map
const copyMap = new Map(mapFromArray);

Basic Map Methods

const map = new Map();

// Add
map.set("key1", "value1");
map.set("key2", "value2");

// Get
console.log(map.get("key1"));  // "value1"

// Check if exists
console.log(map.has("key1"));  // true
console.log(map.has("key3"));  // false

// Delete
map.delete("key1");
console.log(map.has("key1"));  // false

// Clear all
map.clear();
console.log(map.size);  // 0

// Size
map.set("a", 1);
map.set("b", 2);
console.log(map.size);  // 2

Real Example: User Preferences

const userPreferences = new Map();

userPreferences.set("theme", "dark");
userPreferences.set("language", "en");
userPreferences.set("notifications", true);
userPreferences.set("timezone", "UTC");

// Check preference
if (userPreferences.has("theme")) {
  console.log("Theme:", userPreferences.get("theme"));
}

// Update
userPreferences.set("theme", "light");

// Iterate
userPreferences.forEach((value, key) => {
  console.log(`\({key}: \){value}`);
});

What is Set?

Set is a collection of unique values. No duplicates allowed.

Simple Definition

A Set is a collection where each value appears only once. Duplicates are automatically removed.

// Create Set
const set = new Set();

// Add values
set.add("apple");
set.add("banana");
set.add("orange");
set.add("apple");  // Duplicate, ignored

console.log(set);  // Set(3) { 'apple', 'banana', 'orange' }

Only three items, not four. The duplicate "apple" was ignored.

Creating a Set

// From array
const set = new Set([1, 2, 3, 4, 4, 5, 5, 5]);
console.log(set);  // Set(5) { 1, 2, 3, 4, 5 }

// From string
const charSet = new Set("hello");
console.log(charSet);  // Set(4) { 'h', 'e', 'l', 'o' }

// Empty Set
const emptySet = new Set();

Basic Set Methods

const set = new Set();

// Add
set.add(1);
set.add(2);
set.add(3);

// Check if exists
console.log(set.has(2));  // true
console.log(set.has(4));  // false

// Delete
set.delete(2);
console.log(set.has(2));  // false

// Clear all
set.clear();
console.log(set.size);  // 0

// Size
set.add(1);
set.add(2);
console.log(set.size);  // 2

// Iterate
set.forEach((value) => {
  console.log(value);
});

Real Example: Unique Tags

const tags = new Set();

// User adds tags
tags.add("javascript");
tags.add("webdev");
tags.add("node.js");
tags.add("javascript");  // Duplicate ignored

console.log(tags.size);  // 3

// Check tag exists
if (tags.has("webdev")) {
  console.log("Has webdev tag");
}

// Remove tag
tags.delete("node.js");

// Convert back to array
const tagArray = Array.from(tags);
console.log(tagArray);  // ['javascript', 'webdev']

Set Uniqueness Representation

Adding values to a Set
      |
      v
[1, 2, 3, 4, 4, 5, 5]
|     |     |     |
├─────┼─────┼─────┤
v     v     v     v
Add 1: ✓ (new)
Add 2: ✓ (new)
Add 3: ✓ (new)
Add 4: ✓ (new)
Add 4: ✗ (duplicate, ignored)
Add 5: ✓ (new)
Add 5: ✗ (duplicate, ignored)
Add 5: ✗ (duplicate, ignored)
      |
      v
Result: Set(5) { 1, 2, 3, 4, 5 }

Difference Between Map and Object

Objects Store Key-Value Pairs Too

const obj = {
  name: "Alice",
  age: 25,
  email: "alice@example.com"
};

console.log(obj.name);  // "Alice"
console.log(obj["age"]);  // 25

Objects look similar to Map. But there are important differences.

Difference 1: Key Types

Objects accept only strings and symbols as keys:

const obj = {};

obj["name"] = "Alice";        // ✓ String key
obj[1] = "one";               // ✗ Converted to string "1"
obj[true] = "yes";            // ✗ Converted to string "true"

console.log(obj[1]);          // "one" (key is "1", not 1)

Maps accept any data type as keys:

const map = new Map();

map.set("name", "Alice");     // ✓ String key
map.set(1, "one");            // ✓ Number key
map.set(true, "yes");         // ✓ Boolean key
map.set({}, "object key");    // ✓ Object key
map.set([], "array key");     // ✓ Array key

console.log(map.get(1));      // "one" (key is number 1, not "1")

Difference 2: Size Property

Objects don't have a size property:

const obj = { a: 1, b: 2, c: 3 };

console.log(obj.length);      // undefined
// Must count keys manually
console.log(Object.keys(obj).length);  // 3

Maps have a size property:

const map = new Map([["a", 1], ["b", 2], ["c", 3]]);

console.log(map.size);        // 3 (instant)

Difference 3: Iteration

Objects need Object.keys() or for...in:

const obj = { name: "Alice", age: 25 };

// Need to get keys first
Object.keys(obj).forEach(key => {
  console.log(`\({key}: \){obj[key]}`);
});

// Or use for...in (but gets inherited properties too)
for (let key in obj) {
  console.log(`\({key}: \){obj[key]}`);
}

Maps iterate directly:

const map = new Map([["name", "Alice"], ["age", 25]]);

// Iterate directly
map.forEach((value, key) => {
  console.log(`\({key}: \){value}`);
});

// Or use for...of
for (const [key, value] of map) {
  console.log(`\({key}: \){value}`);
}

Difference 4: Performance

Maps are optimized for frequent additions/deletions:

// Adding/deleting from objects is slower
const obj = {};
for (let i = 0; i < 10000; i++) {
  obj[i] = i;
}
delete obj[5000];  // Slower

// Maps are faster
const map = new Map();
for (let i = 0; i < 10000; i++) {
  map.set(i, i);
}
map.delete(5000);  // Faster

Difference 5: Prototype Chain

Objects inherit from Object.prototype:

const obj = {};

console.log(obj.toString);  // Inherited from Object.prototype

Maps don't have this baggage:

const map = new Map();

console.log(map.toString);  // undefined (unless explicitly set)

When to Use Map vs Object

Difference Between Set and Array

Arrays Store Values Too

const arr = [1, 2, 3, 4, 5];

console.log(arr[0]);  // 1
console.log(arr.length);  // 5

Arrays look similar to Set. But there are key differences.

Difference 1: Uniqueness

Arrays allow duplicates:

const arr = [1, 2, 3, 4, 4, 5, 5, 5];

console.log(arr.length);  // 8 (includes duplicates)

Sets don't allow duplicates:

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

console.log(set.size);  // 5 (duplicates removed)

Difference 2: Checking Membership

Arrays need to search:

const arr = [1, 2, 3, 4, 5];

// Slow for large arrays
console.log(arr.includes(3));  // true
console.log(arr.indexOf(3));   // 2

Sets have instant lookup:

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

console.log(set.has(3));  // true (instant, very fast)

Difference 3: Iteration Methods

Arrays have many methods:

const arr = [1, 2, 3, 4, 5];

arr.map(x => x * 2);         // Transform
arr.filter(x => x > 2);      // Filter
arr.reduce((a, b) => a + b); // Aggregate
arr.find(x => x === 3);      // Find one
arr.some(x => x > 3);        // Check any
arr.every(x => x > 0);       // Check all

Sets have basic iteration:

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

// Can use spread operator for array methods
[...set].map(x => x * 2);
[...set].filter(x => x > 2);

Difference 4: Order

Arrays maintain insertion order (always):

const arr = [5, 1, 3, 2, 4];

console.log(arr[0]);  // 5 (original order)

Sets maintain insertion order (in modern JS):

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

// Iteration order: 5, 1, 3, 2, 4
set.forEach(val => console.log(val));

Difference 5: Memory Usage

Arrays use less memory for small amounts:

const arr = [1, 2, 3];  // Small array

Sets use more memory for small amounts, less for large:

const set = new Set([1, 2, 3]);  // More memory overhead initially

For large collections with duplicates, Sets win.

When to Use Set vs Array

Map Key-Value Storage Visual

Map Storage
      |
      ├─ Key: "name"      → Value: "Alice"
      |
      ├─ Key: 25          → Value: "age"
      |
      ├─ Key: true        → Value: "verified"
      |
      └─ Key: {id: 1}     → Value: "user object"

Each key maps to exactly one value
Keys can be ANY data type
Fast lookup by key

When to Use Map and Set

Use Map When

You need key-value storage with:

// Complex keys
const cache = new Map();
cache.set({ userId: 1 }, { name: "Alice", email: "alice@example.com" });
cache.set({ userId: 2 }, { name: "Bob", email: "bob@example.com" });

console.log(cache.get({ userId: 1 }));  // Won't work (different object)

Or frequent additions/deletions:

const sessions = new Map();

// Add session
sessions.set("session-123", { userId: 1, time: Date.now() });

// Check if exists
if (sessions.has("session-123")) {
  console.log("Session valid");
}

// Remove when expired
sessions.delete("session-123");

// How many sessions?
console.log(sessions.size);

Map Real Examples

Caching:

const cache = new Map();

function getUser(id) {
  if (cache.has(id)) {
    return cache.get(id);
  }
  
  const user = fetchUserFromDatabase(id);
  cache.set(id, user);
  return user;
}

User preferences:

const preferences = new Map();

preferences.set("theme", "dark");
preferences.set("language", "en");
preferences.set("notifications", true);

console.log(preferences.get("theme"));

Use Set When

You need unique values:

// Remove duplicates
const tags = new Set(["javascript", "webdev", "javascript", "node"]);
console.log(tags);  // Set { 'javascript', 'webdev', 'node' }

// Check membership
if (tags.has("javascript")) {
  console.log("Has javascript tag");
}

Or checking membership is critical:

// Fast lookup for permissions
const adminUsers = new Set(["user123", "user456", "user789"]);

if (adminUsers.has(userId)) {
  console.log("Admin access granted");
}

Set Real Examples

Unique values:

// Get unique users who visited page
const visitors = new Set();
visitors.add("alice");
visitors.add("bob");
visitors.add("alice");  // Ignored

console.log(visitors.size);  // 2

Allowed values:

// Valid statuses
const validStatuses = new Set(["pending", "active", "completed", "cancelled"]);

function isValidStatus(status) {
  return validStatuses.has(status);
}

console.log(isValidStatus("active"));    // true
console.log(isValidStatus("invalid"));   // false

Remove duplicates from array:

const numbers = [1, 2, 3, 3, 4, 4, 5, 5, 5];
const unique = [...new Set(numbers)];
console.log(unique);  // [1, 2, 3, 4, 5]

Problems with Objects and Arrays

Objects have issues:

const obj = {};

// All keys become strings
obj[1] = "one";
obj[true] = "yes";
obj[{id: 1}] = "object";

console.log(Object.keys(obj));  // ['1', 'true', '[object Object]']
// Lost the original types!

Arrays have issues with duplicates:

const arr = [1, 2, 3, 3, 4, 4, 5];

// No built-in way to check uniqueness
console.log(arr.length);  // 7 (includes duplicates)

// Checking membership is slow
arr.includes(3);  // Linear search O(n)

Complete Practical Examples

Example 1: User Roles with Map

const userRoles = new Map();

// Add users and their roles
userRoles.set(1, ["user", "admin"]);
userRoles.set(2, ["user"]);
userRoles.set(3, ["user", "moderator"]);

// Check role
function hasRole(userId, role) {
  const roles = userRoles.get(userId);
  return roles && roles.includes(role);
}

console.log(hasRole(1, "admin"));     // true
console.log(hasRole(2, "admin"));     // false

// Update roles
userRoles.set(2, ["user", "admin"]);

// Remove user
userRoles.delete(3);

// How many users?
console.log(userRoles.size);

Example 2: Unique Categories with Set

const categories = new Set();

function addCategory(category) {
  categories.add(category);
}

function removeCategory(category) {
  categories.delete(category);
}

function listCategories() {
  return Array.from(categories);
}

// Add categories
addCategory("javascript");
addCategory("webdev");
addCategory("javascript");  // Ignored
addCategory("node.js");

console.log(listCategories());  // ['javascript', 'webdev', 'node.js']

Example 3: Cache with Map

const apiCache = new Map();
const CACHE_DURATION = 5 * 60 * 1000;  // 5 minutes

async function fetchWithCache(url) {
  // Check if cached
  if (apiCache.has(url)) {
    const cached = apiCache.get(url);
    
    if (Date.now() - cached.timestamp < CACHE_DURATION) {
      console.log("From cache");
      return cached.data;
    } else {
      apiCache.delete(url);  // Expired
    }
  }
  
  // Fetch new data
  console.log("Fetching from API");
  const response = await fetch(url);
  const data = await response.json();
  
  // Cache it
  apiCache.set(url, {
    data,
    timestamp: Date.now()
  });
  
  return data;
}

Example 4: Unique Visitor Tracking with Set

const visitedPages = new Map();

function trackVisit(userId, pageId) {
  if (!visitedPages.has(pageId)) {
    visitedPages.set(pageId, new Set());
  }
  
  visitedPages.get(pageId).add(userId);
}

function getUniqueVisitors(pageId) {
  if (visitedPages.has(pageId)) {
    return visitedPages.get(pageId).size;
  }
  return 0;
}

// Track visits
trackVisit("user1", "page-a");
trackVisit("user1", "page-a");  // Same user
trackVisit("user2", "page-a");
trackVisit("user3", "page-a");

console.log(getUniqueVisitors("page-a"));  // 3 (unique users)

Practice Assignment

1. Create a Map-based user store:

// Create Map to store users with userId as key
// Add three users
// Find a user
// Update a user
// Delete a user
// Show total users

2. Use Set to remove duplicates:

// Given array of tags with duplicates
// Create Set from array
// Convert back to array
// Show unique tags

3. Build a permission system with Set:

// Create Set of allowed permissions
// Create function to check permission
// Test with valid and invalid permissions

4. Cache implementation with Map:

// Create cache Map
// Implement cache function that checks before computing
// Add same value twice, show it's only computed once

5. Visitor tracking with Map and Set:

// Track which users visited which pages
// Use Map for pages, Set for unique users
// Show unique visitor count per page

Quick Recap

• Map is a collection of key-value pairs, better than objects for complex keys.

• Set is a collection of unique values, automatically removes duplicates.

• Map accepts any data type as keys: strings, numbers, objects, functions.

• Object converts all keys to strings or symbols.

• Map has a .size property, objects need Object.keys().length.

• Map iterates directly with .forEach() or for...of.

• Objects need Object.keys() or for...in loop.

• Map is faster for frequent additions and deletions.

• Map is optimized for key-value storage operations.

• Set automatically removes duplicate values.

• Array allows duplicates, Set doesn't.

• Set has instant membership checking with .has().

• Array checking with .includes() is slower.

• Array has .map(), .filter(), .reduce() methods.

• Set needs spread operator [...set] to use array methods.

• Map is perfect for caching, sessions, user data.

• Set is perfect for unique values, permissions, tags.

• Convert Array to Set with new Set(array) to remove duplicates.

• Convert Set to Array with [...set] for array methods.

• Objects are for simple JSON data, Maps for complex key-value logic.

• Arrays are for lists and sequences, Sets for unique values.

Map and Set are powerful tools for clean, efficient data storage.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding why Node.js is so performant and when to use it.

What Makes Node.js Fast

Node.js is fast because of two key ideas:

1. It doesn't wait for operations to finish
2. It handles many requests at the same time

The Speed Problem with Traditional Servers

Traditional servers block. When processing a request:

Request 1 arrives
      |
      v
Server reads database (takes 1 second)
      |
      v
Server sends response
      |
      v
Request 2 arrives
Server is now free

Request 2 waits for Request 1 to finish. The server freezes.

If 100 requests arrive, the server freezes 100 times.

How Node.js Solves This

Node.js doesn't wait. When a request needs to wait for something:

Request 1 arrives
      |
      v
Node starts database query
(doesn't wait)
      |
      v
Request 2 arrives immediately
Node processes it
      |
      v
Request 3 arrives
Node processes it
      |
      v
Database finishes Request 1
Node sends response to client 1

All requests are handled. No freezing.

Real Numbers

Traditional server: 100 requests, each takes 1 second for database = 100 seconds total

Node.js server: 100 requests, all waiting on database simultaneously = 1 second total

Huge difference.

Non-Blocking I/O Concept

Non-blocking I/O means code doesn't pause waiting for slow operations.

I/O Operations

I/O stands for Input/Output. Examples:

• Reading files from disk
• Querying databases
• Making HTTP requests
• Writing to disk

All are slow compared to CPU speed.

Blocking I/O (Traditional)

// Blocking: code pauses here
const data = fs.readFileSync("large-file.txt");
console.log("File read");  // Waits until file is completely read
doOtherStuff();            // Only runs AFTER file is read

The program freezes while reading the file. Nothing else happens.

Non-Blocking I/O (Node.js)

// Non-blocking: code continues immediately
fs.readFile("large-file.txt", (err, data) => {
  console.log("File read");  // Runs when file is done
});
console.log("Request sent");  // Runs immediately
doOtherStuff();               // Runs immediately

The program doesn't wait. It starts reading the file and continues with other tasks. When the file is done, a callback runs.

The Real-World Impact

Blocking (traditional):

Fetch from DB (1 second) ▓▓▓▓▓▓▓▓▓▓
Idle, waiting        ▓▓▓▓▓▓▓▓▓▓
Send response        ▓

Non-blocking (Node.js):

Start DB query ▓
Process next request ▓
Process another request ▓
Process another request ▓
...handle 100 requests ▓▓▓▓▓▓▓▓▓▓
All responses send when ready ▓

Node.js never idles. It's always doing something.

Event-Driven Architecture

Node.js responds to events instead of waiting.

What is Event-Driven?

Instead of:

Ask the kitchen for food
Wait, watching them cook
Food is ready
Leave

Event-driven is:

Ask the kitchen for food
Get a pager number
Go sit down
Do other things
Pager buzzes when ready
Go pick up food
Leave

Much more efficient.

How Events Work in Node.js

// Set up listeners (waiting for events)
fs.readFile("file.txt", (err, data) => {
  console.log("File event: data ready");
});

// More code runs immediately
console.log("File reading started");
makeRequest("http://api.example.com");
queryDatabase("SELECT * FROM users");

console.log("All operations started");

Output:

File reading started
All operations started
(1 second later)
File event: data ready

Code doesn't wait. Events trigger callbacks when ready.

The Event Loop

Node.js has an event loop that checks for completed operations:

Event Loop Cycle
      |
      v
Check if database query finished
      |
      ├─ Yes → Run callback
      └─ No → Continue
      |
      v
Check if file read finished
      |
      ├─ Yes → Run callback
      └─ No → Continue
      |
      v
Check if HTTP request finished
      |
      ├─ Yes → Run callback
      └─ No → Continue
      |
      v
Loop back to start

The loop continuously checks what's done. When something finishes, the callback runs.

Real Example: Restaurant Orders

Without event-driven (blocking):

const order1 = "burger";
waitForFood(order1);  // Cook burger, wait here
serveFood(order1);    // Now take order 2

const order2 = "pizza";
waitForFood(order2);  // Cook pizza, wait here
serveFood(order2);    // Now take order 3

// Only 3 orders in 1 hour

With event-driven (non-blocking):

const order1 = "burger";
startCooking(order1, () => {
  serveFood(order1);  // When done, serve it
});

const order2 = "pizza";
startCooking(order2, () => {
  serveFood(order2);  // When done, serve it
});

const order3 = "fries";
startCooking(order3, () => {
  serveFood(order3);  // When done, serve it
});

// All cooking at the same time!
// 3 orders done in 1/3 the time

Single-Threaded Model Explained

Node.js runs JavaScript on a single thread. But it handles multiple operations.

What is a Thread?

A thread is a line of execution. One thread means one line of code at a time.

Thread 1
First instruction
    |
    v
Second instruction
    |
    v
Third instruction

One task at a time, in order.

Single-Threaded Means

console.log("1");
console.log("2");
console.log("3");

// Output:
// 1
// 2
// 3

Always in order, always one at a time.

But How Does It Handle Multiple Requests?

Here's the magic: while one request waits for I/O, Node.js handles other requests.

Thread (JavaScript execution)

Request 1: console.log("Starting") ▓
           fs.readFile() ▓
Request 1 waits for file...
           (Thread handles Request 2)

Request 2: console.log("Starting") ▓
           fs.readFile() ▓
Request 2 waits for file...
           (Thread handles Request 3)

Request 3: console.log("Starting") ▓
           database.query() ▓
Request 3 waits for database...
           (Check if anything is done)

File finishes for Request 1 ▓
(Thread runs callback for Request 1)
Response sent to Request 1 ▓

While waiting, the thread does other work. Not true parallelism, but looks like it.

Concurrency vs Parallelism

Concurrency (Node.js):

One thread, multiple tasks
Task 1: [=====> wait]
Task 2:        [=====> wait]
Task 3:               [=====>]
        
Thread switches between them
No waiting idle time

Parallelism (Java, C++):

Multiple threads, multiple tasks
Thread 1: Task 1 [=====> wait]
Thread 2: Task 2 [=====> wait]
Thread 3: Task 3 [=====>]
        
True simultaneous execution
More CPU usage

Node.js uses concurrency. Cheaper than parallelism.

Why Single-Threaded is Better for I/O

For I/O-heavy apps, single-threaded is perfect:

• No context switching overhead (threads are expensive)
• No synchronization problems (one thread, no conflicts)
• Less memory (one thread vs many threads)
• Simpler code (no locks or mutexes)

For CPU-intensive apps, it's not ideal:

• Only one CPU core is used
• Heavy calculations freeze the thread
• Better to use multiple threads

Blocking vs Non-Blocking Request Handling

Blocking Server (Traditional)

Request 1 arrives
      |
      v
Database query (1 second)
      |
      v
Response sent
      |
      v
Request 2 arrives
      |
      v
Database query (1 second)
      |
      v
Response sent
      |
      v
Request 3 arrives
      |
      v
Database query (1 second)
      |
      v
Response sent

Total time: 3 seconds for 3 requests
Server frozen during each query

Non-Blocking Server (Node.js)

Request 1 arrives
      |
      v
Start database query (no wait)
      |
      v
Request 2 arrives (immediately)
      |
      v
Start database query (no wait)
      |
      v
Request 3 arrives (immediately)
      |
      v
Start database query (no wait)
      |
      v
(All 3 queries run simultaneously)
      |
      v
Responses sent as queries finish

Total time: 1 second for 3 requests
Server never freezes

Node.js handles 3 requests in 1/3 the time.

Code Comparison

Blocking (traditional server):

// This freezes the entire server
app.get("/users", (req, res) => {
  const users = database.query("SELECT * FROM users");  // Waits 1 second
  res.send(users);  // Only then sends response
});

// Other requests wait while this query runs

Non-blocking (Node.js):

// This doesn't freeze anything
app.get("/users", (req, res) => {
  database.query("SELECT * FROM users", (err, users) => {
    res.send(users);  // Sends when ready
  });
  // Function returns immediately, request is still pending
});

// Other requests are processed while query runs

Where Node.js Performs Best

Perfect For: I/O-Heavy Applications

Node.js excels when dealing with lots of I/O:

Database queries ✓ Perfect
File operations ✓ Perfect
API requests ✓ Perfect
Network I/O ✓ Perfect
Real-time updates ✓ Perfect
Streaming data ✓ Perfect

Perfect For: Real-Time Applications

Chat applications, notifications, live updates:

// WebSocket connection
socket.on("message", (msg) => {
  broadcast(msg);  // Send to all users instantly
});

Event-driven architecture is built for this.

Perfect For: Microservices

Small services that communicate over networks:

User Service → Database ✓
Auth Service → Database ✓
Payment Service → External API ✓
Email Service → SMTP Server ✓

All handle many concurrent connections

Not Ideal For: CPU-Intensive Work

Heavy calculations, image processing, video encoding:

Heavy computation ✗ Bad (freezes thread)
Image resizing ✗ Bad
Video encoding ✗ Bad
Complex calculations ✗ Bad

Only one core is used

For CPU work, use Python, Java, or C++.

Best Use Cases Summary

Web APIs ✓ Excellent
REST services ✓ Excellent
Real-time apps ✓ Excellent
Streaming ✓ Excellent
Microservices ✓ Excellent
File servers ✓ Excellent
Chat apps ✓ Excellent
Dashboards ✓ Excellent

Video processing ✗ Not good
AI/ML training ✗ Not good
Scientific computing ✗ Not good
Image batching ✗ Not good

Real-World Companies Using Node.js

Netflix

Netflix uses Node.js for:

• Fast API responses
• Handling millions of concurrent users
• Real-time recommendations

Why? Non-blocking I/O handles massive traffic without freezing.

Uber

Uber uses Node.js for:

• Real-time location tracking
• Instant ride matching
• Scalable microservices

Why? Event-driven architecture perfect for real-time updates.

Slack

Slack uses Node.js for:

• Instant messaging
• File uploads
• WebSocket connections

Why? Handles thousands of concurrent connections efficiently.

Trello

Trello uses Node.js for:

• Real-time board updates
• Collaborative features
• Fast response times

Why? Event-driven perfect for live collaboration.

Walmart

Walmart uses Node.js for:

• Black Friday traffic spikes
• Mobile app API
• Fast checkout

Why? Handles sudden traffic surges without crashing.

PayPal

PayPal uses Node.js for:

• Payment processing
• High concurrency handling
• Microservices architecture

Why? Non-blocking I/O processes transactions quickly.

LinkedIn

LinkedIn uses Node.js for:

• Mobile apps
• Real-time notifications
• Fast feeds

Why? Single-threaded model is efficient for I/O.

Why These Companies?

All these companies have one thing in common: they need to handle massive concurrent requests without freezing. Node.js excels at this.

Event Loop Request Processing Visualization

User makes multiple requests
      |
      v
Request 1 arrives → starts DB query
Request 2 arrives → starts API call
Request 3 arrives → starts file read
      |
      v
Event Loop Cycle 1:
├─ DB query done? Yes → run callback for Request 1
├─ API call done? No
└─ File read done? No
      |
      v
Event Loop Cycle 2:
├─ API call done? Yes → run callback for Request 2
├─ File read done? No
      |
      v
Event Loop Cycle 3:
├─ File read done? Yes → run callback for Request 3
      |
      v
All responses sent to clients
      |
      v
Waiting for next requests

The event loop constantly checks what's finished and runs callbacks.

Performance Characteristics

Throughput (Requests Per Second)

Node.js can handle thousands of concurrent connections:

Traditional Server
Connections:  10    50    100   500   1000
Server: [OK] [OK] [SLOW] [CRASH]

Node.js Server
Connections:  10    50    100   500   1000   5000
Server:  [OK] [OK]  [OK] [OK]  [OK]  [OK]

Memory Usage

Node.js uses less memory per connection:

Traditional Server: 1 thread per request
1000 requests = 1000 threads = huge memory

Node.js: 1 thread handles thousands
1000 requests = 1 thread = minimal memory

Response Time Under Load

As load increases:

Traditional Server
Load increases → Response time increases linearly → Crashes

Node.js Server
Load increases → Response time stays flat → Handles more

Why? Not waiting. Handling more requests in same time.

Complete Example: Fast API

const express = require("express");
const mysql = require("mysql2/promise");

const app = express();
app.use(express.json());

const pool = mysql.createPool({
  host: "localhost",
  user: "root",
  password: "password",
  database: "mydb",
  waitForConnections: true,
  connectionLimit: 10,
  queueLimit: 0
});

// Non-blocking API endpoint
app.get("/users", async (req, res) => {
  try {
    // Don't wait with blocking code
    const [users] = await pool.query("SELECT * FROM users");
    res.json(users);  // Send when ready
  } catch (error) {
    res.status(500).json({ error: "Database error" });
  }
});

// Multiple concurrent requests handled here
app.get("/posts", async (req, res) => {
  const [posts] = await pool.query("SELECT * FROM posts");
  res.json(posts);
});

// Real-time endpoint
app.get("/live-count", (req, res) => {
  let count = 0;
  const interval = setInterval(() => {
    count++;
    if (count === 10) {
      clearInterval(interval);
      res.json({ count });
    }
  }, 100);
});

app.listen(3000, () => {
  console.log("Server running on port 3000");
  console.log("Try: curl http://localhost:3000/users");
  console.log("Try: curl http://localhost:3000/posts");
  console.log("Multiple requests handled simultaneously");
});

Why This is Fast

Request 1: GET /users
  → Start DB query
  → Don't wait
  |
  └─→ Request 2: GET /posts arrives
      → Start DB query
      → Don't wait
      |
      └─→ Request 3: GET /live-count arrives
          → Start counting
          → Don't wait
          
Both queries run at the same time
All responses sent as they finish
Zero blocking, maximum throughput

Practice Assignment

1. Compare blocking vs non-blocking:

// Write blocking code that makes three database queries
// Then write non-blocking version
// Notice the difference in execution time

2. Understand the event loop:

// Write code that:
// - Starts three async operations
// - Logs when each completes
// - Shows how event loop handles them

3. Real-time application:

// Create Express server with WebSocket
// Broadcast messages to multiple clients
// Show how Node.js handles concurrent connections

4. Measure throughput:

// Create Node.js server that handles requests
// Use Apache Bench or curl in loop to test
// See how many concurrent requests it handles
// Compare with what traditional server could handle

5. Identify use cases:

// Given these projects:
// - Chat application
// - Image processing batch job
// - Stock trading API
// - Video encoding service

// Which should use Node.js? Why?

Quick Recap

• Node.js is fast because it doesn't wait for I/O operations.

• Non-blocking I/O means code continues while operations complete in background.

• Event-driven architecture means responding to events, not waiting for completion.

• Single-threaded Node.js handles concurrency (many requests) not parallelism (many threads).

• One request waiting doesn't freeze other requests.

• The event loop constantly checks what operations are done.

• Blocking servers freeze. Non-blocking servers continue.

• Node.js handles thousands of concurrent connections efficiently.

• Concurrency (switching between tasks) is cheaper than parallelism (multiple threads).

• Node.js uses less memory than traditional servers (one thread vs many).

• Response time stays constant even as load increases (until server is saturated).

• Perfect for I/O-heavy apps: APIs, real-time apps, streaming, microservices.

• Not ideal for CPU-intensive work: image processing, video encoding, heavy calculations.

• Netflix, Uber, Slack, Walmart, PayPal all use Node.js for these reasons.

• Real-time apps like chat, notifications, live updates are built for Node.js.

• One Node.js server handles what would require multiple traditional servers.

• The event-driven model makes code simpler and more readable.

Node.js's non-blocking I/O and event-driven architecture make it perfect for modern web applications.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding destructuring and writing cleaner JavaScript code.

What Destructuring Means

Destructuring is unpacking values from objects and arrays into separate variables.

Simple Definition

Destructuring means taking the values inside a container (object or array) and pulling them out into individual variables.

Real Example

Without destructuring:

const user = { name: "Alice", email: "alice@example.com", age: 25 };

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

console.log(name);   // "Alice"
console.log(email);  // "alice@example.com"
console.log(age);    // 25

Four lines just to extract values.

With destructuring:

const user = { name: "Alice", email: "alice@example.com", age: 25 };

const { name, email, age } = user;

console.log(name);   // "Alice"
console.log(email);  // "alice@example.com"
console.log(age);    // 25

One line. Much cleaner.

The Analogy

Think of unpacking a suitcase.

Without destructuring:

You have a suitcase with clothes inside
You take out one shirt
You take out one pair of pants
You take out one pair of socks
You take out one jacket
(4 separate actions)

With destructuring:

You have a suitcase with clothes inside
You open it and pull out all at once
(1 action, everything is organized)

Same result. Much more efficient.

Why It Matters

Destructuring:

• Reduces repetitive code
• Makes code easier to read
• Saves time
• Reduces mistakes

Destructuring Arrays

Extract values from arrays by position.

Basic Array Destructuring

const colors = ["red", "green", "blue"];

// Without destructuring
const first = colors[0];
const second = colors[1];
const third = colors[2];

// With destructuring
const [first, second, third] = colors;

console.log(first);   // "red"
console.log(second);  // "green"
console.log(third);   // "blue"

The order matters. The first variable gets the first element, the second variable gets the second element, and so on.

Skipping Elements

const colors = ["red", "green", "blue", "yellow"];

// Skip green, get red and blue
const [first, , third] = colors;

console.log(first);  // "red"
console.log(third);  // "blue"

Use empty commas to skip elements.

Rest Operator (Get Remaining Elements)

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

const [first, second, ...rest] = numbers;

console.log(first);  // 1
console.log(second); // 2
console.log(rest);   // [3, 4, 5]

The ...rest operator captures all remaining elements into an array.

Swapping Values

Destructuring makes swapping easy:

let a = 1;
let b = 2;

console.log("Before:", a, b);  // Before: 1 2

// Swap
[a, b] = [b, a];

console.log("After:", a, b);   // After: 2 1

No temporary variable needed.

Destructuring with Functions

function getCoordinates() {
  return [10, 20];
}

const [x, y] = getCoordinates();

console.log(x);  // 10
console.log(y);  // 20

Functions return arrays. Destructure them instantly.

Array Destructuring Mapping

Array
[10, 20, 30, 40, 50]
 |   |   |
 v   v   v
const [a, b, c] = ...
 |   |   |
 v   v   v
a=10, b=20, c=30

Each position in the array maps to a variable in order.

Destructuring Objects

Extract values from objects by property name.

Basic Object Destructuring

const user = { name: "Alice", email: "alice@example.com", age: 25 };

// Without destructuring
const name = user.name;
const email = user.email;
const age = user.age;

// With destructuring
const { name, email, age } = user;

console.log(name);   // "Alice"
console.log(email);  // "alice@example.com"
console.log(age);    // 25

The property names become variables. Order doesn't matter.

Selecting Specific Properties

const user = { name: "Alice", email: "alice@example.com", age: 25, city: "NYC" };

// Only extract name and email
const { name, email } = user;

console.log(name);   // "Alice"
console.log(email);  // "alice@example.com"
// age and city are not extracted

Extract only what you need.

Renaming Variables

const user = { name: "Alice", email: "alice@example.com" };

// Rename email to userEmail
const { name, email: userEmail } = user;

console.log(name);      // "Alice"
console.log(userEmail); // "alice@example.com"

Use the colon to rename properties.

Nested Object Destructuring

const user = {
  name: "Alice",
  address: {
    city: "NYC",
    zipcode: "10001"
  }
};

// Extract nested properties
const { name, address: { city, zipcode } } = user;

console.log(name);     // "Alice"
console.log(city);     // "NYC"
console.log(zipcode);  // "10001"

Access nested properties with additional curly braces.

Rest Operator with Objects

const user = { name: "Alice", email: "alice@example.com", age: 25, city: "NYC" };

// Extract name, rest goes into other
const { name, ...other } = user;

console.log(name);   // "Alice"
console.log(other);  // { email: "alice@example.com", age: 25, city: "NYC" }

The ...other operator captures all remaining properties.

Object → Variable Extraction Visual

Object
{
  name: "Alice",
  email: "alice@example.com",
  age: 25
}
|
├─ name ─────→ name variable
├─ email ────→ email variable
└─ age ──────→ age variable

Result:
name = "Alice"
email = "alice@example.com"
age = 25

Each property name becomes a variable with the same name.

Default Values

Provide fallback values if properties don't exist.

Default Values in Arrays

const colors = ["red"];

const [first, second, third = "blue"] = colors;

console.log(first);   // "red"
console.log(second);  // undefined
console.log(third);   // "blue" (default used)

If an element doesn't exist, use the default.

Practical Array Example

function getSettings() {
  return ["dark"];  // Only one value returned
}

const [theme, language = "en", notifications = true] = getSettings();

console.log(theme);         // "dark"
console.log(language);      // "en" (default)
console.log(notifications); // true (default)

Perfect for functions that return partial data.

Default Values in Objects

const user = { name: "Alice" };  // email missing

const { name, email = "noemail@example.com" } = user;

console.log(name);   // "Alice"
console.log(email);  // "noemail@example.com" (default)

If a property doesn't exist, use the default value.

Multiple Defaults

const settings = { theme: "dark" };

const { theme, language = "en", notifications = true, timezone = "UTC" } = settings;

console.log(theme);         // "dark"
console.log(language);      // "en"
console.log(notifications); // true
console.log(timezone);      // "UTC"

Every property can have a default.

Default with Renamed Variables

const user = { name: "Alice" };

const { name, email: userEmail = "no-email@example.com" } = user;

console.log(name);      // "Alice"
console.log(userEmail); // "no-email@example.com"

Combine renaming and defaults.

Benefits of Destructuring

Benefit 1: Less Repetitive Code

Without destructuring:

const user = { name: "Alice", email: "alice@example.com", age: 25 };

function displayUser() {
  console.log(user.name);
  console.log(user.email);
  console.log(user.age);
}

Repeating user. three times.

With destructuring:

const user = { name: "Alice", email: "alice@example.com", age: 25 };

function displayUser() {
  const { name, email, age } = user;
  console.log(name);
  console.log(email);
  console.log(age);
}

Extract once, use many times.

Benefit 2: Cleaner Function Parameters

Without destructuring:

function createPost(post) {
  const title = post.title;
  const content = post.content;
  const author = post.author;
  
  console.log(`\({title} by \){author}`);
}

createPost({ title: "Hello", content: "World", author: "Alice" });

Without destructuring:

function createPost({ title, content, author }) {
  console.log(`\({title} by \){author}`);
}

createPost({ title: "Hello", content: "World", author: "Alice" });

The function signature shows exactly what data it needs.

Benefit 3: Works with Defaults

Without destructuring:

function displayUser(user) {
  const name = user.name || "Unknown";
  const age = user.age || 0;
  
  console.log(`\({name} is \){age} years old`);
}

Multiple lines for defaults.

With destructuring:

function displayUser({ name = "Unknown", age = 0 }) {
  console.log(`\({name} is \){age} years old`);
}

Defaults built in.

Benefit 4: Easy to Add/Remove Properties

Without destructuring:

const user = { name: "Alice", email: "alice@example.com", age: 25, city: "NYC" };

const name = user.name;
const email = user.email;
const age = user.age;
// city is ignored

// Add city later?
const city = user.city;  // Another line

Without destructuring:

const user = { name: "Alice", email: "alice@example.com", age: 25, city: "NYC" };

const { name, email, age, city } = user;  // Easy to add/remove

One line, easy to modify.

Benefit 5: Immutability

Destructuring creates new variables, not references:

const original = { name: "Alice", age: 25 };

const { name, age } = original;

name = "Bob";  // Only affects the variable, not original object
console.log(original.name);  // "Alice" (unchanged)

Safe from accidental mutations.

Benefit 6: Clear Intent

Without destructuring:

function processData(data) {
  console.log(data.username);
  console.log(data.email);
}

Not obvious what properties are needed.

With destructuring:

function processData({ username, email }) {
  console.log(username);
  console.log(email);
}

Crystal clear what data is required.

Before vs After Destructuring

Example 1: User Profile

Before:

const user = {
  name: "Alice",
  email: "alice@example.com",
  age: 25,
  city: "NYC"
};

const name = user.name;
const email = user.email;
const age = user.age;
const city = user.city;

console.log(`\({name} is \){age} and lives in ${city}`);
console.log(`Email: ${email}`);

After:

const user = {
  name: "Alice",
  email: "alice@example.com",
  age: 25,
  city: "NYC"
};

const { name, email, age, city } = user;

console.log(`\({name} is \){age} and lives in ${city}`);
console.log(`Email: ${email}`);

Cleaner and faster to write.

Example 2: API Response

Before:

function handleResponse(response) {
  const status = response.status;
  const data = response.data;
  const message = response.message;
  
  if (status === 200) {
    console.log(data);
  } else {
    console.log(message);
  }
}

After:

function handleResponse({ status, data, message }) {
  if (status === 200) {
    console.log(data);
  } else {
    console.log(message);
  }
}

Shorter and clearer what the function expects.

Example 3: Array from Function

Before:

function getCoordinates() {
  return [10, 20];
}

const coords = getCoordinates();
const x = coords[0];
const y = coords[1];

console.log(`X: \({x}, Y: \){y}`);

After:

function getCoordinates() {
  return [10, 20];
}

const [x, y] = getCoordinates();

console.log(`X: \({x}, Y: \){y}`);

Much shorter.

Example 4: React Components

Before:

function UserCard(props) {
  return (
    <div>
      <h1>{props.name}</h1>
      <p>{props.email}</p>
      <p>{props.age}</p>
    </div>
  );
}

After:

function UserCard({ name, email, age }) {
  return (
    <div>
      <h1>{name}</h1>
      <p>{email}</p>
      <p>{age}</p>
    </div>
  );
}

Standard pattern in React development.

Common Destructuring Patterns

Pattern 1: Function Parameters

const user = { name: "Alice", age: 25 };

// Destructure in parameters
function greet({ name, age }) {
  console.log(`Hello \({name}, you are \){age}`);
}

greet(user);  // Hello Alice, you are 25

Pattern 2: API Responses

const response = {
  status: 200,
  data: { id: 1, name: "Product" },
  message: "Success"
};

const { status, data, message } = response;

if (status === 200) {
  console.log(data);
}

Pattern 3: Loop Iteration

const users = [
  { name: "Alice", age: 25 },
  { name: "Bob", age: 30 }
];

// Destructure in loop
users.forEach(({ name, age }) => {
  console.log(`\({name} is \){age}`);
});

Pattern 4: Multiple Return Values

function getUserInfo(id) {
  return {
    id,
    name: "Alice",
    email: "alice@example.com"
  };
}

const { name, email } = getUserInfo(1);
console.log(name, email);

Pattern 5: Object Merging with Defaults

const config = { theme: "dark" };
const defaults = { theme: "light", language: "en", timezone: "UTC" };

const { theme = defaults.theme, language = defaults.language, timezone = defaults.timezone } = config;

console.log(theme);     // "dark" (from config)
console.log(language);  // "en" (from defaults)
console.log(timezone);  // "UTC" (from defaults)

Common Mistakes

Mistake 1: Forgetting Curly Braces for Objects

const user = { name: "Alice", age: 25 };

// Wrong - missing curly braces
const name, age = user;

// Correct
const { name, age } = user;

Objects need {}. Arrays use [].

Mistake 2: Wrong Brackets for Arrays

const colors = ["red", "green", "blue"];

// Wrong - using curly braces
const { first, second } = colors;

// Correct
const [first, second] = colors;

Mistake 3: Property Name Must Match

const user = { name: "Alice", age: 25 };

// Wrong - no such property
const { firstName } = user;
console.log(firstName);  // undefined

// Correct
const { name } = user;
console.log(name);  // "Alice"

Property names must match (unless renaming).

Mistake 4: Reassigning Without Declaration

let name;

// Wrong - can't reassign without let/const
{ name } = { name: "Alice" };

// Correct
({ name } = { name: "Alice" });

// Or use let/const
const { name } = { name: "Alice" };

Need parentheses when reassigning without declaration.

Complete Practical Example

// Sample data
const users = [
  { id: 1, name: "Alice", email: "alice@example.com", age: 25, city: "NYC" },
  { id: 2, name: "Bob", email: "bob@example.com", age: 30, city: "LA" },
  { id: 3, name: "Charlie", email: "charlie@example.com", age: 28, city: "Chicago" }
];

// Function with destructuring in parameters
function displayUserInfo({ name, email, age = "Unknown", city = "Unknown" }) {
  console.log(`\({name} (\){age}) from ${city}`);
  console.log(`Email: ${email}`);
  console.log("---");
}

// Display each user
users.forEach(displayUserInfo);

// Destructure in loop
users.forEach(({ name, age }) => {
  console.log(`\({name} is \){age} years old`);
});

// Get multiple values
const [firstUser, secondUser, ...otherUsers] = users;

console.log("First user:", firstUser.name);
console.log("Second user:", secondUser.name);
console.log("Number of other users:", otherUsers.length);

// Extract and rename
const { id: userId, name: userName } = users[0];
console.log(`User ID: \({userId}, Name: \){userName}`);

// Nested destructuring
const { id, name, address: { city: userCity = "Unknown" } = {} } = users[0];
console.log(id, name, userCity);

Practice Assignment

1. Basic array destructuring:

// Given array: [10, 20, 30, 40, 50]
// Extract first and third elements
// Ignore the second
// Extract remaining elements into rest variable

2. Basic object destructuring:

// Given object: { name: "Alice", age: 25, city: "NYC", country: "USA" }
// Extract name and city
// Rename country to nation
// Leave age and country unextracted

3. Default values:

// Given incomplete object: { name: "Bob" }
// Destructure with defaults for missing email, age, city
// Ensure defaults appear in console.log

4. Function parameter destructuring:

// Create function that takes { username, email, status = "active" }
// Log all three values
// Call with complete object, then partial object

5. Real-world scenario:

// Create array of products: { id, name, price, inStock = true }
// Loop through with destructuring
// Extract id and name in one line per product
// Show which are in stock using inStock default

Quick Recap

• Destructuring is unpacking values from objects and arrays into variables.

• Array destructuring uses square brackets: const [a, b, c] = array.

• Object destructuring uses curly braces: const { name, age } = object.

• Order matters in arrays (position-based).

• Property names matter in objects (name-based).

• Use commas to skip array elements: const [first, , third] = array.

• The rest operator (...) captures remaining elements or properties.

• Default values prevent undefined: const { name = "Unknown" } = obj.

• Renaming properties: const { email: userEmail } = obj.

• Nested destructuring works with nested objects and arrays.

• Destructuring reduces repetitive code.

• Function parameters benefit most from destructuring.

• Destructuring makes intent clearer in code.

• Immutability is preserved with destructuring.

• Destructuring works with function return values.

• Modern React relies heavily on destructuring.

• Property names must match unless renaming.

• Arrays use [], objects use {}, don't mix them up.

• Destructuring is optional, not required (but recommended).

Destructuring is one of the most useful modern JavaScript features.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding middleware and building better Express applications.

What is Middleware in Express?

Middleware is a function that processes requests and responses.

Simple Definition

Middleware is a function that:

1. Receives the request object
2. Does something with it
3. Either sends a response or passes control to the next middleware

Real Example

When you visit a website:

User makes request
      |
      v
Middleware 1 checks if logged in
      |
      v
Middleware 2 validates the request
      |
      v
Middleware 3 logs the request
      |
      v
Route handler processes it
      |
      v
Response is sent

The request goes through several checkpoints before the actual route handler.

The Checkpoint Analogy

Think of middleware like checkpoints at an airport:

Passenger enters airport
      |
      v
Checkpoint 1: Check ticket
      |
      v
Checkpoint 2: Security scan
      |
      v
Checkpoint 3: Passport check
      |
      v
Board the plane

Each checkpoint can:

• Allow you through (call next())
• Stop you (send a response)
• Do something as you pass (check ticket, scan bag)

Express middleware works the same way.

Basic Middleware Function

function myMiddleware(req, res, next) {
  // req = incoming request
  // res = response to send
  // next = function to call to move to next middleware
  
  console.log("Request received");
  next();  // Pass to next middleware
}

app.use(myMiddleware);

All middleware functions have this signature: (req, res, next).

Where Middleware Sits in Request Lifecycle

The Complete Request Flow

Client sends HTTP request
      |
      v
Request arrives at Express
      |
      v
Middleware 1 runs
      |
      v
Middleware 2 runs
      |
      v
Middleware 3 runs
      |
      v
Route handler runs
      |
      v
Response is created
      |
      v
Response sent to client
      |
      v
Client receives response

Middleware runs before the route handler. The route handler is the final step.

Request Pipeline

Imagine a factory assembly line:

Raw materials (request)
      |
      v
Station 1: Clean (middleware 1)
      |
      v
Station 2: Paint (middleware 2)
      |
      v
Station 3: Inspect (middleware 3)
      |
      v
Station 4: Package (route handler)
      |
      v
Finished product (response)

Each station modifies or inspects. The final station packages everything.

Code Example

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

// Middleware 1
app.use((req, res, next) => {
  console.log("Middleware 1: Request started at", new Date());
  next();  // Move to next middleware
});

// Middleware 2
app.use((req, res, next) => {
  console.log("Middleware 2: Processing request");
  next();  // Move to next middleware
});

// Route handler
app.get("/", (req, res) => {
  console.log("Route handler: Sending response");
  res.send("Hello World");
});

app.listen(3000);

Order of execution:

Request to /
      |
      v
Middleware 1 runs: "Request started..."
      |
      v
Middleware 2 runs: "Processing request"
      |
      v
Route handler runs: "Sending response"
      |
      v
Response sent: "Hello World"

Types of Middleware

Type 1: Application-Level Middleware

Runs for every request to your application.

// Applies to every request
app.use((req, res, next) => {
  console.log("This runs for every request");
  next();
});

Type 2: Router-Level Middleware

Runs only for specific routes.

// Applies only to /api routes
app.use("/api", (req, res, next) => {
  console.log("This only runs for /api routes");
  next();
});

Type 3: Built-in Middleware

Express provides middleware for common tasks.

// Parse JSON bodies
app.use(express.json());

// Parse form data
app.use(express.urlencoded({ extended: true }));

// Serve static files
app.use(express.static("public"));

Type 4: Error-Handling Middleware

Catches errors from other middleware.

// Must have 4 parameters (err, req, res, next)
app.use((err, req, res, next) => {
  console.log("Error occurred:", err.message);
  res.status(500).json({ error: "Something went wrong" });
});

Error handlers must be defined last.

Application-Level Middleware

Runs for all requests.

Basic Application Middleware

app.use((req, res, next) => {
  console.log("Running for every request");
  next();
});

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

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

Both GET requests pass through the middleware.

Multiple Application Middleware

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

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

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

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

Execution order:

Middleware 1
Middleware 2
Middleware 3
Route handler

Conditional Application Middleware

// Only for GET requests
app.use((req, res, next) => {
  if (req.method === "GET") {
    console.log("This is a GET request");
  }
  next();
});

// Only for specific paths
app.use((req, res, next) => {
  if (req.path.startsWith("/admin")) {
    console.log("Admin route accessed");
  }
  next();
});

Router-Level Middleware

Runs only for specific routes.

Basic Router Middleware

// Applies only to /admin routes
app.use("/admin", (req, res, next) => {
  console.log("Admin route accessed");
  next();
});

app.get("/admin/dashboard", (req, res) => {
  res.send("Admin Dashboard");
});

app.get("/admin/users", (req, res) => {
  res.send("User List");
});

// This route doesn't go through the middleware
app.get("/", (req, res) => {
  res.send("Home");
});

The middleware only runs for requests starting with /admin.

Multiple Router Middleware

// First middleware
app.use("/api", (req, res, next) => {
  console.log("API request received");
  next();
});

// Second middleware
app.use("/api", (req, res, next) => {
  console.log("Processing API request");
  next();
});

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

Both middlewares run for /api/users in order.

Nested Routes with Middleware

// Auth middleware only for protected routes
app.use("/api/admin", (req, res, next) => {
  console.log("Checking authentication");
  next();
});

app.get("/api/admin/stats", (req, res) => {
  res.send("Admin stats");
});

app.get("/api/public/posts", (req, res) => {
  res.send("Public posts");
});

/api/admin/stats passes through middleware. /api/public/posts doesn't.

Built-in Middleware

Express provides common middleware.

JSON Parser

app.use(express.json());

app.post("/data", (req, res) => {
  console.log(req.body);  // Parsed JSON available
  res.send("Data received");
});

Automatically parses JSON request bodies.

Form Data Parser

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

app.post("/form", (req, res) => {
  console.log(req.body);  // Form data available
  res.send("Form received");
});

Parses form submissions.

Static File Serving

app.use(express.static("public"));

// Now http://localhost:3000/style.css serves public/style.css
// And http://localhost:3000/index.html serves public/index.html

Serves files from a directory.

Static with Path Prefix

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

// Now http://localhost:3000/static/style.css serves public/style.css

Serve static files under a specific path.

The Role of next()

next() is crucial. It tells Express to move to the next middleware.

Without next()

app.use((req, res, next) => {
  console.log("Middleware running");
  // Forgot to call next()
});

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

The request hangs. The route handler never runs.

With next()

app.use((req, res, next) => {
  console.log("Middleware running");
  next();  // Pass to next middleware
});

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

The request moves forward. The route handler runs.

Sending Response Instead of next()

app.use((req, res, next) => {
  if (!isAuthenticated(req)) {
    res.status(401).json({ error: "Not authenticated" });
    return;  // Stop here, don't call next()
  }
  next();  // Continue if authenticated
});

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

If authentication fails, send response. Otherwise, continue.

next() with Errors

app.use((req, res, next) => {
  try {
    // Some operation
    JSON.parse("invalid json");
    next();
  } catch (error) {
    next(error);  // Pass error to error handler
  }
});

// Error handler (4 parameters)
app.use((err, req, res, next) => {
  console.log("Error:", err.message);
  res.status(500).send("Error occurred");
});

Pass errors to error handlers with next(error).

Middleware Execution Order

Middleware runs in the order it's defined.

Definition Order Matters

// This runs first
app.use((req, res, next) => {
  console.log("First");
  next();
});

// This runs second
app.use((req, res, next) => {
  console.log("Second");
  next();
});

// This runs third
app.use((req, res, next) => {
  console.log("Third");
  next();
});

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

Output:

First
Second
Third
Route handler

Changing Order

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

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

app.use((req, res, next) => {
  console.log("B");  // This is defined AFTER the route
  next();
});

Output for GET /:

A
(No B - defined after route)

Middleware defined after a route won't run for that route.

Route-Specific Order

// Runs for all /admin routes
app.use("/admin", (req, res, next) => {
  console.log("Admin middleware");
  next();
});

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

// Global middleware defined after still runs first
app.use((req, res, next) => {
  console.log("Global middleware");
  next();
});

Global middleware defined before route-specific middleware runs first.

Request → Middleware → Route Handler Flow

HTTP Request arrives
      |
      v
Express receives request
      |
      v
Global middleware 1 executes
  (can access req, res)
  (can modify request)
  |
  ├─ Call next() → continue
  └─ Send response → stop here
      |
      v
Global middleware 2 executes
      |
      ├─ Call next() → continue
      └─ Send response → stop here
      |
      v
Route-specific middleware executes
      |
      ├─ Call next() → continue
      └─ Send response → stop here
      |
      v
Route handler executes
      |
      ├─ Send response → stop here
      └─ Call next() → (if defined)
      |
      v
Response sent to client
      |
      v
Client receives response

Real-World Example: Logging Middleware

Log every request.

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

// Logging middleware
app.use((req, res, next) => {
  const timestamp = new Date().toISOString();
  console.log(`[\({timestamp}] \){req.method} ${req.path}`);
  next();
});

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

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

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

Output when accessing routes:

[2026-05-04T10:30:45.123Z] GET /
[2026-05-04T10:30:50.456Z] GET /about

Enhanced Logging Middleware

app.use((req, res, next) => {
  const start = Date.now();
  
  // Log when request ends
  res.on("finish", () => {
    const duration = Date.now() - start;
    console.log(
      `\({req.method} \){req.path} - \({res.statusCode} - \){duration}ms`
    );
  });
  
  next();
});

Logs request duration too.

Real-World Example: Authentication Middleware

Protect routes from unauthorized access.

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

// Authentication middleware
function authMiddleware(req, res, next) {
  const token = req.headers.authorization;
  
  if (!token) {
    return res.status(401).json({ error: "No token provided" });
  }
  
  if (token === "Bearer valid-token-123") {
    req.user = { id: 1, name: "Alice" };
    next();
  } else {
    res.status(401).json({ error: "Invalid token" });
  }
}

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

// Protected route (use middleware)
app.get("/profile", authMiddleware, (req, res) => {
  res.send(`Hello ${req.user.name}`);
});

app.listen(3000);

Test without token:

curl http://localhost:3000/profile
# Error: No token provided

Test with token:

curl -H "Authorization: Bearer valid-token-123" http://localhost:3000/profile
# Hello Alice

Protecting Multiple Routes

// Apply middleware to all /api routes
app.use("/api", authMiddleware);

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

app.get("/api/posts", (req, res) => {
  res.send("Posts list");
});

// This route is unprotected
app.get("/public", (req, res) => {
  res.send("Public data");
});

All /api routes require authentication. /public doesn't.

Real-World Example: Request Validation Middleware

Validate request data before processing.

const express = require("express");
const app = express();
app.use(express.json());

// Validation middleware
function validateEmail(req, res, next) {
  const email = req.body.email;
  
  if (!email) {
    return res.status(400).json({ error: "Email is required" });
  }
  
  if (!email.includes("@")) {
    return res.status(400).json({ error: "Invalid email format" });
  }
  
  next();
}

app.post("/signup", validateEmail, (req, res) => {
  const email = req.body.email;
  res.json({ message: `Signed up with ${email}` });
});

app.listen(3000);

Test with valid email:

curl -X POST http://localhost:3000/signup \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com"}'
# Signed up with alice@example.com

Test with invalid email:

curl -X POST http://localhost:3000/signup \
  -H "Content-Type: application/json" \
  -d '{"email":"invalid"}'
# Invalid email format

Test without email:

curl -X POST http://localhost:3000/signup \
  -H "Content-Type: application/json" \
  -d '{}'
# Email is required

Multiple Validations

function validateName(req, res, next) {
  if (!req.body.name || req.body.name.length < 2) {
    return res.status(400).json({ error: "Name must be at least 2 characters" });
  }
  next();
}

function validateEmail(req, res, next) {
  if (!req.body.email || !req.body.email.includes("@")) {
    return res.status(400).json({ error: "Invalid email" });
  }
  next();
}

app.post("/signup", validateName, validateEmail, (req, res) => {
  res.json({ message: "Signup successful" });
});

Both validations run before the route handler.

Multiple Middleware Execution Chain

Request arrives
      |
      v
Middleware 1: Logging
  console.log("Request started")
  |
  ├─ next() called
  |
  v
Middleware 2: Authentication
  Check token
  |
  ├─ Token valid: next()
  ├─ Token invalid: send 401 error (stop)
  |
  v
Middleware 3: Request Validation
  Validate data
  |
  ├─ Data valid: next()
  ├─ Data invalid: send 400 error (stop)
  |
  v
Middleware 4: Add Timestamp
  req.timestamp = Date.now()
  |
  ├─ next() called
  |
  v
Route Handler
  Process request
  Send response
  |
  v
Response sent to client

Each middleware runs in order. If any middleware sends a response, the chain stops.

Complete Practical Example

const express = require("express");
const app = express();
app.use(express.json());

// Middleware 1: Logging
app.use((req, res, next) => {
  const timestamp = new Date().toISOString();
  console.log(`[\({timestamp}] \){req.method} ${req.path}`);
  next();
});

// Middleware 2: Authentication
function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(" ")[1];
  
  if (!token) {
    return res.status(401).json({ error: "No token" });
  }
  
  if (token === "valid-token") {
    req.user = { id: 1, name: "Alice" };
    next();
  } else {
    res.status(401).json({ error: "Invalid token" });
  }
}

// Middleware 3: Request validation
function validateRequest(req, res, next) {
  if (!req.body.email) {
    return res.status(400).json({ error: "Email required" });
  }
  
  if (!req.body.email.includes("@")) {
    return res.status(400).json({ error: "Invalid email" });
  }
  
  next();
}

// Public route (only logging)
app.get("/", (req, res) => {
  res.send("Home");
});

// Protected route (logging + authentication)
app.get("/profile", authenticate, (req, res) => {
  res.json({ message: `Hello ${req.user.name}` });
});

// Protected with validation (logging + authentication + validation)
app.post("/update-email", authenticate, validateRequest, (req, res) => {
  res.json({ message: `Email updated to ${req.body.email}` });
});

// Error handler
app.use((err, req, res, next) => {
  console.log("Error:", err.message);
  res.status(500).json({ error: "Server error" });
});

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

Test:

# Public route (no authentication needed)
curl http://localhost:3000/
# Home

# Protected route without token
curl http://localhost:3000/profile
# No token

# Protected route with token
curl -H "Authorization: Bearer valid-token" http://localhost:3000/profile
# Hello Alice

# Update email without token
curl -X POST http://localhost:3000/update-email \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com"}'
# No token

# Update email with token
curl -X POST http://localhost:3000/update-email \
  -H "Authorization: Bearer valid-token" \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com"}'
# Email updated to alice@example.com

Practice Assignment

1. Create a logging middleware:

// Log every request with timestamp, method, and path
// Must call next() to continue
// Apply to all routes

2. Build an authentication middleware:

// Check Authorization header for token
// If no token, send 401 error
// If valid token, set req.user and call next()
// Protect one route with it

3. Create request validation middleware:

// Validate req.body.name (required, min 2 chars)
// Validate req.body.email (required, contains @)
// Return 400 error if invalid
// Use on a POST route

4. Chain multiple middleware:

// Create logging → authentication → validation chain
// POST route should require all three
// GET route should only require logging
// Test both routes

5. Create route-specific middleware:

// Create /api/admin routes protected by authentication
// Create /api/public routes without protection
// Show how same app has protected and public routes

Quick Recap

• Middleware is code that runs between receiving a request and sending a response.

• Middleware sits in the request pipeline: request → middleware → handler → response.

• Every middleware function takes three parameters: req, res, and next.

• next() passes control to the next middleware in the chain.

• If middleware sends a response, the chain stops (don't call next()).

• Application-level middleware runs for all requests using app.use().

• Router-level middleware runs only for specific paths using app.use("/path", ...).

• Built-in middleware includes express.json(), express.urlencoded(), and express.static().

• Error-handling middleware has four parameters: (err, req, res, next).

• Middleware runs in the order it's defined.

• Middleware defined before a route affects that route.

• Middleware defined after a route doesn't affect that route.

• Logging middleware tracks all incoming requests.

• Authentication middleware protects routes from unauthorized access.

• Validation middleware checks request data before processing.

• Multiple middleware can be applied to a single route.

• Middleware can modify the request object (add properties like req.user).

• Use conditional logic in middleware to run code based on request properties.

Middleware is the foundation of building scalable Express applications.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding promises and writing better asynchronous JavaScript.

What Problem Do Promises Solve?

JavaScript runs one line at a time. But some operations take time: fetching data, reading files, database queries.

The Blocking Problem

Without promises, you'd write code that waits:

// This would freeze everything
const data = getDataFromServer();  // Takes 2 seconds
console.log(data);  // Waits 2 seconds before running
doOtherStuff();     // Waits 4 seconds total

The entire program stops. Nothing else happens. This is bad for user experience.

Real Example: Restaurant

Think of ordering food at a restaurant.

The old way (blocking):

1. Place order
2. Stand at counter
3. Stare at kitchen
4. Wait (30 minutes)
5. Finally eat

You're blocked. You can't do anything else.

The promise way (non-blocking):

1. Place order
2. Get pager number
3. Go sit down
4. Do other things
5. Pager buzzes when food is ready
6. Pick it up and eat

You're not blocked. The pager is like a promise. It tells you "I'll notify you when your order is ready."

The Callback Approach

Before promises, developers used callbacks:

getDataFromServer(function(data) {
  console.log(data);
  doOtherStuff();
});

// Code continues here (non-blocking)

This works, but leads to "callback hell":

getUser(1, function(user) {
  getPostsForUser(user.id, function(posts) {
    getCommentsForPost(posts[0].id, function(comments) {
      getAuthorForComment(comments[0].id, function(author) {
        console.log(author.name);
        // 4 levels deep - hard to read
      });
    });
  });
});

What Promises Solve

Promises make asynchronous code readable:

// Much cleaner
const user = await getUser(1);
const posts = await getPostsForUser(user.id);
const comments = await getCommentsForPost(posts[0].id);
const author = await getAuthorForComment(comments[0].id);
console.log(author.name);

Same logic. Way more readable.

Understanding Promises as Future Values

A promise is an object that represents a value that doesn't exist yet.

Simple Analogy

Imagine ordering a birthday cake from a bakery.

The bakery gives you a receipt (the promise). The receipt doesn't contain the cake yet. But it promises:

• Eventually, you'll get a cake
• Or the bakery will tell you they ran out (rejection)

You can:

• Wait for the receipt to become the cake (.then())
• Plan what to do with the cake (chain operations)
• Handle the "ran out of cake" situation (.catch())

The receipt is like a promise. It's not the cake, but it represents the future cake.

Promise Definition

A promise is an object that represents:

• A value that doesn't exist yet
• But will exist in the future (or will fail)

const promise = new Promise((resolve, reject) => {
  // Operation that takes time
  setTimeout(() => {
    resolve("Done!");  // Success - provide the value
  }, 1000);
});

console.log(promise);  // Promise object (not "Done!" yet)

promise.then((result) => {
  console.log(result);  // "Done!" (after 1 second)
});

The promise is created instantly. But the result arrives later.

Promise States

A promise has three states:

State 1: Pending

Promise created
      |
      v
Waiting for operation to complete
      |
      v
State: PENDING

The promise is waiting. The operation hasn't finished yet.

const promise = new Promise((resolve, reject) => {
  // At this point, promise is PENDING
  // Operation hasn't finished
  setTimeout(() => {
    resolve("Done!");
  }, 1000);
});

// Here, promise is still PENDING
console.log(promise);  // Promise { <pending> }

State 2: Fulfilled

Operation completes successfully
      |
      v
resolve() is called
      |
      v
State: FULFILLED
Value is now available

The operation succeeded. The promise has a value.

const promise = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("Success!");  // Call resolve()
  }, 1000);
});

promise.then((value) => {
  console.log(value);  // "Success!"
});

State 3: Rejected

Operation fails
      |
      v
reject() is called
      |
      v
State: REJECTED
Error is available

The operation failed. The promise has an error.

const promise = new Promise((resolve, reject) => {
  setTimeout(() => {
    reject("Something went wrong!");  // Call reject()
  }, 1000);
});

promise.catch((error) => {
  console.log(error);  // "Something went wrong!"
});

State Transitions

PENDING
  |
  ├─ Operation succeeds → resolve() → FULFILLED
  |
  └─ Operation fails → reject() → REJECTED

A promise starts pending. Then it moves to fulfilled or rejected. Never both. Never back to pending.

Key Rule: Promises are Immutable

Once a promise is fulfilled or rejected, it can't change:

const promise = new Promise((resolve, reject) => {
  resolve("First");
  resolve("Second");  // Ignored
  reject("Error");    // Ignored
});

promise.then((value) => {
  console.log(value);  // "First" only
});

Only the first resolve() or reject() matters. The rest are ignored.

Promise Lifecycle Diagram

Promise Created
      |
      v
Promise is PENDING
(Operation running in background)
      |
      ├─ Success Path        OR        Failure Path
      |                                  |
      v                                  v
   resolve("value")                   reject("error")
      |                                  |
      v                                  v
  FULFILLED                           REJECTED
  (Value ready)                       (Error ready)
      |                                  |
      v                                  v
 .then(callback)                    .catch(callback)
      |                                  |
      v                                  v
  Handler runs                      Handler runs
  (with value)                      (with error)

Creating Promises

Creating a Promise Manually

const promise = new Promise((resolve, reject) => {
  // resolve and reject are functions
  // Call resolve(value) when successful
  // Call reject(error) when failed
});

Simple Example: Timer Promise

const delayPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("Done waiting!");
  }, 2000);
});

console.log("Start");
delayPromise.then((message) => {
  console.log(message);
});
console.log("End");

// Output:
// Start
// End
// (2 seconds later)
// Done waiting!

The code doesn't wait for the promise. It continues. After 2 seconds, the handler runs.

Example: Random Success or Failure

const randomPromise = new Promise((resolve, reject) => {
  const random = Math.random();
  
  if (random > 0.5) {
    resolve("Lucky!");
  } else {
    reject("Unlucky!");
  }
});

randomPromise
  .then((message) => {
    console.log("Success:", message);
  })
  .catch((error) => {
    console.log("Error:", error);
  });

Sometimes it succeeds. Sometimes it fails.

Handling Success and Failure

The .then() Method

.then() runs when the promise is fulfilled:

promise.then((value) => {
  console.log("Promise succeeded:", value);
});

The callback receives the value from resolve().

The .catch() Method

.catch() runs when the promise is rejected:

promise.catch((error) => {
  console.log("Promise failed:", error);
});

The callback receives the error from reject().

Both Together

const promise = new Promise((resolve, reject) => {
  const success = Math.random() > 0.5;
  
  if (success) {
    resolve("It worked!");
  } else {
    reject("It failed!");
  }
});

promise
  .then((value) => {
    console.log("Success:", value);
  })
  .catch((error) => {
    console.log("Error:", error);
  });

One or the other will run. Never both.

Real Example: Fetching Data

const fetchUserData = new Promise((resolve, reject) => {
  // Simulate API call
  setTimeout(() => {
    const success = Math.random() > 0.2;
    
    if (success) {
      const user = { id: 1, name: "Alice" };
      resolve(user);
    } else {
      reject("Network error");
    }
  }, 1000);
});

fetchUserData
  .then((user) => {
    console.log("User:", user);
    console.log("Name:", user.name);
  })
  .catch((error) => {
    console.log("Failed to fetch:", error);
  });

The .finally() Method

.finally() runs regardless of success or failure:

promise
  .then((value) => {
    console.log("Success:", value);
  })
  .catch((error) => {
    console.log("Error:", error);
  })
  .finally(() => {
    console.log("Operation complete (success or failure)");
  });

Use .finally() for cleanup code. Like closing a database connection.

Promise Chaining

Promises can be chained. Each .then() returns a new promise.

Why Chaining?

Instead of nested callbacks:

// Callback hell
getUser(1, function(user) {
  getPostsForUser(user.id, function(posts) {
    console.log(posts);
  });
});

You can chain promises:

// Much cleaner
getUser(1)
  .then((user) => {
    return getPostsForUser(user.id);
  })
  .then((posts) => {
    console.log(posts);
  });

Linear. Readable. Each step is clear.

How Chaining Works

Each .then() returns a promise:

const step1 = getUser(1);          // Returns promise

const step2 = step1.then((user) => {
  return getPostsForUser(user.id);  // Returns new promise
});

const step3 = step2.then((posts) => {
  console.log(posts);               // No return = promise resolves with undefined
});

Or chained together:

getUser(1)
  .then((user) => {
    return getPostsForUser(user.id);
  })
  .then((posts) => {
    return getCommentsForPost(posts[0].id);
  })
  .then((comments) => {
    console.log(comments);
  })
  .catch((error) => {
    console.log("Something failed:", error);
  });

Passing Data Through Chains

getUser(1)
  .then((user) => {
    console.log("Step 1:", user);
    return getPostsForUser(user.id);  // Pass to next step
  })
  .then((posts) => {
    console.log("Step 2:", posts);
    return posts[0];                  // Pass post to next step
  })
  .then((firstPost) => {
    console.log("Step 3:", firstPost);
  });

Each step receives the return value from the previous step.

Error Handling in Chains

If any step fails, the chain stops and jumps to .catch():

getUser(1)
  .then((user) => {
    return getPostsForUser(user.id);  // If this fails...
  })
  .then((posts) => {
    return getCommentsForPost(posts[0].id);  // This won't run
  })
  .then((comments) => {
    console.log(comments);             // This won't run
  })
  .catch((error) => {
    console.log("Error caught here:", error);  // Error caught here
  });

One error anywhere in the chain is caught at the end.

Practical Example: Login Flow

authenticateUser(email, password)
  .then((token) => {
    console.log("Login successful");
    return fetchUserData(token);  // Use token to fetch data
  })
  .then((user) => {
    console.log("User loaded:", user.name);
    return updateLastLogin(user.id);
  })
  .then(() => {
    console.log("Last login updated");
    redirectToDashboard();
  })
  .catch((error) => {
    console.log("Login failed:", error);
    showErrorMessage(error);
  });

Clean flow: authenticate → fetch → update → redirect.

Callback vs Promise Comparison

Callback Approach

// Nested callbacks - "callback hell"
getUser(1, function(err, user) {
  if (err) {
    console.log("Error:", err);
  } else {
    getPostsForUser(user.id, function(err, posts) {
      if (err) {
        console.log("Error:", err);
      } else {
        getCommentsForPost(posts[0].id, function(err, comments) {
          if (err) {
            console.log("Error:", err);
          } else {
            console.log("Comments:", comments);
          }
        });
      }
    });
  }
});

Problems:

• Hard to read (pyramid of doom)
• Error handling scattered everywhere
• Difficult to follow the flow
• Easy to make mistakes

Promise Approach

// Clear chain - easy to follow
getUser(1)
  .then((user) => {
    return getPostsForUser(user.id);
  })
  .then((posts) => {
    return getCommentsForPost(posts[0].id);
  })
  .then((comments) => {
    console.log("Comments:", comments);
  })
  .catch((error) => {
    console.log("Error:", error);
  });

Benefits:

• Linear flow (top to bottom)
• Error handling in one place
• Easy to read
• Easy to modify

Async/Await (Built on Promises)

Modern JavaScript makes it even simpler:

// Built on top of promises - looks like synchronous code
async function loadComments() {
  try {
    const user = await getUser(1);
    const posts = await getPostsForUser(user.id);
    const comments = await getCommentsForPost(posts[0].id);
    console.log("Comments:", comments);
  } catch (error) {
    console.log("Error:", error);
  }
}

loadComments();

Same promise behavior, but the syntax is simpler.

Common Promise Patterns

Promise.all() - Wait for All

Run multiple operations in parallel and wait for all:

const user = getUser(1);
const posts = getPostsForUser(1);
const comments = getComments(1);

Promise.all([user, posts, comments])
  .then(([userData, postsData, commentsData]) => {
    console.log("All data loaded");
    console.log("User:", userData);
    console.log("Posts:", postsData);
    console.log("Comments:", commentsData);
  })
  .catch((error) => {
    console.log("One or more failed:", error);
  });

If any promise fails, the whole thing fails.

Promise.race() - Wait for First

Run multiple operations and use the result of whichever finishes first:

const timeout = new Promise((resolve, reject) => {
  setTimeout(() => reject("Timeout"), 5000);
});

const apiCall = fetchData();

Promise.race([apiCall, timeout])
  .then((result) => {
    console.log("Got result:", result);
  })
  .catch((error) => {
    console.log("Failed or timed out:", error);
  });

Useful for timeout handling.

Promise.resolve() - Instant Success

Create a promise that's already fulfilled:

const instantPromise = Promise.resolve("Done!");

instantPromise.then((value) => {
  console.log(value);  // "Done!" (runs immediately)
});

Promise.reject() - Instant Failure

Create a promise that's already rejected:

const failedPromise = Promise.reject("Error!");

failedPromise.catch((error) => {
  console.log(error);  // "Error!" (runs immediately)
});

Complete Example: Building a Promise

// Create a promise that simulates an API call
function fetchUserData(userId) {
  return new Promise((resolve, reject) => {
    // Simulate network delay
    setTimeout(() => {
      // Simulate success/failure
      if (userId > 0) {
        const user = { id: userId, name: "Alice", email: "alice@example.com" };
        resolve(user);  // Success
      } else {
        reject("Invalid user ID");  // Failure
      }
    }, 1000);
  });
}

// Use the promise
fetchUserData(1)
  .then((user) => {
    console.log("Fetched user:", user.name);
    return fetchUserPosts(user.id);
  })
  .then((posts) => {
    console.log("User has", posts.length, "posts");
  })
  .catch((error) => {
    console.log("Failed:", error);
  })
  .finally(() => {
    console.log("Operation complete");
  });

// Test with invalid ID
fetchUserData(-1)
  .then((user) => {
    console.log("User:", user);
  })
  .catch((error) => {
    console.log("Error:", error);
  });

Practice Assignment

1. Create a simple promise:

// Create a promise that resolves with "Hello"
// After 1 second
// Use .then() to log the result

2. Handle both success and failure:

// Create a promise that randomly resolves or rejects
// Implement .then() and .catch()
// Test multiple times

3. Chain multiple promises:

// Create three functions that return promises
// Each one should use the result of the previous
// Chain them together with .then()
// Add error handling with .catch()

4. Compare callbacks vs promises:

// Write the same operation with callbacks
// Then rewrite with promises
// Notice the difference in readability

5. Use Promise.all():

// Create three promises that fetch different data
// Use Promise.all() to wait for all of them
// Handle success and failure

Quick Recap

• Promises represent values that don't exist yet but will exist in the future.

• A promise solves the callback hell problem by making asynchronous code readable.

• Promises are like a receipt at a restaurant: you don't have the cake yet, but the receipt promises you'll get it.

• Pending state: promise is waiting for an operation to complete.

• Fulfilled state: operation succeeded and the promise has a value.

• Rejected state: operation failed and the promise has an error.

• A promise transitions from pending to either fulfilled or rejected, never both.

• Once a promise is fulfilled or rejected, it cannot change states again.

• resolve(value) moves a promise to fulfilled state with a value.

• reject(error) moves a promise to rejected state with an error.

• .then(callback) handles successful completion (fulfilled state).

• .catch(callback) handles failure (rejected state).

• .finally(callback) runs regardless of success or failure.

• Promise chaining allows multiple operations in sequence with .then().then().then().

• Each .then() returns a new promise, enabling chaining.

• Errors in a promise chain jump to the nearest .catch().

• Promise.all() waits for multiple promises, failing if any fails.

• Promise.race() waits for the first promise to complete.

• Callbacks are harder to read and lead to "callback hell."

• Promises are cleaner and more maintainable.

• Async/await is built on top of promises and makes code even simpler.

Promises are the foundation of modern JavaScript asynchronous programming.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding how file uploads work and building upload systems with Express and Multer.

Why File Uploads Need Middleware

When a user uploads a file, the browser doesn't send it like normal form data.

Regular Form Data

// Normal form data
const data = {
  name: "Alice",
  email: "alice@example.com"
};

// Sent as URL-encoded
name=Alice&email=alice@example.com

Express can parse this automatically with express.urlencoded().

File Uploads Are Different

Files are binary data. They can't be sent as simple text like name=Alice&email=alice@example.com.

The browser uses a special format called multipart/form-data.

What is Multipart/Form-Data?

Think of it like a package with multiple items:

------boundary123456
Content-Disposition: form-data; name="email"

alice@example.com
------boundary123456
Content-Disposition: form-data; name="file"; filename="resume.pdf"
Content-Type: application/pdf

[binary file data here]
------boundary123456--

It's a special format that separates form fields and files with boundaries.

Why You Need Middleware

Express by itself cannot:

• Parse multipart/form-data
• Extract files from the request
• Save files to disk
• Handle file streams safely

Without middleware, you'd have to:

// Without middleware: painful
app.post("/upload", (req, res) => {
  // Manually parse multipart boundaries
  // Manually extract binary data
  // Manually save to disk
  // Manually handle errors
  // 100+ lines of code
});

With Multer:

// With Multer: simple
app.post("/upload", multer({ dest: "uploads/" }).single("file"), (req, res) => {
  // File is already saved
  res.json({ message: "File uploaded" });
});

That's why you need middleware for file uploads.

What is Multer?

Multer is Express middleware that handles multipart/form-data.

Simple Definition

Multer is a library that:

• Parses incoming file uploads
• Extracts files from requests
• Saves files to your server
• Provides file information to your route

It sits between the client and your route handler.

Real Example

Client sends file
      |
      v
Multer receives multipart/form-data
      |
      v
Multer parses the boundaries
      |
      v
Multer extracts the file
      |
      v
Multer saves to disk (or memory)
      |
      v
Your route handler gets req.file
      |
      v
You send response

Why Multer

Before Multer, developers had to:

• Manually parse multipart boundaries
• Handle file streams
• Validate file types
• Manage storage locations

Multer automates all of this.

Installation

npm install multer

Multer Middleware Execution Flow

Request arrives with file
      |
      v
Multer checks Content-Type
(must be multipart/form-data)
      |
      v
Multer parses boundaries
      |
      v
Multer extracts file(s)
      |
      v
Multer validates (size, type, etc)
      |
      v
Multer saves to destination
      |
      v
Multer populates req.file or req.files
      |
      v
Route handler executes

The middleware does all the heavy lifting before your code runs.

Handling Single File Upload

Basic Setup

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

const app = express();

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

// Single file upload route
app.post("/upload", upload.single("file"), (req, res) => {
  // req.file contains the uploaded file
  res.json({
    message: "File uploaded successfully",
    file: req.file
  });
});

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

What Happens

1. Client sends file in form field named "file"
2. Multer intercepts the request
3. Multer saves file to uploads/ directory
4. Multer adds req.file object to the request
5. Route handler accesses req.file

The req.file Object

app.post("/upload", upload.single("file"), (req, res) => {
  console.log(req.file);
  // Outputs:
  // {
  //   fieldname: "file",          // Form field name
  //   originalname: "resume.pdf",  // Original filename
  //   encoding: "7bit",            // File encoding
  //   mimetype: "application/pdf",  // File type
  //   destination: "uploads/",     // Where it was saved
  //   filename: "abc123def456",    // Saved filename (random)
  //   path: "uploads/abc123def456", // Full path
  //   size: 45678                  // File size in bytes
  // }
  
  res.json({
    filename: req.file.filename,
    size: req.file.size,
    mimetype: req.file.mimetype
  });
});

HTML Form for Upload

<!DOCTYPE html>
<html>
<body>
  <form action="http://localhost:3000/upload" method="POST" enctype="multipart/form-data">
    <input type="file" name="file" required>
    <button type="submit">Upload</button>
  </form>
</body>
</html>

Important: The enctype="multipart/form-data" is required. Without it, the file isn't sent correctly.

Test With curl

curl -X POST \
  -F "file=@resume.pdf" \
  http://localhost:3000/upload

The -F flag tells curl to send as multipart/form-data.

Handling Multiple File Uploads

Multiple Files, Single Field

Upload several files using the same form field:

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

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

app.post("/upload-multiple", upload.array("files", 10), (req, res) => {
  // req.files is an array of file objects
  res.json({
    message: "Files uploaded",
    count: req.files.length,
    files: req.files.map(f => ({
      filename: f.filename,
      size: f.size
    }))
  });
});

app.listen(3000);

What Changed

.single("file") becomes .array("files", 10).

The second argument is the maximum number of files allowed. This prevents abuse.

req.files Array

app.post("/upload-multiple", upload.array("files", 10), (req, res) => {
  console.log(req.files);
  // Outputs array of file objects:
  // [
  //   { fieldname: "files", originalname: "doc1.pdf", ... },
  //   { fieldname: "files", originalname: "doc2.pdf", ... },
  //   { fieldname: "files", originalname: "doc3.pdf", ... }
  // ]
  
  req.files.forEach(file => {
    console.log(`\({file.originalname} (\){file.size} bytes)`);
  });
});

HTML Form for Multiple Files

<form action="http://localhost:3000/upload-multiple" method="POST" enctype="multipart/form-data">
  <input type="file" name="files" multiple required>
  <button type="submit">Upload Files</button>
</form>

The multiple attribute lets users select multiple files.

Different Fields, Different Files

Upload files to different form fields:

// .fields() takes an array of field configurations
const upload = multer({ dest: "uploads/" });

app.post("/upload-mixed", upload.fields([
  { name: "avatar", maxCount: 1 },
  { name: "documents", maxCount: 5 }
]), (req, res) => {
  console.log(req.files);
  // Outputs:
  // {
  //   avatar: [ { file object } ],
  //   documents: [ { file object }, { file object }, ... ]
  // }
  
  const avatar = req.files.avatar[0];
  const docs = req.files.documents;
  
  res.json({ avatar, docs });
});

HTML Form with Multiple Fields

<form action="http://localhost:3000/upload-mixed" method="POST" enctype="multipart/form-data">
  <label>Profile Picture</label>
  <input type="file" name="avatar" required>
  
  <label>Documents</label>
  <input type="file" name="documents" multiple required>
  
  <button type="submit">Upload</button>
</form>

Storage Configuration Basics

By default, Multer saves files with random names. You might want to customize this.

Memory Storage

Store files in RAM instead of disk:

const multer = require("multer");

// Memory storage (files in RAM)
const storage = multer.memoryStorage();
const upload = multer({ storage });

app.post("/upload", upload.single("file"), (req, res) => {
  // File is in memory
  console.log(req.file);
  // {
  //   fieldname: "file",
  //   originalname: "resume.pdf",
  //   encoding: "7bit",
  //   mimetype: "application/pdf",
  //   buffer: <Buffer...>,    // File binary data
  //   size: 45678
  // }
  
  // No destination or path (it's in RAM)
  res.json({ message: "File received" });
});

Use memory storage when:

• Files are small
• You process them immediately
• You don't need to persist them

Don't use memory storage when:

• Files are large (drains RAM)
• Many users upload simultaneously
• You need to store files permanently

Disk Storage with Custom Names

Save to disk with meaningful filenames:

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

// Disk storage with custom configuration
const storage = multer.diskStorage({
  destination: (req, file, cb) => {
    // Where to save
    cb(null, "uploads/");
  },
  filename: (req, file, cb) => {
    // How to name the file
    // cb(null, originalname) keeps the original name
    // But this is risky (filename injection)
    
    // Better: use timestamp + original extension
    const uniqueName = Date.now() + path.extname(file.originalname);
    cb(null, uniqueName);
  }
});

const upload = multer({ storage });

app.post("/upload", upload.single("file"), (req, res) => {
  console.log(req.file.filename);
  // Output: 1620000000000.pdf
  
  res.json({ filename: req.file.filename });
});

Safe Filename Strategy

Never trust the user's filename. Always generate your own:

const storage = multer.diskStorage({
  destination: (req, file, cb) => {
    cb(null, "uploads/");
  },
  filename: (req, file, cb) => {
    // Option 1: Timestamp + extension
    const filename = Date.now() + path.extname(file.originalname);
    cb(null, filename);
    
    // Option 2: UUID + extension
    // const filename = uuid() + path.extname(file.originalname);
    // cb(null, filename);
    
    // Option 3: User ID + timestamp
    // const filename = req.user.id + "-" + Date.now() + path.extname(file.originalname);
    // cb(null, filename);
  }
});

Always append the file extension to preserve file type.

Complete Storage Example

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

const app = express();

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

const upload = multer({
  storage,
  limits: { fileSize: 5 * 1024 * 1024 }, // 5MB max
  fileFilter: (req, file, cb) => {
    // Only allow PDF and images
    const allowedMimes = ["application/pdf", "image/jpeg", "image/png"];
    if (allowedMimes.includes(file.mimetype)) {
      cb(null, true);
    } else {
      cb(new Error("Invalid file type"));
    }
  }
});

app.post("/upload", upload.single("file"), (req, res) => {
  res.json({
    message: "File uploaded",
    filename: req.file.filename,
    size: req.file.size
  });
});

app.listen(3000);

Key options:

• limits.fileSize: Maximum file size in bytes
• fileFilter: Validate file type, name, or size

Serving Uploaded Files

After uploading, users need to download or view files.

Static File Serving

Tell Express to serve files from the uploads directory:

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

const app = express();

// Serve uploaded files as static
app.use("/uploads", express.static("uploads/"));

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

const upload = multer({ storage });

app.post("/upload", upload.single("file"), (req, res) => {
  const fileUrl = `/uploads/${req.file.filename}`;
  
  res.json({
    message: "File uploaded",
    url: fileUrl  // Client can access at this URL
  });
});

app.listen(3000);

Now files are accessible at http://localhost:3000/uploads/filename.

Downloading vs Viewing

In the browser, images display. But PDFs should download:

app.get("/download/:filename", (req, res) => {
  const filename = req.params.filename;
  const filepath = path.join(__dirname, "uploads", filename);
  
  // Force download
  res.download(filepath);
});

The .download() method tells the browser to download instead of display.

Complete Upload and Download Example

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

const app = express();

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

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

const upload = multer({ storage });

// Upload endpoint
app.post("/upload", upload.single("file"), (req, res) => {
  res.json({
    message: "File uploaded",
    filename: req.file.filename,
    url: `/uploads/${req.file.filename}`
  });
});

// Download endpoint
app.get("/download/:filename", (req, res) => {
  const filepath = path.join(__dirname, "uploads", req.params.filename);
  res.download(filepath);
});

// View files endpoint
app.get("/files", (req, res) => {
  const fs = require("fs");
  const files = fs.readdirSync("uploads/");
  
  res.json({ files });
});

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

Test Upload and Download

Upload:

curl -X POST \
  -F "file=@resume.pdf" \
  http://localhost:3000/upload

Response:

{
  "message": "File uploaded",
  "filename": "1620000000000.pdf",
  "url": "/uploads/1620000000000.pdf"
}

Download:

curl -O http://localhost:3000/download/1620000000000.pdf

Or in the browser: http://localhost:3000/uploads/1620000000000.pdf

Client to Server to Storage Upload Lifecycle

User selects file in browser
      |
      v
Form sends POST request
(multipart/form-data format)
      |
      v
Express receives request
      |
      v
Multer middleware intercepts
      |
      v
Multer parses multipart boundaries
      |
      v
Multer extracts file data
      |
      v
Multer validates file
(type, size, filters)
      |
      ├─ Invalid → Error response
      └─ Valid → Continue
      |
      v
Multer saves to disk
(or memory)
      |
      v
Multer populates req.file
      |
      v
Route handler executes
      |
      v
Handler sends response
(with file info/URL)
      |
      v
Browser receives response
      |
      v
User can access file at URL

Common Multer Options

File Size Limits

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

Reject files larger than 5MB.

File Type Validation

const upload = multer({
  storage,
  fileFilter: (req, file, cb) => {
    if (file.mimetype === "application/pdf") {
      cb(null, true);  // Accept
    } else {
      cb(new Error("Only PDF files allowed"));  // Reject
    }
  }
});

Only allow PDFs. Reject other types.

Multiple Extensions

const upload = multer({
  storage,
  fileFilter: (req, file, cb) => {
    const allowedTypes = ["image/jpeg", "image/png", "application/pdf"];
    
    if (allowedTypes.includes(file.mimetype)) {
      cb(null, true);
    } else {
      cb(new Error("Invalid file type"));
    }
  }
});

Allow images and PDFs.

Error Handling

app.post("/upload", (req, res) => {
  upload.single("file")(req, res, (err) => {
    if (err instanceof multer.MulterError) {
      // Multer error (file too large, etc)
      return res.status(400).json({ error: err.message });
    } else if (err) {
      // Custom error (from fileFilter)
      return res.status(400).json({ error: err.message });
    }
    
    // Success
    res.json({ message: "File uploaded", file: req.file });
  });
});

Catch both Multer errors and custom validation errors.

Complete Practical Example

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

const app = express();
app.use(express.json());

// Create uploads folder if it doesn't exist
if (!fs.existsSync("uploads/")) {
  fs.mkdirSync("uploads/");
}

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

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

// Configure upload with validation
const upload = multer({
  storage,
  limits: { fileSize: 5 * 1024 * 1024 }, // 5MB max
  fileFilter: (req, file, cb) => {
    const allowedTypes = ["image/jpeg", "image/png", "application/pdf"];
    if (allowedTypes.includes(file.mimetype)) {
      cb(null, true);
    } else {
      cb(new Error("Only JPEG, PNG, and PDF files are allowed"));
    }
  }
});

// Single file upload
app.post("/upload", (req, res) => {
  upload.single("file")(req, res, (err) => {
    if (err) {
      return res.status(400).json({ error: err.message });
    }
    
    if (!req.file) {
      return res.status(400).json({ error: "No file provided" });
    }
    
    res.json({
      message: "File uploaded successfully",
      file: {
        filename: req.file.filename,
        originalname: req.file.originalname,
        size: req.file.size,
        url: `/uploads/${req.file.filename}`
      }
    });
  });
});

// Multiple files upload
app.post("/upload-multiple", (req, res) => {
  upload.array("files", 10)(req, res, (err) => {
    if (err) {
      return res.status(400).json({ error: err.message });
    }
    
    if (!req.files || req.files.length === 0) {
      return res.status(400).json({ error: "No files provided" });
    }
    
    const files = req.files.map(f => ({
      filename: f.filename,
      originalname: f.originalname,
      size: f.size,
      url: `/uploads/${f.filename}`
    }));
    
    res.json({
      message: "Files uploaded successfully",
      count: files.length,
      files
    });
  });
});

// List uploaded files
app.get("/files", (req, res) => {
  fs.readdir("uploads/", (err, files) => {
    if (err) {
      return res.status(500).json({ error: "Could not read files" });
    }
    
    res.json({ files });
  });
});

// Download file
app.get("/download/:filename", (req, res) => {
  const filepath = path.join(__dirname, "uploads", req.params.filename);
  
  // Prevent directory traversal attacks
  if (!filepath.startsWith(path.join(__dirname, "uploads"))) {
    return res.status(403).json({ error: "Forbidden" });
  }
  
  res.download(filepath);
});

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

Test it:

# Upload single file
curl -X POST \
  -F "file=@resume.pdf" \
  http://localhost:3000/upload

# Upload multiple files
curl -X POST \
  -F "files=@file1.pdf" \
  -F "files=@file2.pdf" \
  http://localhost:3000/upload-multiple

# List files
curl http://localhost:3000/files

# Download file
curl -O http://localhost:3000/download/1620000000000.pdf

Practice Assignment

1. Build a single file upload route:

// Create POST /upload endpoint
// Accept file in "file" form field
// Save to "uploads/" directory
// Return uploaded file info
// Test with curl

2. Add file validation:

// Validate file type (only PDF and images)
// Validate file size (max 2MB)
// Return error if validation fails
// Test with invalid file

3. Create multiple file upload:

// Create POST /upload-multiple endpoint
// Accept up to 5 files in "files" field
// Save all files
// Return array of file info
// Test with multiple files

4. Serve uploaded files:

// Use express.static() for uploads folder
// Create GET /files endpoint to list all files
// Create GET /download/:filename endpoint
// Test accessing and downloading files

5. Add error handling:

// Handle Multer errors (file too large)
// Handle custom validation errors
// Return meaningful error messages
// Test with various error scenarios

Quick Recap

• File uploads are sent as multipart/form-data, a special format the browser uses to send binary data.

• Middleware is needed because Express doesn't parse multipart/form-data by default.

• Multer is Express middleware that parses multipart/form-data and saves files.

• .single("field") uploads one file from form field "field".

• .array("field", max) uploads multiple files from the same field.

• .fields() uploads different files to different fields.

• req.file contains info about a single uploaded file (with .single()).

• req.files contains info about multiple uploaded files (with .array() or .fields()).

• Memory storage stores files in RAM (good for small, temporary files).

• Disk storage saves files to the server filesystem (good for persistent storage).

• Always use custom filenames to prevent filename injection attacks.

• File validation with fileFilter prevents unwanted file types.

• File size limits prevent storage abuse.

• express.static() serves uploaded files so users can access them.

• res.download() forces download instead of viewing in the browser.

• Multipart/form-data requires the HTML form attribute enctype="multipart/form-data".

Multer makes file uploads simple and secure.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding what Node.js is and why it changed how we build web applications.

What is Node.js?

Node.js is a runtime environment that executes JavaScript code outside the browser.

The Simple Definition

Runtime = An environment where code runs. JavaScript runtime = A place where JavaScript code executes.

Before Node.js, only browsers could run JavaScript. Node.js made it possible to run JavaScript on servers too.

Real Example

Before Node.js:

Frontend: JavaScript (in browser)
Backend: PHP, Python, Java (on server)
You had to learn multiple languages

After Node.js:

Frontend: JavaScript (in browser)
Backend: JavaScript (on server)
One language everywhere

Why This Matters

Most developers already knew JavaScript for the browser. Node.js meant they could write backend code without learning a new language.

Why Was JavaScript Browser-Only?

JavaScript was literally created for browsers.

The Origin Story (1995)

Brendan Eich created JavaScript in 10 days for Netscape Navigator. It was designed to:

• Run in web browsers
• Manipulate HTML and CSS
• Respond to user interactions
• Validate forms

There was no concept of "server-side JavaScript" in 1995.

Browser Capabilities

Browsers had everything JavaScript needed:

// Browser JavaScript
document.getElementById("button").addEventListener("click", () => {
  alert("Button clicked!");
});

The browser provided document, window, DOM APIs, etc. These only existed in browsers.

No Server Features

JavaScript had no way to:

• Read/write files on disk
• Connect to databases
• Listen for incoming network requests
• Run as a long-lived process

It was perfectly designed for browsers. Just not for servers.

How Node.js Changed Everything

The Breakthrough (2009)

Ryan Dahl created Node.js with a radical idea: take the JavaScript engine from Chrome and let it run on servers.

Instead of creating a new language or runtime, he reused existing JavaScript technology.

What Node.js Added

Node.js removed browser APIs and added server APIs:

// Browser (Node.js can't do this)
document.getElementById("button");  // No document
window.alert("Hi");                 // No window

// Server (Node.js can do this)
const fs = require("fs");           // Read files
const http = require("http");       // Create servers
const net = require("net");         // Network sockets

The JavaScript Runtime Difference

Browser Runtime (JavaScript)
├─ JavaScript language (same)
├─ DOM API (document, element)
├─ Window API (localStorage, fetch)
├─ Event system (click, scroll)
└─ Security sandbox (can't access disk)

Node.js Runtime (JavaScript)
├─ JavaScript language (same)
├─ File System (fs module)
├─ HTTP Server (http module)
├─ OS utilities (os, path modules)
└─ Full disk/network access

Same language. Different APIs.

Browser JS vs Server JS: The Analogy

Browser JavaScript

Think of browser JavaScript as a theater actor:

• Performs on stage (the browser window)
• Interacts with the audience (user clicks, scrolls)
• Props and scenery are provided (DOM, document)
• Can't leave the theater
• Limited to what the stage allows

// Browser: responding to user
button.addEventListener("click", () => {
  console.log("User clicked");
});

Server JavaScript (Node.js)

Think of server JavaScript as a factory manager:

• Runs operations behind the scenes
• Doesn't interact with users directly
• Controls machinery (databases, files, networks)
• Runs 24/7
• Manages resources and processes

// Server: listening for requests
server.listen(3000, () => {
  console.log("Server running");
});

Different roles. Same skill (JavaScript).

The V8 Engine: Under the Hood

What is V8?

V8 is Google's JavaScript engine. It's what makes JavaScript fast.

JavaScript vs Runtime

JavaScript (language)
  ↓
V8 Engine (converts to machine code)
  ↓
Computer (executes)

V8 takes JavaScript code and compiles it to machine code so computers can run it blazingly fast.

Why V8 Matters

Before V8 (early 2000s):

• JavaScript was interpreted line-by-line
• Slow

V8 (2008+):

• Compiles JavaScript to machine code
• ~1000x faster

Node.js uses V8, which is why JavaScript on servers can be performant.

You Don't Need to Know the Details

For this article, just remember:

Browser: runs V8 engine
Node.js: also runs V8 engine
Both execute the same JavaScript differently

The engine is the same. The environment is different.

Event-Driven Architecture

What is Event-Driven?

Instead of waiting for things to happen, Node.js listens for events and responds.

The Analogy

Synchronous (traditional servers):

A waiter takes your order, goes to the kitchen, waits for the food, comes back, goes to the next customer.

Event-Driven (Node.js):

A waiter takes your order, puts it in a queue, serves other customers, and comes back when your food is ready.

More efficient.

Example: Reading a File

Traditional approach (blocking):

// This makes the server WAIT
const data = fs.readFileSync("large-file.txt");
console.log(data);
// Server is blocked until file is read

Node.js approach (event-driven):

// This doesn't block the server
fs.readFile("large-file.txt", (err, data) => {
  console.log(data);
});
// Server continues handling other requests

Node.js doesn't wait. It does other things and comes back when the file is ready.

Why This Matters

One Node.js server can handle thousands of requests without blocking, because it doesn't wait for operations to finish.

Traditional Server (PHP/Java)
Request 1 → ⏳ waiting for database → Response
Request 2 → queued behind request 1
Request 3 → queued behind request 2

Node.js Server
Request 1 → database query (no wait)
Request 2 → database query (no wait)
Request 3 → database query (no wait)
Responses come back as each finishes

Much more efficient.

Node.js Runtime Architecture Overview

Node.js Runtime
  |
  ├─ V8 Engine
  |   └─ Executes JavaScript code
  |
  ├─ libuv (Library)
  |   ├─ Event loop
  |   ├─ Thread pool
  |   └─ Async I/O
  |
  ├─ Core Modules
  |   ├─ fs (files)
  |   ├─ http (server)
  |   ├─ os (system)
  |   └─ path (routing)
  |
  └─ npm (Package Manager)
      └─ Access to millions of libraries

The key: V8 executes your code, libuv handles async operations.

Real-World Use Cases of Node.js

1. Web Servers

const http = require("http");

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

server.listen(3000);

Build APIs and websites. Simple and fast.

2. Real-Time Applications

Companies like Slack, Discord, Trello use Node.js for real-time features.

// WebSocket: real-time communication
socket.on("message", (data) => {
  broadcast(data);  // Send to all users instantly
});

Event-driven architecture is perfect for real-time.

3. Building CLI Tools

Create command-line tools for developers:

// npm, ESLint, Webpack, Prettier are all Node.js tools
const args = process.argv;
console.log("Arguments:", args);

4. Data Processing & Streaming

Process large files without loading everything into memory:

const fs = require("fs");

fs.createReadStream("huge-file.csv")
  .pipe(processStream)
  .pipe(fs.createWriteStream("output.csv"));

Handle terabytes of data efficiently.

5. IoT & Embedded Systems

Node.js runs on Raspberry Pi and IoT devices.

// Read sensor data
const sensorData = getSensorReading();
sendToCloud(sensorData);

6. Building Microservices

Netflix, LinkedIn, and Uber use Node.js for microservices.

// Small, focused services
app.post("/users", createUser);
app.get("/users/:id", getUser);
app.delete("/users/:id", deleteUser);

Each service is independent. Easy to scale.

Node.js vs Traditional Backend Languages

JavaScript (Node.js)

Pros: One language for frontend and backend, event-driven and non-blocking, fast to write, perfect for real-time apps.

Cons: Single-threaded (traditionally), less suitable for CPU-intensive tasks.

PHP

Pros: Easy to learn, great for beginners.

Cons: Blocks per request (slower), no real-time support, poor for modern apps.

Java

Pros: Fast compiled language, mature ecosystem, good for enterprise.

Cons: Verbose and slow to write, requires more resources, steeper learning curve.

Python

Pros: Easy to read, great for AI and data science, large ecosystem.

Cons: Slow (interpreted), not ideal for real-time, multiple competing frameworks.

Node.js Sweet Spot

Real-Time Apps     ← Node.js wins
APIs & Servers     ← Node.js wins
CLI Tools          ← Node.js wins
Microservices      ← Node.js wins
Data Processing    ← Node.js strong

CPU-Intensive Work ← Java/Python better
Enterprise Systems ← Java better

Node.js excels at I/O-intensive applications (network, database, file operations). It's less ideal for CPU-intensive work (heavy calculations, image processing).

Why Developers Adopted Node.js

The Three Reasons

1. One Language Everywhere

// Frontend
const user = { name: "Alice" };
document.getElementById("name").textContent = user.name;

// Backend (same JavaScript!)
const user = { name: "Alice" };
res.json(user);

Frontend developers could now write backend code without learning Java or PHP.

2. Non-Blocking, Event-Driven

One Node.js server can handle more requests than one PHP server because it doesn't block on I/O operations.

3. Perfect for Modern Apps

• Real-time features (chat, notifications)
• Microservices architecture
• Mobile APIs
• WebSockets
• Streaming data

Node.js was designed for these use cases.

The Tipping Point (2012-2015)

npm grew. Libraries exploded. Companies started using Node.js in production.

Today, Node.js powers thousands of companies.

Browser JS vs Server JS: Execution Comparison

Browser Execution
  |
  ├─ User opens website
  ├─ Browser downloads HTML + JavaScript
  ├─ V8 engine parses JavaScript
  ├─ DOM is built
  ├─ User interacts (click, type)
  ├─ JavaScript responds to events
  └─ Page updates, render

Node.js Execution
  |
  ├─ Developer starts server
  ├─ Node.js loads JavaScript files
  ├─ V8 engine parses JavaScript
  ├─ Server starts listening for requests
  ├─ Client sends HTTP request
  ├─ JavaScript handles request
  ├─ Database query runs (non-blocking)
  ├─ Response is sent back
  └─ Server continues listening

Same engine (V8). Different triggers and APIs.

Simple Node.js Server Example

const http = require("http");

// Create server
const server = http.createServer((req, res) => {
  // req = incoming request
  // res = response to send
  
  if (req.url === "/") {
    res.writeHead(200);
    res.write("Welcome to Node.js!");
    res.end();
  } else if (req.url === "/about") {
    res.writeHead(200);
    res.write("This is the about page");
    res.end();
  } else {
    res.writeHead(404);
    res.write("Page not found");
    res.end();
  }
});

// Listen on port 3000
server.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

Run it:

node server.js
# Server running on http://localhost:3000

Visit http://localhost:3000 in your browser. You'll see "Welcome to Node.js!"

Key Differences Summarized

Practice Assignment

1. Understand the difference:

// Why does this work in Browser but NOT in Node.js?
document.getElementById("button");

// Why does this work in Node.js but NOT in Browser?
fs.readFileSync("/etc/passwd");

2. Create a simple server:

// Create an http server
// Listen on port 3000
// Respond with "Hello Node.js"
// Test with curl or browser

3. Explore the event-driven model:

// Use fs.readFile (async, non-blocking)
// Use a callback function
// Console.log the file contents
// Understand why it doesn't block

4. Build a multi-route server:

// Create routes for:
// GET / → "Home"
// GET /about → "About page"
// GET /users → "Users list"
// GET /404 → "Not found"
// Test each route

Quick Recap

• Node.js is a runtime that executes JavaScript outside the browser.
• JavaScript was browser-only because it was designed for user interactions and DOM manipulation.
• Node.js uses the same V8 engine as Chrome but with different APIs for server tasks.
• Runtime is the environment where code runs; programming language is the syntax.
• Node.js has no DOM, document, or window objects because it runs on servers, not browsers.
• V8 is Google's JavaScript engine that compiles JS to machine code.
• Node.js uses event-driven, non-blocking I/O to handle thousands of concurrent requests efficiently.
• libuv handles the event loop and async operations behind the scenes.
• Node.js excels at I/O-intensive applications: APIs, real-time apps, microservices, CLI tools.
• Node.js is not ideal for CPU-intensive work (use Python or Java instead).
• Browser JS responds to user events (clicks); Server JS responds to network events (requests).
• One language for frontend and backend is Node.js's killer feature.

Node.js turned JavaScript into a full-stack language.

If you enjoyed this article, check out my other blogs on this profile. Connect with me: LinkedIn | GitHub | X (Twitter)

This is about understanding JWT and building login systems without session databases.

What Authentication Means

Authentication answers: "Who are you?"

Real Example

Checking into a hotel: you show an ID once, and they don't check the guest list every time you walk in. The ID is your proof.

Apps work the same way.

Without Authentication

app.get("/profile", (req, res) => {
  res.json({ message: "Anyone can access this" });
});

No protection.

With Authentication

app.get("/profile", (req, res) => {
  if (!req.user) {
    return res.status(401).json({ error: "Not authenticated" });
  }
  res.json({ message: `Hello ${req.user.name}` });
});

Only authenticated users see it.

What JWT Is

JWT (JSON Web Token) is a token that represents a user's identity.

The Concept

1. User logs in
2. Server creates a token containing their info
3. Server sends the token
4. User sends the token with every request
5. Server verifies the token (no database needed)

The token itself proves who they are.

Simple Analogy

Concert wristband: instead of the venue checking a list every time you enter, you wear a wristband proving you're authorized. The wristband is the proof.

JWT is like that wristband for API requests.

JWT vs Sessions

Structure of a JWT

A JWT has three parts: header.payload.signature

Part 1: Header

{
  "alg": "HS256",    // Algorithm
  "typ": "JWT"       // Type
}

Base64 encoded: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Part 2: Payload

{
  "userId": 1,
  "email": "alice@example.com",
  "name": "Alice",
  "iat": 1234567890,    // Issued at
  "exp": 1234571490     // Expires at
}

Base64 encoded: eyJ1c2VySWQiOjEsImVtYWlsIjoiYWxpY2VAZXhhbXBsZS5jb20ifQ

Part 3: Signature

Server signs the header and payload:

HMACSHA256(
  base64(header) + "." + base64(payload),
  "secret-key"
)

Result: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Complete Token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjE...SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Three parts separated by dots.

Why the Signature Matters

It proves the token hasn't been tampered with:

Valid token: signature matches
Tampered token: signature doesn't match → rejected

JWT Token Structure Visualization

JWT Token
  |
  ├─ Header (base64)
  |   ├─ Algorithm: HS256
  |   └─ Type: JWT
  |
  ├─ Payload (base64)
  |   ├─ userId: 1
  |   ├─ email: alice@example.com
  |   ├─ name: Alice
  |   ├─ iat: 1234567890
  |   └─ exp: 1234571490
  |
  └─ Signature (HMAC)
      └─ Hash of header + payload with secret

The server can read the payload without a database because it's right there in the token.

Login Flow Using JWT

Step 1: User Logs In

app.post("/login", (req, res) => {
  const { email, password } = req.body;
  const user = users.find(u => u.email === email);
  
  if (!user || user.password !== password) {
    return res.status(401).json({ error: "Invalid credentials" });
  }
  
  // Credentials valid
  res.json({ message: "Login successful" });
});

Step 2: Server Creates JWT

const jwt = require("jsonwebtoken");
const SECRET = "your-secret-key";

app.post("/login", (req, res) => {
  const { email, password } = req.body;
  const user = users.find(u => u.email === email);
  
  if (!user || user.password !== password) {
    return res.status(401).json({ error: "Invalid credentials" });
  }
  
  // Create token
  const token = jwt.sign(
    { userId: user.id, email: user.email, name: user.name },
    SECRET,
    { expiresIn: "24h" }
  );
  
  res.json({ token });
});

Token contains user info and expires in 24 hours.

Step 3: Client Stores Token

// After login, client stores token
localStorage.setItem("token", token);

Step 4: Client Sends Token With Requests

// Every request includes the token
const token = localStorage.getItem("token");

fetch("http://localhost:3000/profile", {
  headers: {
    "Authorization": `Bearer ${token}`
  }
});

Step 5: Server Verifies Token

app.get("/profile", (req, res) => {
  const token = req.headers.authorization?.split(" ")[1];
  
  if (!token) {
    return res.status(401).json({ error: "No token" });
  }
  
  try {
    const decoded = jwt.verify(token, SECRET);
    res.json({ message: `Hello ${decoded.name}` });
  } catch (error) {
    res.status(401).json({ error: "Invalid token" });
  }
});

No database needed. The token proves who they are.

JWT Login Authentication Flow

User sends login request
(email + password)
      |
      v
Server finds user in database
      |
      v
Server checks password
      |
      ├─ Wrong: send error
      └─ Correct: continue
      |
      v
Server creates JWT token
(contains user info)
      |
      v
Server sends token to client
      |
      v
Client stores token
(localStorage, sessionStorage, etc)
      |
      v
User makes API request
(includes token in Authorization header)
      |
      v
Server verifies token signature
      |
      ├─ Invalid: reject (401)
      └─ Valid: continue
      |
      v
Request allowed, response sent

Sending Token With Requests

In HTTP Header (Standard)

// Client side
const token = localStorage.getItem("token");

fetch("http://localhost:3000/profile", {
  headers: {
    "Authorization": `Bearer ${token}`
  }
});

This is the standard approach.

In Cookie

Alternative (automatically sent):

// Server side
res.cookie("token", token, {
  httpOnly: true,
  secure: true,
  maxAge: 24 * 60 * 60 * 1000
});

In Query String

Not recommended (exposes token in logs):

fetch("http://localhost:3000/profile?token=" + token);

The header approach is best.

Protecting Routes Using Tokens

Token Verification Middleware

function verifyToken(req, res, next) {
  const token = req.headers.authorization?.split(" ")[1];
  
  if (!token) {
    return res.status(401).json({ error: "No token" });
  }
  
  try {
    const decoded = jwt.verify(token, SECRET);
    req.user = decoded;
    next();
  } catch (error) {
    res.status(401).json({ error: "Invalid token" });
  }
}

Apply to Routes

// Protected route
app.get("/profile", verifyToken, (req, res) => {
  res.json({ 
    message: `Hello ${req.user.name}`,
    user: req.user
  });
});

// Another protected route
app.get("/posts", verifyToken, (req, res) => {
  res.json({ posts: "User's posts" });
});

// Public route (no middleware)
app.get("/public", (req, res) => {
  res.json({ message: "Anyone can see this" });
});

The middleware checks the token before the handler runs.

Admin-Only Route

function requireAdmin(req, res, next) {
  if (req.user.role !== "admin") {
    return res.status(403).json({ error: "Admin only" });
  }
  next();
}

app.delete("/users/:id", verifyToken, requireAdmin, (req, res) => {
  res.json({ message: "User deleted" });
});

Complete Login Example

const express = require("express");
const jwt = require("jsonwebtoken");

const app = express();
app.use(express.json());

const SECRET = "your-secret-key";

// In-memory user store
const users = [
  { id: 1, email: "alice@example.com", password: "password123", name: "Alice" },
  { id: 2, email: "bob@example.com", password: "password456", name: "Bob" }
];

// Login endpoint
app.post("/login", (req, res) => {
  const { email, password } = req.body;
  
  // Find user
  const user = users.find(u => u.email === email);
  
  // Check password
  if (!user || user.password !== password) {
    return res.status(401).json({ error: "Invalid credentials" });
  }
  
  // Create token
  const token = jwt.sign(
    { userId: user.id, email: user.email, name: user.name },
    SECRET,
    { expiresIn: "24h" }
  );
  
  res.json({ token });
});

// Verify token middleware
function verifyToken(req, res, next) {
  const token = req.headers.authorization?.split(" ")[1];
  
  if (!token) {
    return res.status(401).json({ error: "No token" });
  }
  
  try {
    const decoded = jwt.verify(token, SECRET);
    req.user = decoded;
    next();
  } catch (error) {
    res.status(401).json({ error: "Invalid token" });
  }
}

// Protected route
app.get("/profile", verifyToken, (req, res) => {
  res.json({ message: `Hello ${req.user.name}`, user: req.user });
});

// Public route
app.get("/public", (req, res) => {
  res.json({ message: "Public data" });
});

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

Test It

# Login
curl -X POST http://localhost:3000/login \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com","password":"password123"}'

# Response: {"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

# Access protected route with token
curl http://localhost:3000/profile \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

# Response: {"message":"Hello Alice","user":{"userId":1,...}}

Practice Assignment

1. Create a login endpoint:

// Receive email and password
// Find user in array
// Create JWT if credentials valid
// Return token

2. Build token verification middleware:

// Extract token from Authorization header
// Verify signature with jwt.verify()
// Store decoded user in req.user
// Call next() if valid

3. Protect a route:

// Apply verifyToken middleware to a route
// Route should access req.user
// Test with curl including token

4. Handle token expiration:

// Set expiresIn to "1h"
// Try accessing route after expiration
// See "invalid token" error

Quick Recap

• Authentication proves who someone is.

• JWT is a token containing user info, signed by the server.

• JWT has three parts: header.payload.signature

• Header specifies the algorithm.

• Payload contains user data.

• Signature proves the token hasn't been tampered with.

• Login: receive credentials → verify → create token → send to client.

• Clients send the token in the Authorization header.

• Servers verify the token's signature, no database needed.

• Protect routes by checking the token before allowing access.

• JWT is stateless: the token proves who the user is.

JWT makes authentication simple and scalable.

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)

This is about how Express simplifies server building and lets you focus on routes and logic.

What Express.js Is

Express is a framework for building web servers in Node.js. It handles routing, middleware, and request/response management so you don't have to.

Without Express (Raw Node.js)

const http = require("http");

const server = http.createServer((req, res) => {
  if (req.method === "GET" && req.url === "/") {
    res.writeHead(200, { "Content-Type": "text/plain" });
    res.end("Home page");
  } else if (req.method === "GET" && req.url === "/about") {
    res.writeHead(200, { "Content-Type": "text/plain" });
    res.end("About page");
  } else {
    res.writeHead(404, { "Content-Type": "text/plain" });
    res.end("Not found");
  }
});

server.listen(3000);

Lots of boilerplate for just two routes.

With Express

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

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

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

app.listen(3000);

Same functionality, much cleaner.

Why Express Simplifies Node.js Development

1. Routing Is Built-In

Express makes routing straightforward:

app.get("/users", (req, res) => {
  // Handle GET /users
});

app.post("/users", (req, res) => {
  // Handle POST /users
});

app.delete("/users/:id", (req, res) => {
  // Handle DELETE /users/123
});

Raw Node.js requires manual URL parsing.

2. Request/Response Helpers

Express provides convenience methods:

res.json({ data: "value" });      // Send JSON
res.send("text response");        // Send text
res.status(404).send("Not found"); // Set status

Raw Node.js requires manual header management.

3. URL Parameters and Query Strings

Automatic parsing:

app.get("/users/:id", (req, res) => {
  const userId = req.params.id;  // From /users/123
});

app.get("/search", (req, res) => {
  const query = req.query.q;  // From /search?q=hello
});

Raw Node.js requires string parsing.

Creating Your First Express Server

Step 1: Install Express

npm install express

Step 2: Create the Server

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

// Your routes here

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

That's the minimal setup. Just a few lines.

Step 3: Add Routes

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

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

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000");
});

Now your server responds to GET requests at the root path.

Test It

node server.js
# Server running on http://localhost:3000

# In another terminal
curl http://localhost:3000
# Hello, World!

It works immediately.

Request → Route Handler → Response Flow

Browser sends request
  |
  v
Express receives request
  |
  v
Matches URL to a route
  |
  v
Route handler function called
  |
  ├─ req: request object (data from browser)
  └─ res: response object (send data back)
  |
  v
Handler uses res.send() or res.json()
  |
  v
Response sent back to browser
  |
  v
Browser displays it

Each request goes through this cycle.

Handling GET Requests

GET requests retrieve data. They're read-only.

Basic GET Route

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

Visiting the root URL triggers this handler.

GET With URL Parameters

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

// /users/5 → "User ID: 5"
// /users/123 → "User ID: 123"

The :id is a variable in the URL.

GET With Query Strings

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

// /search?q=javascript → "Searching for: javascript"

Query strings come after the ?.

Real Example: User Endpoint

const users = [
  { id: 1, name: "Alice" },
  { id: 2, name: "Bob" }
];

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

app.get("/users/:id", (req, res) => {
  const user = users.find(u => u.id == req.params.id);
  if (user) {
    res.json(user);
  } else {
    res.status(404).send("User not found");
  }
});

Requests:

• GET /users → all users
• GET /users/1 → user 1
• GET /users/999 → 404

Handling POST Requests

POST requests send data to the server.

Basic POST Route

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

A POST to /users triggers this handler.

POST With Data

Add middleware to parse the body:

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

app.use(express.json());

app.post("/users", (req, res) => {
  const name = req.body.name;
  res.json({ message: "User created", name });
});

Now req.body contains the request data.

Real Example: Creating a Resource

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

app.use(express.json());

let users = [{ id: 1, name: "Alice" }];

app.post("/users", (req, res) => {
  const newUser = {
    id: users.length + 1,
    name: req.body.name
  };
  users.push(newUser);
  res.status(201).json(newUser);
});

Test it:

curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name":"David"}'

# Response: {"id":2,"name":"David"}

Sending Responses

Express provides multiple ways to send responses back.

Plain Text

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

JSON

app.get("/json", (req, res) => {
  res.json({ message: "Hello", value: 42 });
});

HTML

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

With Status Code

app.post("/created", (req, res) => {
  res.status(201).json({ id: 1 });
});

app.get("/not-found", (req, res) => {
  res.status(404).send("Not found");
});

app.get("/error", (req, res) => {
  res.status(500).send("Server error");
});

Status codes tell the browser what happened:

• 200: OK
• 201: Created
• 404: Not found
• 500: Server error

Redirect

app.get("/old-page", (req, res) => {
  res.redirect("/new-page");
});

Complete Example: Simple API

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

app.use(express.json());

// In-memory data store
let posts = [
  { id: 1, title: "First Post", body: "Hello" },
  { id: 2, title: "Second Post", body: "World" }
];

// GET all posts
app.get("/posts", (req, res) => {
  res.json(posts);
});

// GET one post
app.get("/posts/:id", (req, res) => {
  const post = posts.find(p => p.id == req.params.id);
  if (post) {
    res.json(post);
  } else {
    res.status(404).json({ error: "Post not found" });
  }
});

// CREATE a post
app.post("/posts", (req, res) => {
  const newPost = {
    id: posts.length + 1,
    title: req.body.title,
    body: req.body.body
  };
  posts.push(newPost);
  res.status(201).json(newPost);
});

// UPDATE a post
app.put("/posts/:id", (req, res) => {
  const post = posts.find(p => p.id == req.params.id);
  if (post) {
    post.title = req.body.title || post.title;
    post.body = req.body.body || post.body;
    res.json(post);
  } else {
    res.status(404).json({ error: "Post not found" });
  }
});

// DELETE a post
app.delete("/posts/:id", (req, res) => {
  const index = posts.findIndex(p => p.id == req.params.id);
  if (index !== -1) {
    const deleted = posts.splice(index, 1);
    res.json(deleted[0]);
  } else {
    res.status(404).json({ error: "Post not found" });
  }
});

app.listen(3000, () => {
  console.log("API running on http://localhost:3000");
});

This API handles create, read, update, and delete operations.

Express Routing Structure

app
  |
  ├─ app.get("/path", handler)
  ├─ app.post("/path", handler)
  ├─ app.put("/path", handler)
  ├─ app.delete("/path", handler)
  |
  └─ app.listen(port)

Each route:
  path: URL to match
  handler: function to run
    req: incoming request
    res: outgoing response

Practice Assignment

1. Create a basic server:

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

// Create GET / endpoint that returns "Hello"
// Create GET /about endpoint that returns "About page"

app.listen(3000);

2. Handle URL parameters:

// Create GET /greet/:name that returns "Hello, {name}"
// Example: /greet/alice → "Hello, alice"

3. Handle POST requests:

// Parse JSON
// Create POST /data that receives { message: "..." }
// Return { received: message }

4. Build a simple resource API:

// Create an array of items
// GET /items → return all
// GET /items/:id → return one
// POST /items → create new
// DELETE /items/:id → delete one

Quick Recap

• Express is a framework for building web servers in Node.js.

• Routes are defined with app.get(), app.post(), app.put(), app.delete().

• URL parameters come from req.params.

• Query strings come from req.query.

• POST data comes from req.body (with express.json() middleware).

• Responses are sent with res.send(), res.json(), or res.status().

• Status codes indicate what happened (200, 201, 404, 500).

• Express removes boilerplate compared to raw Node.js.

• A single app.listen() starts the server.

• Routing in Express is simple and readable.

Express makes building web servers straightforward. Focus on routes and logic, not HTTP boilerplate.

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)

This is the core difference between JavaScript that feels fast and JavaScript that feels broken.

What Synchronous Code Means

Synchronous code runs line by line, in order. Each line waits for the previous one.

Simple Example

console.log("Line 1");
console.log("Line 2");
console.log("Line 3");

// Output:
// Line 1
// Line 2
// Line 3

One line, then the next. Straightforward.

With Operations

console.log("Start");
const sum = 5 + 3;
console.log("Sum:", sum);
console.log("Done");

// Output:
// Start
// Sum: 8
// Done

Each operation completes before moving on.

Real Example: Reading a File

const fs = require("fs");

console.log("Before");
const data = fs.readFileSync("data.txt", "utf8");
console.log("Data:", data);
console.log("After");

// Output:
// Before
// Data: (contents)
// After

readFileSync blocks. The program waits for the file.

What Asynchronous Code Means

Asynchronous code starts an operation but doesn't wait for it. It continues running and gets notified when the operation completes.

Simple Example

console.log("Start");

setTimeout(() => {
  console.log("After 2 seconds");
}, 2000);

console.log("End");

// Output:
// Start
// End
// (2 seconds pass)
// After 2 seconds

Notice: "End" prints before the timeout callback. JavaScript doesn't wait.

How It Works

Time →
|
Start: console.log("Start") → prints immediately
  |
  ├─ setTimeout called (doesn't wait)
  |  └─ callback scheduled for later
  |
  ├─ console.log("End") → prints immediately
  |
  └─ (user continues using app)
  |
  (2 seconds pass)
  |
  └─ Callback fires: console.log("After 2 seconds")
  |
Done

JavaScript continues running while waiting for the timer.

Real Example: API Request

console.log("Fetching data...");

fetch("https://api.example.com/users/1")
  .then(response => response.json())
  .then(user => console.log("User:", user));

console.log("Request sent");

// Output:
// Fetching data...
// Request sent
// (network request happens)
// User: { id: 1, name: "Alice" }

The fetch doesn't block. JavaScript continues to "Request sent" before the data arrives.

Synchronous Execution Timeline

START
  |
  v
Execute Line 1
  |
  v
Execute Line 2
  |
  v
Execute Line 3
  |
  v
Execute Line 4
  |
  v
END

Strict top-to-bottom order
Each line waits for the previous to finish

Asynchronous Task Queue Concept

START
  |
  v
Execute immediate code
  |
  ├─ Line 1: fetch("api")  → add to task queue
  |
  ├─ Line 2: console.log   → execute immediately
  |
  └─ Continue to END
  |
  v
QUEUE (waiting for data)
  |
  └─ fetch callback (waiting for response)
  |
  (when data arrives)
  |
  └─ Execute callback
  |
  v
END

Why JavaScript Needs Asynchronous Behavior

The Problem: Blocking Code

Without async, waiting for data freezes everything:

// Synchronous read from network (hypothetical)
const userData = synchronousNetworkRead("https://api.example.com/user/1");
// User can't do anything while waiting. App is frozen.

If the network takes 5 seconds, the entire app is frozen for 5 seconds. Users can't click, scroll, or interact.

The Solution: Asynchronous

// Asynchronous read from network
fetch("https://api.example.com/user/1")
  .then(response => response.json())
  .then(user => console.log("User:", user));

// User can still click, scroll, and interact
// App remains responsive

The fetch starts, but JavaScript keeps running. Users can interact while waiting.

Real-World Analogy

Synchronous (Restaurant): You order food. You stand at the counter and don't move until your food is ready. Everyone behind you waits. Nothing else happens.

Asynchronous (Pager): You order food. You get a pager. You sit down and can relax, order drinks, chat. When food is ready, the pager buzzes. You go get it. Everyone can use the line for their own orders.

JavaScript uses the pager model.

Examples: API Calls

Synchronous Approach (Hypothetical)

function getUserData(userId) {
  // This would freeze the app while waiting
  const user = synchronousAPICall(`/api/users/${userId}`);
  return user;
}

// User can't interact while waiting
const user = getUserData(1);
console.log("User:", user);

If the API takes 3 seconds, the app is frozen for 3 seconds.

Asynchronous Approach (Real)

function getUserData(userId) {
  return fetch(`/api/users/${userId}`)
    .then(response => response.json());
}

// App remains responsive
getUserData(1).then(user => {
  console.log("User:", user);
});

// This runs immediately, doesn't wait
console.log("Request started");

Output:

Request started
(network happens)
User: { id: 1, name: "Alice" }

The app stays responsive.

With Async/Await

async function getUserData(userId) {
  const response = await fetch(`/api/users/${userId}`);
  const user = await response.json();
  return user;
}

async function main() {
  const user = await getUserData(1);
  console.log("User:", user);
}

main();

Same thing, more readable. App stays responsive.

Examples: Timers

Synchronous Wait (Not Built-In)

JavaScript doesn't have a built-in synchronous wait, but you could simulate it:

function badWait(milliseconds) {
  const start = Date.now();
  while (Date.now() - start < milliseconds) {
    // Do nothing, just burn CPU
  }
}

console.log("Start");
badWait(3000);  // Block for 3 seconds
console.log("After 3 seconds");

This blocks everything. Users can't interact. CPU spins uselessly.

Asynchronous Wait (The Right Way)

console.log("Start");

setTimeout(() => {
  console.log("After 3 seconds");
}, 3000);

console.log("I run immediately");

// Output:
// Start
// I run immediately
// (3 seconds pass)
// After 3 seconds

The app stays responsive. Users can interact while waiting.

Real Scenario: Loading Multiple Files

Bad (Blocking):

const fs = require("fs");

console.log("Start");
const file1 = fs.readFileSync("file1.txt");  // Waits
const file2 = fs.readFileSync("file2.txt");  // Waits
const file3 = fs.readFileSync("file3.txt");  // Waits
console.log("Done");

// Synchronous reads = everything waits
// If each file takes 1 second, total = 3 seconds

Good (Non-Blocking):

const fs = require("fs").promises;

async function loadFiles() {
  console.log("Start");
  
  const [file1, file2, file3] = await Promise.all([
    fs.readFile("file1.txt"),
    fs.readFile("file2.txt"),
    fs.readFile("file3.txt")
  ]);
  
  console.log("Done");
}

loadFiles();

// Asynchronous reads = runs in parallel
// If each file takes 1 second, total = ~1 second
// App stays responsive the whole time

Same files, but async is faster and doesn't freeze the app.

Problems With Blocking Code

1. Frozen User Interface

Blocking code freezes the UI:

// Synchronous blocking code
function processLargeDataset() {
  let sum = 0;
  for (let i = 0; i < 1000000000; i++) {
    sum += i;
  }
  return sum;
}

// User clicks, types, hovers = nothing happens
const result = processLargeDataset();
console.log("Result:", result);

// Finally, UI responds after computation

During processLargeDataset(), the browser can't respond to clicks or updates.

2. Network Requests Block Everything

// Hypothetical blocking network code
function fetchUserBlocking(userId) {
  const user = blockingFetch(`/api/users/${userId}`);
  return user;
}

// This waits forever if network is slow
const user = fetchUserBlocking(1);

// Nothing else runs until the user data arrives

If the network is slow, everything is stuck.

3. Bad User Experience

// Blocking code
console.log("Saving data...");
const result = blockingSaveToDatabase(data);  // Waits
console.log("Data saved");

// User sees "Saving" for a long time
// Can't do anything else
// Feels slow and broken

4. Performance Issues

// Blocking: Load 3 files one at a time
// File 1: 1 second
// File 2: 1 second
// File 3: 1 second
// Total: 3 seconds

// Non-blocking: Load 3 files in parallel
// File 1, 2, 3: 1 second each (at the same time)
// Total: ~1 second

// Same files, 3x faster with async

Blocking code is slow because operations can't overlap.

5. No Responsiveness While Waiting

// Blocking: App is stuck
while (waitingForData) {
  // Nothing
}

// Non-blocking: App keeps running
fetch(url).then(data => {
  // Handle when ready
});

// User can scroll, click, interact while waiting

The JavaScript Event Loop

JavaScript handles async operations using an event loop:

Call Stack (immediate code)
  |
  ├─ Execute synchronous code here
  └─ When done, check Task Queue

Task Queue (async callbacks)
  |
  ├─ setTimeout callbacks waiting
  ├─ Promise callbacks waiting
  ├─ Fetch callbacks waiting
  └─ When stack is empty, run next task

Event Loop
  |
  └─ Continuously checks: if stack empty and queue has tasks?
       └─ Move task from queue to stack

Example:

console.log("1");

setTimeout(() => {
  console.log("2");
}, 0);

console.log("3");

// Output:
// 1
// 3
// 2

// Why?
// 1. "1" runs immediately (stack)
// 2. setTimeout scheduled (goes to queue)
// 3. "3" runs immediately (stack)
// 4. Stack empty, event loop checks queue
// 5. "2" runs from queue

Practice Assignment

1. Spot the blocking code:

// Is this blocking or non-blocking?
const data = readFileSync("data.txt");

// Answer: Blocking. App freezes while reading.

2. Convert blocking to non-blocking:

// Blocking version
const file1 = readFileSync("file1.txt");
const file2 = readFileSync("file2.txt");

// Convert to async

3. Understand the order:

console.log("A");
setTimeout(() => console.log("B"), 0);
console.log("C");

// What order does it print? Why?

4. Build a responsive app:

// Fetch data but keep UI responsive
// Show loading state while fetching
// Update UI when data arrives

Quick Recap

• Synchronous code runs line by line, each line waits for the previous.

• Asynchronous code starts operations but doesn't wait for them.

• JavaScript uses the event loop to handle async operations.

• Blocking code freezes the UI and makes apps feel slow.

• Non-blocking code keeps the UI responsive.

• Network requests, timers, and file operations should be async.

• Synchronous file reads (readFileSync) block the entire app.

• Asynchronous file reads keep everything responsive.

• setTimeout, fetch, and promises are async.

• async/await makes async code easier to read.

• The task queue holds async callbacks until the call stack is empty.

Master the difference between synchronous and asynchronous, and you'll write JavaScript that feels fast and responsive.

Happy coding! 🚀

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)

Promises fixed callback hell. But chaining many .then() calls still looks messy. Async/await lets you write asynchronous code that reads like normal code.

If promises made async bearable, async/await made it obvious.

Why Async/Await Was Introduced

Promises solved callback hell, but promise chains can be hard to follow.

The Promise Chain Problem

function fetchUserData(userId) {
  return fetch(`/api/users/${userId}`)
    .then(response => response.json())
    .then(user => {
      return fetch(`/api/posts/${user.id}`)
        .then(response => response.json())
        .then(posts => ({ user, posts }));
    });
}

It works, but reading it requires jumping between .then() blocks.

The Async/Await Solution

async function fetchUserData(userId) {
  const response = await fetch(`/api/users/${userId}`);
  const user = await response.json();
  
  const postsResponse = await fetch(`/api/posts/${user.id}`);
  const posts = await postsResponse.json();
  
  return { user, posts };
}

Same logic, reads top to bottom like normal code.

Why It Matters

• Easier to understand
• Variables are in scope where you use them
• Error handling with try/catch instead of .catch()
• Feels like synchronous code

How Async Functions Work

An async function automatically returns a promise.

Basic Example

async function myFunction() {
  return "Hello";
}

myFunction().then(result => console.log(result));
// Output: Hello

Even though you return a string, the function returns a promise.

What Gets Returned

async function getNumber() {
  return 42;
}

const result = getNumber();
console.log(result);  // Promise { <pending> }

result.then(num => console.log(num));  // 42

Every async function returns a promise.

Two Ways to Call Async Functions

Option 1: With .then()

async function getMessage() {
  return "Hello!";
}

getMessage().then(msg => console.log(msg));

Option 2: With await (inside another async function)

async function main() {
  const msg = await getMessage();
  console.log(msg);
}

main();

Simple Async Example

async function processData() {
  const response = await fetch("/api/data");
  const data = await response.json();
  const processed = data.map(item => item * 2);
  return processed;
}

processData().then(result => console.log(result));

Each await pauses until the promise resolves.

The Await Keyword

The await keyword pauses execution until a promise resolves.

Basic Example

async function example() {
  console.log("Start");
  const result = await fetch("/api/data");
  console.log("End");
}

// Output:
// Start
// (waits for fetch)
// End

The function pauses at await and waits for the promise.

Multiple Awaits

async function loadUserPosts(userId) {
  const userResponse = await fetch(`/api/users/${userId}`);
  const user = await userResponse.json();
  
  const postsResponse = await fetch(`/api/posts/${user.id}`);
  const posts = await postsResponse.json();
  
  return { user, posts };
}

Each line waits for the previous one to finish.

Await Only Works in Async Functions

// Wrong: This doesn't work
function notAsync() {
  const data = await fetch("/api/data");  // SyntaxError
}

// Right: This works
async function isAsync() {
  const data = await fetch("/api/data");  // OK
}

You can only use await inside async functions.

Parallel Operations With Promise.all()

If operations don't depend on each other, run them together:

async function loadBoth() {
  const [user, posts] = await Promise.all([
    fetch("/api/users/1").then(r => r.json()),
    fetch("/api/posts/1").then(r => r.json())
  ]);
  
  return { user, posts };
}

This is faster than waiting for one, then the other.

Error Handling With Async Code

Use try/catch blocks with async/await.

Basic Try/Catch

async function fetchUser(userId) {
  try {
    const response = await fetch(`/api/users/${userId}`);
    const user = await response.json();
    return user;
  } catch (error) {
    console.log("Error:", error.message);
  }
}

fetchUser(1);

If any await fails, catch handles it.

Error Object Details

async function operation() {
  try {
    const result = await riskyFunction();
    console.log("Success:", result);
  } catch (error) {
    console.log("Message:", error.message);
    console.log("Type:", error.name);
    console.log("Stack:", error.stack);
  }
}

The error object has all the details.

Finally Block

async function processFile(filename) {
  let file;
  
  try {
    file = await openFile(filename);
    const content = await file.read();
    console.log("Content:", content);
  } catch (error) {
    console.log("Error:", error.message);
  } finally {
    if (file) {
      await file.close();  // Always close
    }
  }
}

The finally block always runs.

Handle Different Errors

async function complexOp() {
  try {
    const user = await getUser();
    const posts = await getPosts(user.id);
    return { user, posts };
  } catch (error) {
    if (error.message.includes("User not found")) {
      console.log("No user");
    } else if (error.message.includes("Network")) {
      console.log("Network problem");
    } else {
      console.log("Other error:", error);
    }
  }
}

Promise vs Async/Await

Both work the same way. Async/await is just cleaner syntax.

Side-by-Side Comparison

With Promises:

function getUser(userId) {
  return fetch(`/api/users/${userId}`)
    .then(response => response.json())
    .then(user => {
      console.log("User:", user);
      return user;
    })
    .catch(error => console.log("Error:", error));
}

With Async/Await:

async function getUser(userId) {
  try {
    const response = await fetch(`/api/users/${userId}`);
    const user = await response.json();
    console.log("User:", user);
    return user;
  } catch (error) {
    console.log("Error:", error);
  }
}

Async/await reads more naturally.

Readability Difference

Promises:

.then(...)
.then(...)
.then(...)
.catch(...)

Requires jumping between blocks

Async/Await:

await operation1
await operation2
await operation3
try/catch

Reads top to bottom

They're Compatible

You can use .then() with async/await:

async function loadData() {
  const response = await fetch("/api/data");
  return response.json();
}

// Still use .then()
loadData().then(data => console.log(data));

// Or await it
const data = await loadData();

Async/await doesn't replace promises. It's built on them.

Converting Promises to Async/Await

Example: Fetch Multiple Resources

Promise Version:

function loadUserWithPosts(userId) {
  let userData;
  
  return fetch(`/api/users/${userId}`)
    .then(response => response.json())
    .then(user => {
      userData = user;
      return fetch(`/api/posts/${user.id}`);
    })
    .then(response => response.json())
    .then(posts => {
      return { user: userData, posts };
    })
    .catch(error => {
      console.log("Error:", error);
      return null;
    });
}

Async/Await Version:

async function loadUserWithPosts(userId) {
  try {
    const userResponse = await fetch(`/api/users/${userId}`);
    const user = await userResponse.json();
    
    const postsResponse = await fetch(`/api/posts/${user.id}`);
    const posts = await postsResponse.json();
    
    return { user, posts };
  } catch (error) {
    console.log("Error:", error);
    return null;
  }
}

Much clearer. No temporary variables or nested callbacks.

Async Function Execution Flow

START
  |
  v
Enter async function
  |
  v
Execute line by line
  |
  ├─ await expression → pause
  |     |
  |     └─ wait for promise
  |           |
  |           └─ resolve
  |
  ├─ Continue
  |
  └─ await expression → pause
        |
        └─ wait for promise
              |
              └─ resolve
  |
  v
Return value (wrapped in promise)
  |
  v
END

Each await pauses execution. When the promise resolves, execution continues.

Real-World Example: API Call with Data Processing

async function fetchAndProcessUserData(userId) {
  try {
    // Fetch user
    console.log(`Fetching user ${userId}...`);
    const userResponse = await fetch(`/api/users/${userId}`);
    
    if (!userResponse.ok) {
      throw new Error(`HTTP error! status: ${userResponse.status}`);
    }
    
    const user = await userResponse.json();
    
    // Fetch posts
    console.log(`Fetching posts for ${user.name}...`);
    const postsResponse = await fetch(`/api/posts?userId=${user.id}`);
    const posts = await postsResponse.json();
    
    // Process data
    const result = {
      user: user.name,
      email: user.email,
      postCount: posts.length,
      recentPost: posts[0]?.title
    };
    
    console.log("Processing complete");
    return result;
    
  } catch (error) {
    console.error("Failed to fetch data:", error.message);
    return null;
    
  } finally {
    console.log("Operation finished");
  }
}

// Call it
fetchAndProcessUserData(1)
  .then(result => console.log("Result:", result))
  .catch(err => console.log("Outer error:", err));

Clean, readable, and easy to follow.

Practice Assignment

1. Convert a promise chain to async/await:

// Promise version
function getDataAndProcess() {
  return fetch("/api/data")
    .then(r => r.json())
    .then(data => processData(data))
    .catch(err => console.log(err));
}

// Convert to async/await

2. Handle errors with try/catch:

async function fetchMultiple() {
  // Fetch from /api/users and /api/posts
  // Handle any errors that occur
  // Log success and errors
}

3. Use parallel requests:

async function loadDashboard() {
  // Fetch users, posts, and comments at the same time
  // Use Promise.all() for parallel requests
  // Return all data combined
}

4. Chain dependent operations:

async function getUserPostComments(userId) {
  // Get user
  // Get user's posts
  // Get comments on first post
  // Return everything together
}

Quick Recap

• Async/await is syntactic sugar for promises.

• async functions always return a promise.

• await pauses execution until a promise resolves.

• await only works inside async functions.

• Use try/catch for error handling.

• finally block always runs.

• Async/await is easier to read than promise chains.

• Use Promise.all() to run operations in parallel.

• Variables are in scope where you use them.

• .then() and async/await can be mixed.

• Async/await code reads like synchronous code.

Async/await makes promises easier to work with. Learn both and you'll truly understand JavaScript's async model.

Happy coding! 🚀

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)

Code breaks. Users do unexpected things. Networks fail. Without error handling, your app crashes. With it, you handle problems gracefully and stay in control.

Error handling isn't about preventing all mistakes. It's about deciding what to do when they happen.

What Errors Are in JavaScript

An error is when something goes wrong while code runs. JavaScript throws an error and stops.

Common Error Types

Reference Error — Using a variable that doesn't exist:

console.log(someVariable);
// ReferenceError: someVariable is not defined

Type Error — Calling a method on the wrong type:

let number = 42;
number.toUpperCase();
// TypeError: number.toUpperCase is not a function

Range Error — Value outside acceptable range:

new Array(-1);
// RangeError: Invalid array length

Without Error Handling

function loadFile(filename) {
  const data = JSON.parse(fs.readFileSync(filename, "utf8"));
  return data;
}

loadFile("missing.json");
// Error: file not found
// App crashes. User sees nothing.

With Error Handling

function loadFile(filename) {
  try {
    const data = JSON.parse(fs.readFileSync(filename, "utf8"));
    return data;
  } catch (error) {
    return { default: true };
  }
}

loadFile("missing.json");
// Returns: { default: true }
// App keeps running.

Using Try and Catch Blocks

The try block has code that might fail. The catch block handles it if it does.

Basic Structure

try {
  // Code that might throw an error
  riskyOperation();
} catch (error) {
  // Handle the error
  console.log("Something went wrong:", error.message);
}

Real Example: Parsing JSON

let jsonString = '{ "name": "Alice" }';

try {
  let data = JSON.parse(jsonString);
  console.log("Parsed successfully:", data);
} catch (error) {
  console.log("Invalid JSON:", error.message);
}

If it's valid JSON, it parses. If not, catch handles it.

With Broken JSON

let jsonString = '{ "name": "Alice"';  // Missing closing brace

try {
  let data = JSON.parse(jsonString);
  console.log("Parsed:", data);
} catch (error) {
  console.log("Invalid JSON:", error.message);
  // Output: Invalid JSON: Unexpected end of JSON input
}

The error happens in try. Instead of crashing, catch handles it.

The Error Object

The error object has useful properties:

try {
  nonexistentFunction();
} catch (error) {
  console.log(error.message);  // The message
  console.log(error.name);     // Error type
  console.log(error.stack);    // Full trace
}

Multiple Operations

try {
  const data = fs.readFileSync("data.json", "utf8");
  const parsed = JSON.parse(data);
  processData(parsed);
} catch (error) {
  console.log("Error:", error.message);
}

If any operation fails, catch handles it.

The Finally Block

The finally block always runs, no matter what. Success or failure, it executes.

Structure

try {
  // Code that might fail
} catch (error) {
  // Handle the error
} finally {
  // Always runs
}

Real Example: Close a Database

const db = openDatabase("app.db");

try {
  const user = db.query("SELECT * FROM users WHERE id = 1");
  console.log("User found:", user);
} catch (error) {
  console.log("Query failed:", error.message);
} finally {
  db.close();  // Always close, success or failure
}

The database closes whether the query works or fails.

Execution Order

try block runs
  |
  ├─ Success → skip catch → go to finally
  └─ Failure → catch runs → then finally

finally always runs last

Resource Cleanup

function processFile(filename) {
  let file;
  
  try {
    file = openFile(filename);
    const content = file.read();
    console.log("File processed");
  } catch (error) {
    console.log("Error:", error.message);
  } finally {
    if (file) {
      file.close();  // Clean up
    }
  }
}

The file closes whether processing succeeds or fails.

Try → Catch → Finally Execution Flow

START
  |
  v
TRY BLOCK
  |
  ├─── No error
  |      |
  |      v
  |    Code runs successfully
  |      |
  |      v
  |    SKIP catch block
  |      |
  └──────┤
  |      |
  ├─── Error occurs
  |      |
  |      v
  |    Jump to CATCH block
  |      |
  |      v
  |    Handle error
  |      |
  └──────┤
  |      |
  v      v
FINALLY BLOCK (always runs)
  |
  v
END

Throwing Custom Errors

When something is wrong with your logic, create your own error.

Throw Statement

function validateAge(age) {
  if (age < 0) {
    throw new Error("Age cannot be negative");
  }
  return age;
}

try {
  validateAge(-5);
} catch (error) {
  console.log("Validation failed:", error.message);
  // Output: Validation failed: Age cannot be negative
}

Error Types You Can Throw

throw new Error("Something went wrong");
throw new TypeError("Expected a number");
throw new RangeError("Value out of range");
throw "Quick error message";

Custom Error Classes

class ValidationError extends Error {
  constructor(message) {
    super(message);
    this.name = "ValidationError";
  }
}

function validateEmail(email) {
  if (!email.includes("@")) {
    throw new ValidationError("Invalid email");
  }
  return email;
}

try {
  validateEmail("notanemail");
} catch (error) {
  if (error instanceof ValidationError) {
    console.log("Email error:", error.message);
  }
}

When to Throw

function divideNumbers(a, b) {
  if (typeof a !== "number" || typeof b !== "number") {
    throw new TypeError("Both must be numbers");
  }
  
  if (b === 0) {
    throw new Error("Cannot divide by zero");
  }
  
  return a / b;
}

try {
  divideNumbers(10, 2);   // Works: 5
  divideNumbers(10, 0);   // Throws error
} catch (error) {
  console.log("Math error:", error.message);
}

Why Error Handling Matters

1. Graceful Failure

Without error handling, your app crashes:

// Crashes if database fails
app.get("/user/:id", (req, res) => {
  const user = db.findUser(req.params.id);
  res.json(user);
});

// Handles the error gracefully
app.get("/user/:id", (req, res) => {
  try {
    const user = db.findUser(req.params.id);
    res.json(user);
  } catch (error) {
    res.status(500).json({ error: "User not found" });
  }
});

User gets a message instead of a blank screen.

2. Better Debugging

Error objects show you where the problem is:

try {
  riskyFunction();
} catch (error) {
  console.log(error.stack);
  // Shows file, line number, and function names
  // Helps you find bugs fast
}

3. Resource Cleanup

With finally, resources always get cleaned up:

let connection;

try {
  connection = openConnection();
} catch (error) {
  console.log("Error:", error.message);
} finally {
  if (connection) {
    connection.close();  // Don't leak resources
  }
}

Without finally, connections stay open if an error happens.

4. Better User Experience

Handle errors cleanly:

function saveData(data) {
  try {
    validateData(data);
    db.save(data);
    return { success: true };
  } catch (error) {
    return { 
      success: false, 
      message: "Could not save. Please try again." 
    };
  }
}

Users see a clear message, not a crash.

Real-World Example: Parsing User Input

function processUserInput(jsonString) {
  try {
    // Parse the JSON
    const data = JSON.parse(jsonString);
    
    // Validate the data
    if (!data.name || !data.email) {
      throw new Error("Missing required fields");
    }
    
    // Process the data
    const result = {
      name: data.name.trim(),
      email: data.email.toLowerCase()
    };
    
    console.log("Processing successful:", result);
    return result;
    
  } catch (error) {
    if (error instanceof SyntaxError) {
      console.log("Invalid JSON format:", error.message);
    } else if (error.message.includes("required")) {
      console.log("Validation error:", error.message);
    } else {
      console.log("Unexpected error:", error.message);
    }
    
    return null;
    
  } finally {
    console.log("Processing complete");
  }
}

// Test it
processUserInput('{ "name": "Alice", "email": "alice@example.com" }');
// Output: Processing successful: { name: 'Alice', email: 'alice@example.com' }
//         Processing complete

processUserInput('invalid json');
// Output: Invalid JSON format: Unexpected token i...
//         Processing complete

processUserInput('{ "name": "Bob" }');
// Output: Validation error: Missing required fields
//         Processing complete

Each scenario is handled appropriately.

Error Handling Patterns

Pattern 1: Try-Catch-Finally

try {
  // Do something
} catch (error) {
  // Handle error
} finally {
  // Cleanup
}

Pattern 2: Catch and Rethrow

try {
  database.query("SELECT * FROM users");
} catch (error) {
  console.log("Database error:", error);
  throw error;  // Pass it up to the caller
}

Pattern 3: Catch and Return Default

function getConfig() {
  try {
    return loadConfig();
  } catch (error) {
    return defaultConfig;  // Use defaults if load fails
  }
}

Pattern 4: Catch Specific Errors

try {
  operation();
} catch (error) {
  if (error instanceof TypeError) {
    console.log("Type error:", error.message);
  } else if (error instanceof RangeError) {
    console.log("Range error:", error.message);
  } else {
    console.log("Unknown error:", error.message);
  }
}

Practice Assignment

1. Parse JSON safely:

const jsonString = '{ "name": "Alice", "age": 25 }';

// Write a function that parses the JSON
// If parsing fails, return a default object

2. Handle multiple errors:

function divideAndLog(a, b) {
  try {
    // Check if both are numbers
    // Check if b is not zero
    // Divide and log result
  } catch (error) {
    // Handle the error
  }
}

3. Create a custom error:

// Create a PasswordError class
// Throw it if password is too short
// Catch it and show a message

4. Use finally for cleanup:

let file = null;

try {
  file = openFile("data.txt");
  // Read and process the file
} catch (error) {
  // Handle error
} finally {
  // Make sure file closes
}

Quick Recap

• Errors happen when code breaks. JavaScript throws and stops.

• Try block contains code that might fail.

• Catch block handles errors if they happen.

• Finally block always runs, success or failure.

• Throw keyword creates your own errors.

• Error objects have .message, .stack, and .name.

• Error handling lets you fail gracefully instead of crashing.

• Use finally to clean up resources.

• Catch specific error types for different handling.

• Error messages help you debug faster.

• Good error handling improves user experience.

Error handling isn't optional. It's how you control what happens when things go wrong.

Happy coding! 🚀

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)

This is about what spread and rest do, how they differ, and when to use each one.

Understanding the Three Dots

The ... syntax appears in two different contexts:

Spread:  Takes many elements and spreads them out
Rest:    Takes many values and collects them together

The syntax is the same. The context is different. That's what matters.

What the Spread Operator Does

The spread operator takes an iterable (array, string, or object) and expands it in-place.

Expanding an Array

const arr = [1, 2, 3];

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

Without spread: The array is printed as an array.

With spread: The elements are printed individually.

Spread Unpacks Values

Without spread:  [1, 2, 3]
                 One array

With spread:     1, 2, 3
                 Three separate values

Real Example: Function Arguments

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

const numbers = [1, 2, 3];

// Without spread
add(numbers[0], numbers[1], numbers[2]);  // 6 (clunky)

// With spread
add(...numbers);  // 6 (clean)

Spread takes [1, 2, 3] and expands it to 1, 2, 3. Then those values are passed as separate arguments.

Spread with Math Functions

const numbers = [5, 6, 2, 8, 1];

// Find max without spread
Math.max(numbers[0], numbers[1], numbers[2], numbers[3], numbers[4]); // 8

// With spread
Math.max(...numbers); // 8

Math.max() expects individual arguments, not an array. Spread converts the array to individual arguments.

Spreading Strings

Strings are iterable. You can spread them:

const str = "hello";

console.log(...str);  // h e l l o

const arr = [...str];
console.log(arr);     // ["h", "e", "l", "l", "o"]

Spread expands the string into individual characters.

What the Rest Operator Does

The rest operator collects multiple values into a single array.

Collecting Function Arguments

function sum(...numbers) {
  console.log(numbers);  // An array of all arguments
  let total = 0;
  for (let num of numbers) {
    total += num;
  }
  return total;
}

sum(1, 2, 3);        // numbers = [1, 2, 3]
sum(1, 2, 3, 4, 5);  // numbers = [1, 2, 3, 4, 5]

Rest collects all arguments into a single array numbers.

Rest Collects Values

Without rest:  function (a, b, c) { }
               Can only accept 3 arguments

With rest:     function (...args) { }
               Can accept any number of arguments

Rest with Regular Parameters

function greet(greeting, ...names) {
  console.log(greeting);  // Single value
  console.log(names);     // Array of remaining values
}

greet("Hello", "Alice", "Bob", "Charlie");

// Output:
// "Hello"
// ["Alice", "Bob", "Charlie"]

The first argument goes to greeting. The rest go into the names array.

Rest in Array Destructuring

const arr = [1, 2, 3, 4, 5];

const [first, second, ...rest] = arr;

console.log(first);   // 1
console.log(second);  // 2
console.log(rest);    // [3, 4, 5]

The first two elements are assigned individually. The rest are collected into an array.

Rest in Object Destructuring

const person = {
  name: "John",
  age: 30,
  city: "New York",
  country: "USA"
};

const { name, age, ...location } = person;

console.log(name);      // "John"
console.log(age);       // 30
console.log(location);  // { city: "New York", country: "USA" }

Named properties are extracted. The rest are collected into a new object.

Spread vs Rest: Key Differences

Context Matters

Visual Comparison

SPREAD (Unpacking)
[1, 2, 3]
   ↓
1, 2, 3

REST (Collecting)
1, 2, 3
   ↓
[1, 2, 3]

Spread goes outward. Rest goes inward.

Position Matters

Spread can appear anywhere in an expression:

const a = [1, 2];
const b = [3, 4];

const combined = [0, ...a, ...b, 5];
console.log(combined);  // [0, 1, 2, 3, 4, 5]

Rest can only be the last parameter:

function test(...rest, param) { }  // ERROR
function test(param, ...rest) { }  // CORRECT

Rest must come last because it collects everything remaining.

Using Spread with Arrays

Copy an Array

const original = [1, 2, 3];

// Shallow copy
const copy = [...original];

console.log(copy);           // [1, 2, 3]
console.log(copy === original); // false (different arrays)

Spread creates a new array with the same elements.

Combine Arrays

const arr1 = [1, 2];
const arr2 = [3, 4];

const combined = [...arr1, ...arr2];
console.log(combined);  // [1, 2, 3, 4]

Spread expands both arrays into a new one.

Insert Elements

const arr = [1, 2, 5];

// Insert 3 and 4 between 2 and 5
const result = [1, 2, 3, 4, 5];

// Or do it with spread
const start = [1, 2];
const end = [5];
const final = [...start, 3, 4, ...end];
console.log(final);  // [1, 2, 3, 4, 5]

Remove Duplicates

const arr = [1, 2, 2, 3, 3, 3, 4];

// Using Set (removes duplicates)
const unique = [...new Set(arr)];
console.log(unique);  // [1, 2, 3, 4]

Spread converts the Set back to an array.

Reverse an Array

const arr = [1, 2, 3];

// Using spread with reverse
const reversed = [...arr].reverse();
console.log(arr);        // [1, 2, 3] (original unchanged)
console.log(reversed);   // [3, 2, 1] (new reversed array)

Spread creates a copy first, so the original isn't modified.

Using Spread with Objects

Copy an Object

const original = { name: "John", age: 30 };

// Shallow copy
const copy = { ...original };

console.log(copy);              // { name: "John", age: 30 }
console.log(copy === original); // false (different objects)

Spread creates a new object with the same properties.

Merge Objects

const obj1 = { name: "John", age: 30 };
const obj2 = { city: "New York", country: "USA" };

const merged = { ...obj1, ...obj2 };
console.log(merged);
// { name: "John", age: 30, city: "New York", country: "USA" }

Spread expands both objects into one.

Override Properties

const defaults = { theme: "light", language: "en" };
const userSettings = { theme: "dark" };

const settings = { ...defaults, ...userSettings };
console.log(settings);
// { theme: "dark", language: "en" }

Properties from userSettings override defaults because they come later.

Add New Properties

const user = { name: "John", age: 30 };

const updated = {
  ...user,
  age: 31,
  email: "john@example.com"
};

console.log(updated);
// { name: "John", age: 31, email: "john@example.com" }

Spread the original, then add or override properties.

Exclude Properties

const user = { name: "John", age: 30, password: "secret" };

// Remove password
const { password, ...publicUser } = user;

console.log(publicUser);
// { name: "John", age: 30 }

Rest collects everything except the excluded property.

Practical Use Cases

Use Case 1: Flexible Function Arguments

// Without rest - limited to exact arguments
function oldSum(a, b, c) {
  return a + b + c;
}

oldSum(1, 2, 3);       // 6
oldSum(1, 2, 3, 4);    // 10 (4 ignored)

// With rest - any number of arguments
function newSum(...numbers) {
  return numbers.reduce((sum, n) => sum + n, 0);
}

newSum(1, 2, 3);       // 6
newSum(1, 2, 3, 4);    // 10
newSum(1, 2, 3, 4, 5); // 15

Use Case 2: Cloning Data

const original = { id: 1, name: "Product", price: 99.99 };

// Create a copy to modify
const edited = { ...original, price: 79.99 };

console.log(original); // { id: 1, name: "Product", price: 99.99 }
console.log(edited);   // { id: 1, name: "Product", price: 79.99 }

The original remains unchanged.

Use Case 3: Passing Arguments

function greet(greeting, name, punctuation) {
  return greeting + " " + name + punctuation;
}

const args = ["Hello", "Alice", "!"];

// Without spread
greet(args[0], args[1], args[2]);  // "Hello Alice!"

// With spread
greet(...args);  // "Hello Alice!"

Spread converts the array to function arguments.

Use Case 4: State Management (React-style)

// Update a single property in state
const state = { user: "John", count: 5, loading: false };

const newState = {
  ...state,
  count: state.count + 1
};

console.log(state);    // { user: "John", count: 5, loading: false }
console.log(newState); // { user: "John", count: 6, loading: false }

Create a new object with one property changed.

Use Case 5: API Response Handling

const apiResponse = {
  status: 200,
  data: { id: 1, name: "John" },
  timestamp: "2026-05-04"
};

// Extract just the data
const { status, timestamp, ...userData } = apiResponse;

console.log(userData);  // { id: 1, name: "John" }

Rest extracts the important data.

Use Case 6: Building Arrays Dynamically

const baseItems = ["apple", "banana"];
const newItems = ["orange"];
const userItems = ["grape"];

const groceryList = [
  "store items:",
  ...baseItems,
  ...newItems,
  ...userItems
];

console.log(groceryList);
// ["store items:", "apple", "banana", "orange", "grape"]

Spread combines multiple arrays cleanly.

Use Case 7: Default Parameters with Objects

const defaultConfig = {
  timeout: 5000,
  retries: 3,
  verbose: false
};

function makeRequest(url, config = {}) {
  const finalConfig = { ...defaultConfig, ...config };
  return finalConfig;
}

makeRequest("https://api.example.com");
// { timeout: 5000, retries: 3, verbose: false }

makeRequest("https://api.example.com", { timeout: 10000 });
// { timeout: 10000, retries: 3, verbose: false }

Merge user config with defaults.

Use Case 8: Filtering with Rest

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

const [first, ...rest] = numbers;
const even = rest.filter(n => n % 2 === 0);

console.log(even);  // [2, 4]

Extract and process remaining elements.

Spread and Rest Diagrams

Spread: Expanding Elements

Array: [1, 2, 3]
    ↓
Spread: ...arr
    ↓
Expanded: 1, 2, 3
    ↓
Used in: Function calls, array literals, object literals

Rest: Collecting Values

Values: 1, 2, 3, 4, 5
    ↓
Rest: ...rest
    ↓
Collected: [1, 2, 3, 4, 5]
    ↓
Stored in: Array parameter, destructuring

Visual Comparison

SPREAD (Unpacking)
        [1, 2, 3]
              ↓
        1 , 2 , 3
              ↓
    Pass to function / merge

REST (Collecting)
        1 , 2 , 3
              ↓
        [1, 2, 3]
              ↓
    Store in variable

Advanced Examples

Combining Spread and Rest

const arr = [1, 2, 3, 4, 5];

// Destructure with rest
const [first, second, ...remaining] = arr;

// Spread to reconstruct
const reconstructed = [first, second, ...remaining];

console.log(reconstructed);  // [1, 2, 3, 4, 5]

Deep Object Merging (Single Level)

const user = { name: "John", address: { city: "NY" } };
const update = { address: { zip: "10001" } };

// Shallow merge - overwrites entire address
const result = { ...user, ...update };
console.log(result);
// { name: "John", address: { zip: "10001" } }
// Note: city is lost!

// For deep merge, handle nested objects
const deepResult = {
  ...user,
  address: { ...user.address, ...update.address }
};
console.log(deepResult);
// { name: "John", address: { city: "NY", zip: "10001" } }

Rest with Named Parameters

function createUser(firstName, lastName, ...metadata) {
  return {
    name: firstName + " " + lastName,
    meta: metadata
  };
}

const user = createUser(
  "John",
  "Doe",
  { role: "admin" },
  { permissions: ["read", "write"] }
);

console.log(user);
// {
//   name: "John Doe",
//   meta: [{ role: "admin" }, { permissions: ["read", "write"] }]
// }

Spread in Conditional Logic

const features = ["auth", "api"];
const allFeatures = ["auth", "api", "admin", "logging"];

// Check if all features are included
const hasAllFeatures = features.every(f => allFeatures.includes(f));

// Or, spread and use includes
const isSubset = [...features].every(f => allFeatures.includes(f));

Common Mistakes

Mistake 1: Using Rest in Wrong Position

// WRONG - rest must be last
function test(a, ...rest, b) { }

// RIGHT
function test(a, b, ...rest) { }

Rest collects all remaining values. It must be last.

Mistake 2: Confusing Spread and Rest by Symbol

// WRONG - looks the same but different meaning
const arr = [...[1, 2, 3]];  // Spread - unpacking
const fn = (...args) => {};  // Rest - collecting

// RIGHT - understand the context
// In array/call: spread
// In parameters/destructuring: rest

Mistake 3: Deep Copy with Spread

const original = { user: { name: "John" } };

// WRONG - only shallow copy
const copy = { ...original };
copy.user.name = "Jane";

console.log(original.user.name);  // "Jane" (changed!)

// RIGHT - for nested objects, use deep copy or spread nested objects
const deepCopy = {
  ...original,
  user: { ...original.user }
};

Spread only does shallow copying.

Mistake 4: Spreading Non-Iterables

// WRONG - numbers are not iterable
const num = 123;
const arr = [...num];  // TypeError

// RIGHT - only spread iterables (arrays, strings, objects with Symbol.iterator)
const str = "hello";
const arr = [...str];  // ["h", "e", "l", "l", "o"]

Mistake 5: Rest in Middle of Destructuring

// WRONG - rest must be last
const { a, ...rest, b } = obj;

// RIGHT
const { a, b, ...rest } = obj;

Quick Recap

• Spread operator (...) in array/object literals or function calls: Expands elements.

  • console.log(...[1,2,3]) → prints 1 2 3
  • Math.max(...[5,6,2]) → returns 6
  • {...obj} → creates a copy

• Rest operator (...) in function parameters or destructuring: Collects values into an array.

  • function(...args) → collects all arguments
  • const [a, ...rest] = arr → collects remaining elements
  • const { name, ...rest } = obj → collects remaining properties

• Context determines meaning:

  • In arrays/calls: Spread (unpacking)
  • In parameters/destructuring: Rest (collecting)

• Spread uses:

  • Copy arrays and objects
  • Merge arrays and objects
  • Pass array elements as function arguments
  • Insert elements into arrays

• Rest uses:

  • Accept variable number of arguments
  • Destructure arrays and objects
  • Extract specific values and collect the rest

• Spread is shallow - nested objects/arrays aren't fully copied.

• Rest must be last - it collects all remaining values.

Master spread and rest. Write cleaner, more flexible code. You'll use them constantly.

Happy coding! 🚀

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)

This is about how string methods work, why developers write polyfills, and how to ace those string manipulation interview questions.

What Are String Methods?

String methods are functions that operate on strings. JavaScript has many built-in.

Built-In String Methods

const str = "Hello";

str.length           // 5
str.toUpperCase()    // "HELLO"
str.toLowerCase()    // "hello"
str.charAt(0)        // "H"
str.indexOf("e")     // 1
str.slice(0, 3)      // "Hel"
str.trim()           // Removes whitespace

These methods are available on every string. You've used them a thousand times.

How Methods Work Conceptually

Every string has methods attached to it. When you call a method, JavaScript:

1. Takes the string as context (this)
2. Performs an operation
3. Returns a result

"hello".toUpperCase()
    ↓
1. this = "hello"
2. Convert all letters to uppercase
3. Return "HELLO"

String Methods Are Just Functions

Under the hood, a string method is just a function that:

• Accesses the string's characters
• Does something with them
• Returns a result

Understanding this is key. Once you know how they work, you can build them.

How Strings Actually Work

Before writing polyfills, understand how strings are structured.

Strings Are Character Arrays

A string is a sequence of characters. You can access each character by index:

const str = "Hello";

str[0]  // "H"
str[1]  // "e"
str[2]  // "l"
str[3]  // "l"
str[4]  // "o"

Each character has a position (index). Index 0 is the first character.

Strings Have a Length

const str = "Hello";
str.length  // 5

You can iterate through all characters:

for (let i = 0; i < str.length; i++) {
  console.log(str[i]);
}

// Output:
// H
// e
// l
// l
// o

Strings Are Immutable

Once created, you can't change a string. Methods return new strings:

const original = "hello";
const upper = original.toUpperCase();

console.log(original); // "hello" (unchanged)
console.log(upper);    // "HELLO" (new string)

This is crucial for polyfills. You always create and return new strings.

What Is a Polyfill?

A polyfill is code that replicates the functionality of a built-in method.

Why Write Polyfills?

Reason 1: Compatibility

Some older browsers don't have newer methods. A polyfill provides that functionality:

// Modern method
const trimmed = "  hello  ".trimStart();

// If the browser doesn't support trimStart(), use a polyfill
function trimStart(str) {
  let start = 0;
  while (str[start] === " ") {
    start++;
  }
  return str.slice(start);
}

Reason 2: Understanding

Writing a polyfill forces you to understand the logic. Interview questions often ask this.

Reason 3: Custom Behavior

Sometimes you need a slight variation:

// Built-in returns the first occurrence
"hello".indexOf("l");  // 2

// Your polyfill could return all occurrences
function findAll(str, char) {
  const indices = [];
  for (let i = 0; i < str.length; i++) {
    if (str[i] === char) {
      indices.push(i);
    }
  }
  return indices;
}

findAll("hello", "l");  // [2, 3]

Polyfill Structure

Every polyfill follows a pattern:

function myPolyfill(input, ...args) {
  // 1. Validate input
  // 2. Initialize variables
  // 3. Iterate through the string (or other logic)
  // 4. Build the result
  // 5. Return the result
}

Let's build some.

Implementing Simple String Utilities

1. Uppercase Polyfill

The logic: Convert each letter to uppercase.

function toUpperCase(str) {
  let result = "";
  
  for (let i = 0; i < str.length; i++) {
    const char = str[i];
    // ASCII: lowercase a-z is 97-122, uppercase A-Z is 65-90
    // Difference is 32
    if (char >= "a" && char <= "z") {
      // Convert lowercase to uppercase
      result += String.fromCharCode(char.charCodeAt(0) - 32);
    } else {
      // Keep non-lowercase characters as-is
      result += char;
    }
  }
  
  return result;
}

toUpperCase("hello");     // "HELLO"
toUpperCase("Hello 123"); // "HELLO 123"
toUpperCase("WORLD");     // "WORLD"

How it works:

1. Loop through each character
2. Check if it's lowercase (a-z)
3. If yes, convert to uppercase using ASCII codes
4. If no, keep it as-is
5. Build and return the result

2. Lowercase Polyfill

Similar logic, opposite direction:

function toLowerCase(str) {
  let result = "";
  
  for (let i = 0; i < str.length; i++) {
    const char = str[i];
    if (char >= "A" && char <= "Z") {
      // Convert uppercase to lowercase
      result += String.fromCharCode(char.charCodeAt(0) + 32);
    } else {
      result += char;
    }
  }
  
  return result;
}

toLowerCase("HELLO");     // "hello"
toLowerCase("Hello 123"); // "hello 123"

3. indexOf Polyfill

Find the first occurrence of a substring:

function indexOf(str, searchStr, fromIndex = 0) {
  // Start from fromIndex (or 0 if not provided)
  for (let i = fromIndex; i < str.length; i++) {
    // Check if searchStr matches starting at position i
    let match = true;
    
    for (let j = 0; j < searchStr.length; j++) {
      if (str[i + j] !== searchStr[j]) {
        match = false;
        break;
      }
    }
    
    if (match) {
      return i; // Found it, return the index
    }
  }
  
  return -1; // Not found
}

indexOf("hello world", "o");      // 4
indexOf("hello world", "world");  // 6
indexOf("hello world", "xyz");    // -1
indexOf("hello hello", "ello", 2); // 5

How it works:

1. Loop through each position in the string
2. At each position, check if the substring matches
3. To check, compare character by character
4. If all match, return the index
5. If nothing matches, return -1

4. slice Polyfill

Extract a portion of the string:

function slice(str, start = 0, end = str.length) {
  // Handle negative indices
  if (start < 0) start = Math.max(0, str.length + start);
  if (end < 0) end = Math.max(0, str.length + end);
  
  // Clamp to string boundaries
  start = Math.max(0, start);
  end = Math.min(str.length, end);
  
  let result = "";
  
  for (let i = start; i < end; i++) {
    result += str[i];
  }
  
  return result;
}

slice("hello", 0, 3);    // "hel"
slice("hello", 1);       // "ello"
slice("hello", -3);      // "llo"
slice("hello", -4, -1);  // "ell"

How it works:

1. Handle negative indices (count from the end)
2. Clamp values to string boundaries
3. Loop from start to end
4. Collect characters and return

5. includes Polyfill

Check if a string contains a substring:

function includes(str, searchStr, position = 0) {
  // Start searching from position
  for (let i = position; i < str.length; i++) {
    // Try to match searchStr at position i
    let match = true;
    
    for (let j = 0; j < searchStr.length; j++) {
      if (str[i + j] !== searchStr[j]) {
        match = false;
        break;
      }
    }
    
    if (match) {
      return true;
    }
  }
  
  return false;
}

includes("hello world", "world");  // true
includes("hello world", "xyz");    // false
includes("hello world", "ell", 1); // true

6. split Polyfill

Split a string by a delimiter:

function split(str, delimiter = "", limit) {
  const result = [];
  
  if (delimiter === "") {
    // Split into individual characters
    for (let i = 0; i < str.length; i++) {
      if (limit !== undefined && result.length >= limit) break;
      result.push(str[i]);
    }
  } else {
    let current = "";
    let i = 0;
    
    while (i < str.length) {
      // Check if delimiter matches at position i
      let match = true;
      for (let j = 0; j < delimiter.length; j++) {
        if (str[i + j] !== delimiter[j]) {
          match = false;
          break;
        }
      }
      
      if (match) {
        // Delimiter found
        result.push(current);
        if (limit !== undefined && result.length >= limit) {
          return result;
        }
        current = "";
        i += delimiter.length;
      } else {
        // Not a match, add character to current
        current += str[i];
        i++;
      }
    }
    
    result.push(current); // Add the last part
  }
  
  return result;
}

split("hello", "");        // ["h", "e", "l", "l", "o"]
split("a,b,c", ",");       // ["a", "b", "c"]
split("hello", "l");       // ["he", "", "o"]
split("a,b,c,d", ",", 2);  // ["a", "b"]

7. trim Polyfill

Remove whitespace from both ends:

function trim(str) {
  let start = 0;
  let end = str.length - 1;
  
  // Find first non-whitespace character
  while (start <= end && str[start] === " ") {
    start++;
  }
  
  // Find last non-whitespace character
  while (end >= start && str[end] === " ") {
    end--;
  }
  
  // Return the trimmed string
  return str.slice(start, end + 1);
}

trim("  hello  ");     // "hello"
trim("hello");         // "hello"
trim("  ");            // ""
trim("  a b c  ");     // "a b c"

How it works:

1. Find the first non-space character from the left
2. Find the first non-space character from the right
3. Extract the substring between them

8. repeat Polyfill

Repeat a string multiple times:

function repeat(str, count) {
  // Validate count
  if (count < 0 || count === Infinity) {
    throw new Error("Invalid count value");
  }
  
  let result = "";
  
  for (let i = 0; i < count; i++) {
    result += str;
  }
  
  return result;
}

repeat("ab", 3);    // "ababab"
repeat("hello", 2); // "hellohello"
repeat("x", 0);     // ""

9. replace Polyfill

Replace the first occurrence of a substring:

function replace(str, searchStr, replaceStr) {
  // Find the first occurrence
  for (let i = 0; i < str.length; i++) {
    let match = true;
    
    // Check if searchStr matches at position i
    for (let j = 0; j < searchStr.length; j++) {
      if (str[i + j] !== searchStr[j]) {
        match = false;
        break;
      }
    }
    
    if (match) {
      // Found it, replace and return
      return str.slice(0, i) + replaceStr + str.slice(i + searchStr.length);
    }
  }
  
  // Not found, return original
  return str;
}

replace("hello world", "world", "universe"); // "hello universe"
replace("hello hello", "hello", "hi");       // "hi hello"
replace("hello", "xyz", "abc");              // "hello"

10. startsWith Polyfill

Check if a string starts with a substring:

function startsWith(str, searchStr, position = 0) {
  // Check if str starts with searchStr from position
  for (let i = 0; i < searchStr.length; i++) {
    if (str[position + i] !== searchStr[i]) {
      return false;
    }
  }
  return true;
}

startsWith("hello", "he");      // true
startsWith("hello", "ell");     // false
startsWith("hello", "ell", 1);  // true
startsWith("hello", "");        // true

String Processing Flow

Here's how string methods conceptually work:

Input String
    ↓
Method receives it
    ↓
Initialize result container
    ↓
Loop through characters
    ↓
    ├─ Evaluate each character
    ├─ Apply logic
    └─ Add to result
    ↓
Return new string

Visual Example: indexOf

String: "hello world"
Search: "o"

Position 0: "h" vs "o" → No match
Position 1: "e" vs "o" → No match
Position 2: "l" vs "o" → No match
Position 3: "l" vs "o" → No match
Position 4: "o" vs "o" → MATCH!

Return: 4

Visual Example: split

String: "a,b,c"
Delimiter: ","

Position 0: "a" → Not delimiter → Add to current
Position 1: "," → DELIMITER → Push "a" to result, reset
Position 2: "b" → Not delimiter → Add to current
Position 3: "," → DELIMITER → Push "b" to result, reset
Position 4: "c" → Not delimiter → Add to current
End of string → Push "c" to result

Result: ["a", "b", "c"]

Common Interview String Problems

Problem 1: Reverse a String

Question: Write a function to reverse a string.

function reverseString(str) {
  let result = "";
  
  for (let i = str.length - 1; i >= 0; i--) {
    result += str[i];
  }
  
  return result;
}

reverseString("hello");  // "olleh"
reverseString("12345");  // "54321"

Alternative: Using built-in methods

function reverseString(str) {
  return str.split("").reverse().join("");
}

Problem 2: Check for Palindrome

Question: Check if a string is a palindrome.

function isPalindrome(str) {
  // Remove spaces and convert to lowercase
  const clean = str.toLowerCase().replace(/\s/g, "");
  
  // Compare with reversed version
  let reversed = "";
  for (let i = clean.length - 1; i >= 0; i--) {
    reversed += clean[i];
  }
  
  return clean === reversed;
}

isPalindrome("racecar");      // true
isPalindrome("race car");     // true
isPalindrome("hello");        // false

Alternative: Two-pointer approach

function isPalindrome(str) {
  const clean = str.toLowerCase().replace(/\s/g, "");
  let left = 0;
  let right = clean.length - 1;
  
  while (left < right) {
    if (clean[left] !== clean[right]) {
      return false;
    }
    left++;
    right--;
  }
  
  return true;
}

Problem 3: Count Character Frequency

Question: Count how many times each character appears.

function countCharacters(str) {
  const count = {};
  
  for (let i = 0; i < str.length; i++) {
    const char = str[i];
    count[char] = (count[char] || 0) + 1;
  }
  
  return count;
}

countCharacters("hello");
// { h: 1, e: 1, l: 2, o: 1 }

countCharacters("aabbcc");
// { a: 2, b: 2, c: 2 }

Problem 4: Find the First Non-Repeated Character

Question: Find the first character that appears only once.

function firstNonRepeated(str) {
  const count = {};
  
  // Count all characters
  for (let i = 0; i < str.length; i++) {
    const char = str[i];
    count[char] = (count[char] || 0) + 1;
  }
  
  // Find first character with count 1
  for (let i = 0; i < str.length; i++) {
    if (count[str[i]] === 1) {
      return str[i];
    }
  }
  
  return null;
}

firstNonRepeated("hello");      // "h"
firstNonRepeated("aabbcc");     // null
firstNonRepeated("aabbc");      // "c"

Problem 5: Anagram Check

Question: Check if two strings are anagrams.

function isAnagram(str1, str2) {
  // Remove spaces and convert to lowercase
  const clean1 = str1.toLowerCase().replace(/\s/g, "");
  const clean2 = str2.toLowerCase().replace(/\s/g, "");
  
  // Check if lengths match
  if (clean1.length !== clean2.length) {
    return false;
  }
  
  // Count characters in first string
  const count = {};
  for (let i = 0; i < clean1.length; i++) {
    const char = clean1[i];
    count[char] = (count[char] || 0) + 1;
  }
  
  // Check if characters match in second string
  for (let i = 0; i < clean2.length; i++) {
    const char = clean2[i];
    if (!count[char]) {
      return false;
    }
    count[char]--;
  }
  
  return true;
}

isAnagram("listen", "silent");      // true
isAnagram("hello", "world");        // false
isAnagram("abc", "bca");            // true

Alternative: Sorting approach

function isAnagram(str1, str2) {
  const sort1 = str1.toLowerCase().replace(/\s/g, "").split("").sort().join("");
  const sort2 = str2.toLowerCase().replace(/\s/g, "").split("").sort().join("");
  return sort1 === sort2;
}

Problem 6: String Compression

Question: Compress a string by replacing repeated characters with count.

function compress(str) {
  if (str.length <= 2) return str;
  
  let result = "";
  let count = 1;
  
  for (let i = 0; i < str.length; i++) {
    // If next character is different or we're at the end
    if (str[i] !== str[i + 1]) {
      result += str[i] + count;
      count = 1;
    } else {
      count++;
    }
  }
  
  return result.length < str.length ? result : str;
}

compress("aabbcc");      // "a2b2c2"
compress("abcdef");      // "abcdef" (no compression)
compress("aaaa");        // "a4"

Problem 7: Word Frequency

Question: Count how many times each word appears.

function wordFrequency(str) {
  const words = str.toLowerCase().split(/\s+/);
  const count = {};
  
  for (let i = 0; i < words.length; i++) {
    const word = words[i];
    count[word] = (count[word] || 0) + 1;
  }
  
  return count;
}

wordFrequency("hello world hello");
// { hello: 2, world: 1 }

Problem 8: Longest Substring Without Repeating Characters

Question: Find the length of the longest substring without repeating characters.

function longestSubstring(str) {
  let maxLength = 0;
  let currentLength = 0;
  const charIndex = {};
  
  for (let i = 0; i < str.length; i++) {
    const char = str[i];
    
    // If character was seen and is in current window
    if (charIndex[char] !== undefined && charIndex[char] >= (i - currentLength)) {
      // Reset length
      currentLength = i - charIndex[char] - 1;
    } else {
      currentLength++;
    }
    
    charIndex[char] = i;
    maxLength = Math.max(maxLength, currentLength);
  }
  
  return maxLength;
}

longestSubstring("abcabcbb");  // 3 ("abc")
longestSubstring("bbbbb");     // 1 ("b")
longestSubstring("pwwkew");    // 3 ("kew")

Why Understanding Built-In Behavior Matters

Interview Preparation

Interviewers ask you to build string methods for a reason:

1. It shows understanding - You know how strings work at a fundamental level
2. It tests logic - You can think through problems algorithmically
3. It reveals gaps - Edge cases in your implementation show what you miss
4. It's practical - You can debug better when things go wrong

Real-World Application

Understanding how methods work helps you:

1. Debug faster - When something goes wrong, you understand why
2. Optimize - You know the cost of operations
3. Choose wisely - Pick the right method for the job
4. Extend functionality - Build custom methods when needed

Edge Cases Show Deep Understanding

// A shallow implementation
function includes(str, search) {
  return str.indexOf(search) !== -1;
}

// A deep implementation handles edge cases
function includes(str, search, position = 0) {
  if (search === "") return true;         // Empty string is always included
  if (position >= str.length) return false; // Position out of bounds
  if (search.length > str.length) return false; // Search longer than string
  
  // ... actual logic
}

The difference is understanding the edge cases.

Polyfill Behavior Representation

Built-in Method
    ↓
Input Validation
    ↓
    ├─ Check arguments
    ├─ Handle defaults
    └─ Validate types
    ↓
Core Logic
    ↓
    ├─ Loop through string
    ├─ Apply transformations
    └─ Build result
    ↓
Result Assembly
    ↓
    ├─ Combine parts
    ├─ Format output
    └─ Handle edge cases
    ↓
Return Result

Every polyfill follows this pattern.

String Method Comparison Table

Practice Assignment

1. Implement charAt:

function charAt(str, index) {
  // Return the character at the given index
  // Return empty string if out of bounds
}

charAt("hello", 0);  // "h"
charAt("hello", 5);  // ""

2. Implement lastIndexOf:

function lastIndexOf(str, searchStr) {
  // Find the LAST occurrence of searchStr
  // Return -1 if not found
}

lastIndexOf("hello", "l");     // 3
lastIndexOf("hello", "hello"); // 0

3. Implement endsWith:

function endsWith(str, searchStr, length) {
  // Check if str ends with searchStr
  // Optional length parameter
}

endsWith("hello", "lo");   // true
endsWith("hello", "ll");   // false

4. Solve a common problem:

Choose one:

• Reverse a string
• Check palindrome
• Count character frequency
• Find first non-repeated character
• Check anagram

5. Implement replaceAll:

function replaceAll(str, searchStr, replaceStr) {
  // Replace ALL occurrences (not just the first)
}

replaceAll("hello hello", "hello", "hi");  // "hi hi"
replaceAll("aaa", "a", "b");                // "bbb"

Common Mistakes

Mistake 1: Forgetting String Immutability

// WRONG - trying to modify a string
let str = "hello";
str[0] = "H";
console.log(str); // "hello" (unchanged)

// RIGHT - create a new string
function capitalize(str) {
  return str[0].toUpperCase() + str.slice(1);
}

Mistake 2: Off-by-One Errors

// WRONG - loop goes one too far
for (let i = 0; i <= str.length; i++) {
  // Accesses str[str.length] which is undefined
}

// RIGHT
for (let i = 0; i < str.length; i++) {
  // Safe access
}

Mistake 3: Not Handling Empty Strings

// WRONG - crashes on empty string
function firstChar(str) {
  return str[0].toUpperCase(); // Error if str is ""
}

// RIGHT
function firstChar(str) {
  if (str.length === 0) return "";
  return str[0].toUpperCase();
}

Mistake 4: Ignoring Edge Cases

// WRONG - doesn't handle negatives
function slice(str, start, end) {
  // What if start is negative?
}

// RIGHT
function slice(str, start = 0, end = str.length) {
  if (start < 0) start = Math.max(0, str.length + start);
  if (end < 0) end = Math.max(0, str.length + end);
  // ... continue
}

Mistake 5: Inefficient Concatenation

// SLOW - creates new string each iteration
function repeat(str, count) {
  let result = "";
  for (let i = 0; i < count; i++) {
    result += str; // Creates new string each time
  }
  return result;
}

// BETTER - still works, same approach is fine for interviews
// For production, consider array join method
function repeat(str, count) {
  let result = "";
  for (let i = 0; i < count; i++) {
    result += str;
  }
  return result;
}

Quick Recap

• String methods are built-in functions that operate on strings.

• Strings are sequences of characters that you can access by index.

• Strings are immutable - methods return new strings, not modify the original.

• A polyfill replicates the functionality of a built-in method.

• Why polyfills matter:

  • Understand how built-ins work
  • Prepare for interviews
  • Provide fallbacks for older browsers

• Core pattern for any polyfill:

  1. Validate input
  2. Initialize result
  3. Loop and process
  4. Return result

• Common interview problems:

  • Reverse string
  • Palindrome check
  • Character frequency
  • Anagram detection
  • String compression
  • Substring without repeating chars

• Edge cases matter - empty strings, negative indices, out-of-bounds access.

• Built-in behavior understanding helps you:

  • Debug faster
  • Choose the right method
  • Optimize code
  • Pass interviews

Build your own string methods. Understand how they work. Master the fundamentals.

Happy coding! 🚀

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)

This is about installing Node.js, understanding what it does, running your first script, and building your first server.

What Is Node.js?

Node.js is a JavaScript runtime. It lets you run JavaScript code outside the browser.

JavaScript Before Node.js

Browser
    ↓
  JavaScript engine
    ↓
  Runs scripts, handles DOM, events

JavaScript was trapped in the browser. You needed a browser to run JavaScript.

JavaScript with Node.js

Computer / Server
    ↓
  Node.js (JavaScript runtime)
    ↓
  Runs scripts, handles files, networks, databases

Now JavaScript runs anywhere. No browser needed.

What Can Node.js Do?

• Create web servers
• Read and write files
• Make HTTP requests
• Connect to databases
• Run command-line tools
• Build APIs
• Process data

Basically anything a server-side language can do.

Installing Node.js

Node.js is free and open-source. Installation takes 2 minutes.

Step 1: Go to nodejs.org

Visit https://nodejs.org/

You'll see two versions:

LTS (Long Term Support)  ← Recommended for beginners
Current                  ← Latest features, less stable

Download the LTS version. It's stable and supported for years.

Step 2: Run the Installer

Windows:

1. Download the .msi file
2. Run the installer
3. Click "Next" through the steps
4. Click "Install"
5. Click "Finish"

macOS:

1. Download the .pkg file
2. Run the installer
3. Follow the prompts
4. Done

Linux (Ubuntu/Debian):

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs

Or use your package manager.

Step 3: Verify Installation

Open a terminal/command prompt and type:

node --version

You should see:

v20.10.0

(The exact version doesn't matter, just that it shows a version.)

Also check npm:

npm --version

You should see:

10.2.3

Both commands working? Node.js is installed. You're done.

Understanding the Terminal

You'll need to use the terminal (command line) to run Node.js scripts.

Opening the Terminal

Windows:

• Press Win + R
• Type cmd
• Press Enter

macOS:

• Press Cmd + Space
• Type terminal
• Press Enter

Linux:

• Ctrl + Alt + T
• Or search for "Terminal"

Basic Commands

pwd                 # Print working directory (where you are)
ls                  # List files in current directory
cd folder_name      # Change directory (go into a folder)
cd ..               # Go up one level
mkdir folder_name   # Make a new folder

Example

pwd
# Output: /Users/john/Documents

ls
# Output: Desktop  Documents  Downloads

cd Documents
# Now you're in Documents folder

pwd
# Output: /Users/john/Documents

mkdir my-app
cd my-app
# Now you're in my-app folder

The Node REPL

REPL stands for "Read-Eval-Print-Loop". It's an interactive JavaScript environment.

What Is REPL?

Read   → You type JavaScript code
Eval   → Node.js evaluates it
Print  → It prints the result
Loop   → Waits for more input

It's like a JavaScript sandbox where you can test code instantly.

Starting the REPL

Type this in your terminal:

node

You'll see:

Welcome to Node.js v20.10.0.
Type ".help" for more information.
>

The > prompt means Node is waiting for input.

Using the REPL

Try some JavaScript:

> 2 + 2
4
> "hello"
'hello'
> const name = "John"
undefined
> name
'John'

The REPL evaluates each line and prints the result. undefined is printed when there's nothing to return (like after assignment).

REPL Examples

> const numbers = [1, 2, 3]
undefined

> numbers.length
3

> numbers.map(n => n * 2)
[ 2, 4, 6 ]

> Math.sqrt(16)
4

> new Date()
2026-05-04T10:30:45.123Z

Exiting the REPL

Type .exit or press Ctrl + D:

> .exit

You're back at the terminal prompt.

REPL Is for Experimenting

The REPL is great for:

• Testing code quickly
• Learning JavaScript
• Debugging
• Exploring APIs

But for real applications, you write code in files.

Your First Node.js Script

Let's create a simple JavaScript file and run it with Node.

Step 1: Create a Folder

mkdir my-first-app
cd my-first-app

You're now in a new folder.

Step 2: Create a JavaScript File

Create a file named hello.js:

Windows (Command Prompt):

type nul > hello.js

macOS/Linux:

touch hello.js

Or use a text editor (VS Code, Sublime Text, etc.) to create the file.

Step 3: Write Code

Open hello.js in your text editor and write:

console.log("Hello, World!");

Save the file.

Step 4: Run the Script

In your terminal (in the same folder), type:

node hello.js

You'll see:

Hello, World!

Success! You just ran your first Node.js script.

What Happened?

You type: node hello.js
    ↓
Node reads hello.js
    ↓
Node executes the code
    ↓
console.log() prints to terminal
    ↓
Output: Hello, World!
    ↓
Script finishes, returns to prompt

More Examples

Example 1: Variables and Math

Create math.js:

const a = 10;
const b = 20;
const sum = a + b;

console.log("Sum:", sum);
console.log("Product:", a * b);

Run it:

node math.js

Output:

Sum: 30
Product: 200

Example 2: Arrays and Loops

Create loop.js:

const fruits = ["apple", "banana", "orange"];

console.log("Fruits:");
for (let fruit of fruits) {
  console.log("- " + fruit);
}

Run it:

node loop.js

Output:

Fruits:
- apple
- banana
- orange

Example 3: Functions

Create greet.js:

function greet(name, age) {
  console.log("Hello, " + name + "!");
  console.log("You are " + age + " years old.");
}

greet("Alice", 25);
greet("Bob", 30);

Run it:

node greet.js

Output:

Hello, Alice!
You are 25 years old.
Hello, Bob!
You are 30 years old.

Node.js Execution Flow

Here's what happens when you run a script.

Execution Timeline

You type: node hello.js
    ↓
1. Node.js starts
    ↓
2. Reads hello.js
    ↓
3. Parses the code (checks for syntax errors)
    ↓
4. Executes the code line by line
    ↓
5. Encounters console.log()
    ↓
6. Prints output to terminal
    ↓
7. Code finishes
    ↓
8. Node.js exits
    ↓
Back to terminal prompt

Script → Runtime → Output Flow

hello.js (file)
    ↓
Node.js Runtime
    ↓
JavaScript Engine (V8)
    ↓
Parse code
    ↓
Execute code
    ↓
Call built-in functions (console.log, etc.)
    ↓
Output: "Hello, World!"

Why Files vs REPL?

REPL is interactive:

• Type one line
• See result immediately
• Good for learning

Files are permanent:

• Code is saved
• Can run anytime
• Easy to share
• Good for real projects

Writing Your First Server

Now let's create a real Node.js server. It won't be much, but it's a real web server.

What Is a Server?

A server is a program that listens for requests and sends responses.

Client (browser/computer)
    ↓
Sends request to server
    ↓
Server
    ↓
Receives request
Processes it
Sends response
    ↓
Client
    ↓
Receives response

Hello World Server

Create server.js:

const http = require("http");

const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("Hello, World!");
});

server.listen(3000);
console.log("Server running on http://localhost:3000");

Running the Server

node server.js

You'll see:

Server running on http://localhost:3000

The server is now running. It won't stop until you stop it (which you'll do in a moment).

Testing the Server

Open your browser and go to:

http://localhost:3000

You'll see:

Hello, World!

The server responded! You made a request, the server processed it, and sent back a response.

Stopping the Server

In the terminal, press Ctrl + C:

^C

The server stops. You're back at the prompt.

Breaking Down the Code

const http = require("http");

This imports Node's built-in http module. It lets you create web servers.

const server = http.createServer((req, res) => {
  // This function runs every time a request comes in
});

createServer() creates a server. The function (callback) runs for each request.

res.writeHead(200, { "Content-Type": "text/plain" });

writeHead() sends the response header. 200 means "OK" (success). The second argument specifies the content type.

res.end("Hello, World!");

end() sends the response body and closes the connection.

server.listen(3000);

listen() makes the server listen on port 3000. Your browser connects to localhost:3000.

console.log("Server running on http://localhost:3000");

Print a message so you know the server started.

Server with Different Paths

Let's make a server that responds differently based on the URL path.

Create server-routes.js:

const http = require("http");

const server = http.createServer((req, res) => {
  if (req.url === "/") {
    res.writeHead(200);
    res.end("Home page");
  } else if (req.url === "/about") {
    res.writeHead(200);
    res.end("About page");
  } else if (req.url === "/contact") {
    res.writeHead(200);
    res.end("Contact page");
  } else {
    res.writeHead(404);
    res.end("Page not found");
  }
});

server.listen(3000);
console.log("Server running on http://localhost:3000");

Run it:

node server-routes.js

Now try:

• http://localhost:3000/ → "Home page"
• http://localhost:3000/about → "About page"
• http://localhost:3000/contact → "Contact page"
• http://localhost:3000/other → "Page not found"

Each path gives a different response.

Server with HTML

Let's send actual HTML instead of plain text.

Create server-html.js:

const http = require("http");

const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "text/html" });
  
  const html = `
    <!DOCTYPE html>
    <html>
    <head>
      <title>My Node Server</title>
    </head>
    <body>
      <h1>Welcome to My Node Server</h1>
      <p>This HTML is served from Node.js</p>
    </body>
    </html>
  `;
  
  res.end(html);
});

server.listen(3000);
console.log("Server running on http://localhost:3000");

Run it:

node server-html.js

Visit http://localhost:3000 and you'll see a proper HTML page in your browser.

Project Structure

As your projects grow, organize your files.

Simple Structure

my-app/
  ├── server.js
  ├── helpers.js
  └── data.json

Everything in one folder.

Better Structure

my-app/
  ├── src/
  │   ├── server.js
  │   ├── handlers.js
  │   └── utils.js
  ├── data/
  │   └── data.json
  ├── public/
  │   ├── style.css
  │   └── index.html
  └── package.json

Organized by purpose.

Node.js Execution Flow Diagram

Write Code
    ↓
hello.js file created
    ↓
terminal: node hello.js
    ↓
Node.js starts
    ↓
Read hello.js from disk
    ↓
Parse JavaScript
    ↓
Execute code
    ↓
    ├─ Variable declarations
    ├─ Function calls
    └─ I/O operations
    ↓
Output to terminal/console
    ↓
Script finishes
    ↓
Process exits
    ↓
Back to terminal prompt

Common Questions

Q: What's the difference between Node.js and npm?

Node.js is the JavaScript runtime.

npm is the Node Package Manager. It lets you install libraries and tools.

node --version    # Check Node.js
npm --version     # Check npm

Q: Why does Node.js need a port number?

Your computer can run multiple servers. Each server needs a unique port.

Port 3000 → My app
Port 5000 → Another app
Port 8080 → Another app

A port is like an address on your computer.

Q: Can I use Node.js with HTML/CSS?

Yes. Node.js can serve HTML and CSS files. Or you can use frameworks like Express to make it easier.

Q: Is Node.js used only for web servers?

No. You can:

• Build web servers
• Create command-line tools
• Process files
• Build real-time applications
• Automate tasks
• And much more

Q: Do I need a framework like Express?

Not at all. You can build servers with just Node's built-in modules. But Express makes it easier.

Q: Can I run Node.js code in the browser?

No. Node.js runs on servers/your computer. Browser JavaScript is different. They have different APIs.

Practice Assignment

1. Install Node.js and verify:

node --version
npm --version

Both should print version numbers.

2. Try the REPL:

node
> 5 + 5
> "hello " + "world"
> const name = "John"
> name.toUpperCase()
> .exit

Experiment with different JavaScript.

3. Create your first script:

Create welcome.js:

const name = "Your Name";
console.log("Welcome, " + name);
console.log("You are now a Node.js developer!");

Run it:

node welcome.js

4. Create a simple calculator:

Create calculator.js:

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

function multiply(a, b) {
  return a * b;
}

// Your code: call these functions and print results

5. Create a Hello World server:

Create server.js:

const http = require("http");

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

server.listen(3000);
console.log("Server running on http://localhost:3000");

Run it and visit http://localhost:3000 in your browser.

6. Extend the server:

Add more routes to your server:

• / → "Home page"
• /about → "About page"
• /contact → "Contact page"
• anything else → "Page not found"

Common Mistakes

Mistake 1: Forgetting to Install Node.js

You: node hello.js
Terminal: command not found

Solution: Install Node.js from nodejs.org

Mistake 2: Running a File That Doesn't Exist

node nonexistent.js
# Error: Cannot find module 'nonexistent.js'

Check the filename is correct and you're in the right folder.

Mistake 3: Forgetting to Save the File

// You write this in the editor
console.log("Hello");

// But don't save it
node hello.js
// Node runs the old version (or no file found)

Always save before running.

Mistake 4: Not Stopping the Server Before Restarting

node server.js
# (ctrl + C to stop)

node server.js
# If you don't stop first:
# Error: Port 3000 already in use

Stop with Ctrl + C before running again.

Mistake 5: Typos in require()

const http = require("htttp");  // WRONG
const http = require("http");   // RIGHT

The module name is case-sensitive.

Next Steps

You've learned the basics. Here's what to explore next:

Learn More JavaScript

• Variables and data types
• Functions and callbacks
• Objects and arrays
• ES6+ features

Learn Node.js Modules

• fs module (file operations)
• path module (file paths)
• events module (event handling)
• stream module (data streaming)

Learn npm and Packages

• Install packages: npm install
• Use package.json
• Manage dependencies
• Use popular packages

Learn a Framework

• Express.js - Web framework
• Fastify - Fast web framework
• Hapi - Full-featured framework

Build Projects

• Web server
• API
• Command-line tool
• Real-time application

Quick Recap

• Node.js is a JavaScript runtime for servers and computers.

• Installation is simple - download from nodejs.org and run the installer.

• REPL is an interactive JavaScript shell. Type node to start it.

• Scripts are JavaScript files you run with node filename.js.

• Server listens for requests and sends responses.

• Port 3000 is a common port for development (http://localhost:3000).

• Ctrl + C stops a running script (like a server).

• File structure matters. Organize your code as projects grow.

• console.log() prints to the terminal.

• require() imports modules (like http).

You now have Node.js running. You can execute JavaScript anywhere. The world of back-end development is open.

Build something! 🚀

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)

This is about how Node.js handles concurrency, the event loop, background workers, and why a single-threaded language can scale to handle massive workloads.

The Single-Threaded Nature of Node.js

JavaScript code in Node.js runs on a single thread. Your application code executes one line at a time, in order.

One Thread, One Stack, One Job at a Time

Your JavaScript Code
        ↓
Single Thread
        ↓
One statement at a time
        ↓
Next statement runs when previous finishes

console.log("1");
console.log("2");
console.log("3");

// Output:
// 1
// 2
// 3

The thread processes each line sequentially.

Single-Threaded Means What, Exactly?

function task1() {
  console.log("Task 1 starting");
  for (let i = 0; i < 1000000000; i++) {} // Long operation
  console.log("Task 1 done");
}

function task2() {
  console.log("Task 2 starting");
  console.log("Task 2 done");
}

task1();
task2();

// Output:
// Task 1 starting
// Task 1 done
// Task 2 starting
// Task 2 done

Task 2 has to wait for Task 1 to finish. The single thread blocks. It can't do anything else until Task 1 completes.

This is a problem in a web server. If one request takes 10 seconds, all other requests wait 10 seconds.

So How Does Node.js Handle Multiple Requests?

The trick is: Node.js doesn't actually execute multiple JavaScript operations simultaneously. Instead, it cleverly switches between them using the event loop and delegates heavy work to background threads.

Understanding Concurrency vs Parallelism

These terms sound similar but are fundamentally different.

Parallelism: True Simultaneous Execution

Multiple tasks run at the exact same time on different CPU cores.

Core 1: Task A --------→
Core 2: Task B --------→
Core 3: Task C --------→

All three run simultaneously

Two multi-core processors can do parallel tasks. Node.js on a single thread cannot.

Concurrency: Interleaved Execution

One thread rapidly switches between tasks, making it appear like they run simultaneously.

Thread:  Task A → Task B → Task A → Task C → Task B → Task C → ...

Switching so fast it looks like they're all running at once

Node.js does this. It's not true simultaneous execution, but it feels like it to the user.

The Analogy: Chef Handling Orders

Imagine a restaurant with one chef.

Parallel: Multiple chefs cooking different dishes at the same time.

Concurrent: One chef:

1. Starts cooking an order (put it on the stove)
2. While it's cooking, takes the next order
3. While that's cooking, preps a third order
4. Checks on the first dish (it's done, plate it)
5. Gets the second dish, plates it
6. Continues cooking the third dish
7. Repeats

The chef isn't cooking multiple dishes at once. But orders are being prepared concurrently. The chef switches between tasks during downtime.

Node.js is the chef. Your requests are orders. The event loop manages the switching.

The Event Loop: The Brain of Node.js

The event loop is what makes concurrency possible. It's the mechanism that keeps Node.js running and switching between tasks.

What Is the Event Loop?

The event loop continuously checks for work to do. It runs through different types of tasks in a specific order.

Event Loop Phases (simplified):

1. Timers → Execute setTimeout/setInterval callbacks
2. Pending I/O → Execute I/O operations
3. Check → Execute setImmediate callbacks
4. Close → Execute cleanup callbacks

When all phases are empty, loop repeats

How It Works

console.log("Start");

setTimeout(function() {
  console.log("After 0ms");
}, 0);

console.log("End");

// Output:
// Start
// End
// After 0ms

Here's what happens:

1. console.log("Start") runs immediately
   Output: Start

2. setTimeout() registers the callback but doesn't execute it
   The callback is added to the event loop queue

3. console.log("End") runs immediately
   Output: End

4. The main JavaScript code is done

5. Event loop checks its queues
   It finds the setTimeout callback

6. Event loop executes the callback
   Output: After 0ms

The callback runs later, not immediately. The event loop scheduled it.

Event Loop Keeps Running

const http = require("http");

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

server.listen(3000);

console.log("Server listening on port 3000");

Output: Server listening on port 3000

Then the program doesn't exit. The server stays running. Why? The event loop is still running, waiting for requests. When a request comes in, it handles it. When done, it goes back to waiting.

The event loop never stops (until you kill the process).

The Event Loop Executes Your Code

While (event loop is running) {
  if (timers have callbacks) {
    execute timer callbacks
  }
  
  if (I/O operations are done) {
    execute I/O callbacks
  }
  
  if (setImmediate has callbacks) {
    execute setImmediate callbacks
  }
  
  Wait for more events
}

This loop runs constantly, even when nothing is happening (it just waits).

Handling Multiple Requests with One Thread

Now let's see how multiple HTTP requests are handled.

Single-Threaded HTTP Server

const http = require("http");

const server = http.createServer((req, res) => {
  console.log("Request received");
  
  // Simulate some work
  for (let i = 0; i < 100000000; i++) {}
  
  res.writeHead(200);
  res.end("Hello");
});

server.listen(3000);

A request comes in. The callback runs. It does some work. It sends a response. Done.

But what if 5 requests come in simultaneously?

Request 1 Timeline

Time: 0ms    → Request 1 arrives
Time: 0ms    → Callback runs
Time: 0-100ms → Doing work
Time: 100ms  → Response sent

Requests 2-5 Arrive While Request 1 Is Processing

Time: 0ms    → Request 1 arrives → Callback queued
Time: 10ms   → Request 2 arrives → Queued
Time: 20ms   → Request 3 arrives → Queued
Time: 30ms   → Request 4 arrives → Queued
Time: 40ms   → Request 5 arrives → Queued

Time: 100ms  → Request 1 processing done → Response sent

Time: 100ms  → Request 2 callback runs
Time: 200ms  → Request 2 done → Response sent

Time: 200ms  → Request 3 callback runs
...and so on

Requests queue up. They're handled one at a time. This seems bad. But here's the trick: the waiting is hidden.

The Real Trick: Non-Blocking I/O

The problem above assumes blocking work (the for loop). In real applications, work is I/O (network, files, database):

const http = require("http");
const fs = require("fs");

const server = http.createServer((req, res) => {
  // Non-blocking I/O
  fs.readFile("data.txt", (err, data) => {
    res.writeHead(200);
    res.end(data);
  });
});

server.listen(3000);

This is what happens:

Time: 0ms    → Request 1 arrives
Time: 0ms    → fs.readFile() called (non-blocking)
             → Callback registered in event loop
             → Function returns immediately

Time: 0ms    → Event loop is free!
             → Can handle Request 2

Time: 0ms    → Request 2 arrives
Time: 0ms    → fs.readFile() called (non-blocking)
             → Callback registered
             → Returns immediately

Time: 0ms    → Event loop is free!
             → Waiting for I/O to complete

Time: 50ms   → File read completes for Request 1
             → Callback for Request 1 executes
             → Response sent

Time: 50ms   → Event loop is free!
             → Waiting for Request 2's file read

Time: 100ms  → File read completes for Request 2
             → Callback for Request 2 executes
             → Response sent

Two requests are handled "concurrently" but with no blocking. While one is waiting for file I/O, the other can start.

Delegating Work to Background Threads

Some work can't be non-blocking (CPU-intensive tasks). For this, Node.js uses the Worker Thread Pool.

CPU-Intensive Work Blocks the Thread

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

const result = expensiveCalculation();
console.log(result);

This takes 10 seconds. During those 10 seconds, Node.js can't handle any requests. It's blocked.

Delegating to Worker Threads

Node.js has a Worker Thread Pool (libuv). You can delegate heavy work:

const { Worker } = require("worker_threads");
const http = require("http");

const server = http.createServer((req, res) => {
  // Delegate to a worker thread
  const worker = new Worker("./worker.js");
  
  worker.on("message", (result) => {
    res.writeHead(200);
    res.end("Result: " + result);
  });
});

server.listen(3000);

The worker thread does the heavy calculation in the background. The main thread remains free to handle other requests.

What Gets Delegated?

By default, Node.js delegates some I/O operations to the worker thread pool:

File I/O (fs module)       → Worker threads
DNS lookups                → Worker threads
Some crypto operations     → Worker threads
Database connections       → Often delegated

Your JavaScript code       → Main thread

When you call fs.readFile(), it doesn't block the main thread. It's delegated to a worker thread. The worker reads the file. When done, the callback is queued in the event loop.

libuv: The Magic Behind the Scenes

libuv is a C library that Node.js uses. It manages:

1. The event loop
2. The worker thread pool (usually 4 threads by default)
3. Platform-specific APIs for file I/O, networking, etc.

Node.js Application
        ↓
libuv (Event Loop + Thread Pool)
        ↓
Operating System APIs
        ↓
Hardware (CPU, Disk, Network)

The Complete Picture: How a Request Is Handled

Let's trace a real HTTP request from start to finish.

Request Handling Flow

1. Request arrives at the server
   ↓
2. Event loop detects it
   ↓
3. Callback function (request handler) queued
   ↓
4. Event loop executes the callback
   ↓
5. Callback calls fs.readFile() (or other I/O)
   ↓
6. fs.readFile() is delegated to worker thread
   Callback is registered
   ↓
7. Event loop is free, returns to waiting
   ↓
8. Worker thread reads file from disk
   ↓
9. File reading completes
   ↓
10. Callback is queued in event loop
    ↓
11. Event loop executes the callback
    ↓
12. Response is sent
    ↓
13. Connection closed

Code Representation

const http = require("http");
const fs = require("fs");

http.createServer((req, res) => {
  // Step 4: Callback runs
  console.log("Request received");
  
  // Step 5-6: Delegate file reading
  fs.readFile("data.txt", (err, data) => {
    // Step 11-12: Callback runs when file is read
    res.writeHead(200);
    res.end(data);
  });
  
  // Step 7: Function returns, thread is free
}).listen(3000);

// Step 1-2-3: Event loop waits for requests

Multiple Requests Timeline

Request 1 arrives → Handler queued
Handler runs      → fs.readFile delegated to worker
                  → Handler returns (thread free)

Request 2 arrives → Handler queued
Handler runs      → fs.readFile delegated to worker
                  → Handler returns (thread free)

Request 3 arrives → Handler queued
Handler runs      → fs.readFile delegated to worker
                  → Handler returns (thread free)

(Meanwhile, workers are reading files)

Worker 1: File 1 done → Callback queued
Worker 2: File 2 done → Callback queued
Worker 3: File 3 done → Callback queued

Event loop: Execute callbacks
Callback 1 → Send Response 1
Callback 2 → Send Response 2
Callback 3 → Send Response 3

Three requests are handled concurrently. The main thread never blocks. Workers handle I/O in parallel.

Why Node.js Scales Well

Efficient Resource Usage

Traditional servers create one thread per request:

Request 1 → Thread 1 (dedicated)
Request 2 → Thread 2 (dedicated)
Request 3 → Thread 3 (dedicated)
...
Request 1000 → Thread 1000 (dedicated)

Memory usage: 1000 threads × memory per thread = a lot of memory

Node.js handles all requests with one thread:

Request 1 → Event Loop
Request 2 → Event Loop
Request 3 → Event Loop
...
Request 1000 → Event Loop

Memory usage: 1 thread + small queues = much less memory

Handling C10K Problem

The C10K problem: How to handle 10,000 concurrent connections?

Traditional threaded servers struggle because:

• Creating 10,000 threads uses massive memory
• Thread switching has overhead
• Each thread has a stack (memory hungry)

Node.js handles it elegantly:

• One thread handles all connections
• I/O is delegated to worker threads
• Connections are just data in memory (lightweight)

Event-Driven Architecture

Node.js is event-driven:

Something happens → Event fires → Callback runs
                    (non-blocking)

This is efficient. The thread doesn't wait for anything. It processes events as they arrive.

Scales Horizontally

For even better scaling, run multiple Node.js processes:

Load Balancer
    ↓
├─ Node.js Process 1 (Single thread)
├─ Node.js Process 2 (Single thread)
├─ Node.js Process 3 (Single thread)
└─ Node.js Process 4 (Single thread)

Requests distributed across processes
Each process handles requests with its event loop

No threads to create. No memory overhead. Clean and fast.

Common Misconceptions

Misconception 1: "Node.js Runs Everything on One Thread"

False. JavaScript code runs on one thread. But I/O operations are delegated to worker threads. Crypto, DNS, and file operations use background threads.

Misconception 2: "Node.js Can't Do Parallel Work"

False. The main thread can't run JavaScript in parallel. But libuv's worker thread pool runs I/O operations in parallel.

Misconception 3: "Node.js Can't Handle CPU-Intensive Work"

True and false. Pure JavaScript running on the main thread blocks. But you can use Worker Threads to run CPU-intensive work in parallel:

const { Worker } = require("worker_threads");

const worker = new Worker("./heavy-calculation.js");

worker.on("message", (result) => {
  console.log("Result:", result);
});

// Main thread is free to handle other requests

Misconception 4: "If One Request Takes 10 Seconds, All Requests Wait"

Only if the request does CPU-intensive work on the main thread. If it does I/O (file read, database query), other requests proceed while it waits.

Practical Example: Web Server

Simple Web Server Handling Multiple Requests

const http = require("http");
const fs = require("fs");

const server = http.createServer((req, res) => {
  console.log("Request:", req.url);
  
  // Non-blocking file read
  fs.readFile("data.txt", (err, data) => {
    if (err) {
      res.writeHead(500);
      res.end("Error");
      return;
    }
    
    res.writeHead(200);
    res.end(data);
    console.log("Response sent for:", req.url);
  });
});

server.listen(3000);
console.log("Server listening on port 3000");

What Happens

1. Request 1 arrives

2. Handler runs, calls fs.readFile()

3. fs.readFile() delegates to worker, returns immediately

4. Event loop is free

5. Request 2 arrives

6. Handler runs, calls fs.readFile()

7. fs.readFile() delegates to worker, returns immediately

8. Event loop is free

9. Workers finish reading files

10. Callbacks are queued

11. Event loop executes callbacks

12. Responses are sent

All handled concurrently with one thread.

Load Test

curl http://localhost:3000 &
curl http://localhost:3000 &
curl http://localhost:3000 &
curl http://localhost:3000 &
curl http://localhost:3000 &

Send 5 requests at once. All handled concurrently. All respond quickly.

Event Loop Phases in Detail

The event loop goes through phases:

Phase 1: Timers

Execute callbacks from setTimeout() and setInterval().

setTimeout(() => {
  console.log("1 second passed");
}, 1000);

Phase 2: I/O Callbacks

Execute callbacks from file reads, network operations, etc.

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

Phase 3: Check

Execute setImmediate() callbacks.

setImmediate(() => {
  console.log("Immediate");
});

Phase 4: Close

Execute close callbacks from streams and connections.

connection.on("close", () => {
  console.log("Connection closed");
});

The loop repeats these phases constantly.

Order Matters

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
Promise.resolve().then(() => console.log("promise"));

// Output (usually):
// promise
// timeout
// immediate

Promises are microtasks (higher priority). They execute before the next phase.

Blocking vs Non-Blocking

Understanding this distinction is crucial.

Blocking: Stops the Event Loop

const fs = require("fs");

// Blocking
const data = fs.readFileSync("file.txt");
console.log(data);

// The event loop is stopped until the file is read

Don't use Sync methods in production. They block.

Non-Blocking: Frees the Event Loop

const fs = require("fs");

// Non-blocking
fs.readFile("file.txt", (err, data) => {
  console.log(data);
});

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

The callback happens later. The event loop continues.

Why Non-Blocking Matters

With blocking:

Request 1 arrives
File read (BLOCKS for 100ms)
Request 2 arrives (waits)
Request 3 arrives (waits)
File read done
Response 1 sent
Request 2 handled (BLOCKS for 100ms)
...all requests delayed

With non-blocking:

Request 1 arrives
File read starts (non-blocking)
Request 2 arrives
File read starts (non-blocking)
Request 3 arrives
File read starts (non-blocking)
Files read (in parallel)
All responses sent
Total time: ~100ms instead of 300ms

Practice Assignment

1. Understand the event loop:

console.log("1");

setTimeout(() => {
  console.log("2");
}, 0);

console.log("3");

// What will the output be? Why?

2. Non-blocking file operations:

const fs = require("fs");

// Write code that:
// 1. Reads 3 files without blocking
// 2. Prints them all when done

fs.readFile("file1.txt", (err, data) => {
  // Your code
});

// ... more files

3. Handle multiple HTTP requests:

const http = require("http");
const fs = require("fs");

// Create a server that:
// 1. Reads a file for each request
// 2. Sends it as response
// 3. Handles multiple requests concurrently

// Send 5 requests: curl http://localhost:3000 &

4. Identify blocking code:

// Which of these is blocking?

// A:
const data = fs.readFileSync("file.txt");

// B:
fs.readFile("file.txt", callback);

// C:
const result = expensiveCalculation();

// D:
setTimeout(callback, 0);

5. Event loop phases:

setTimeout(() => console.log("A"), 0);
setImmediate(() => console.log("B"));
process.nextTick(() => console.log("C"));

// What order will they print?

Common Mistakes

Mistake 1: Using Blocking Operations

// WRONG - blocks the event loop
const data = fs.readFileSync("file.txt");
res.end(data);

// RIGHT - non-blocking
fs.readFile("file.txt", (err, data) => {
  res.end(data);
});

Mistake 2: Long-Running Synchronous Code

// WRONG - blocks for 5 seconds
for (let i = 0; i < 10000000000; i++) {}
res.end("Done");

// RIGHT - delegate to worker thread or break into chunks

Mistake 3: Misunderstanding Callback Timing

// WRONG - expecting callback to run immediately
let data;

fs.readFile("file.txt", (err, contents) => {
  data = contents;
});

console.log(data); // undefined - callback hasn't run yet!

Mistake 4: Not Handling Errors in Callbacks

// WRONG - ignoring errors
fs.readFile("file.txt", (err, data) => {
  console.log(data); // Crashes if error and data is undefined
});

// RIGHT - check for errors
fs.readFile("file.txt", (err, data) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(data);
});

Mistake 5: Assuming One Request Blocks Others

// WRONG - thinking this blocks other requests
app.get("/slow", (req, res) => {
  fs.readFile("large-file.txt", (err, data) => {
    // While waiting here, other requests ARE handled
    res.end(data);
  });
});

// It doesn't block! Other requests proceed while this waits.

Quick Recap

• Node.js runs JavaScript on a single thread. Your code executes sequentially, one statement at a time.

• The event loop is what makes concurrency possible. It continuously checks for work and executes callbacks.

• I/O is non-blocking. When you read a file or query a database, it's delegated to a worker thread. The main thread continues.

• Concurrency vs Parallelism:

  • Concurrency: One thread switches between tasks
  • Parallelism: Multiple threads run simultaneously
  • Node.js is concurrent (one thread) but uses parallelism for I/O

• The worker thread pool (libuv) handles:

  • File I/O
  • DNS lookups
  • Some crypto operations
  • System-level I/O

• Multiple requests are handled concurrently because:

  • The main thread isn't blocked
  • I/O operations happen in the background
  • Callbacks are queued and executed when ready

• Node.js scales well because:

  • One thread uses less memory than many threads
  • I/O is efficient (parallel in background)
  • No thread creation overhead
  • Can handle thousands of concurrent connections

• Never block the event loop:

  • Use non-blocking I/O (fs.readFile, not fs.readFileSync)
  • Avoid long CPU-intensive synchronous code
  • Use Worker Threads for heavy computation

• The event loop has phases: Timers → I/O → Check → Close → Repeat

• For true parallelism, use Worker Threads or run multiple Node.js processes.

Master the event loop and concurrency model, and you'll write scalable, efficient Node.js applications.

Happy coding! 🚀

If you enjoyed this article, check out my other blogs on this profile. 🔗 Connect with me: LinkedIn | GitHub | X (Twitter)