DEV Community: Abanoub Kerols

JavaScript Closures — Part 2 (Advanced Concepts & Real-World Applications)

Abanoub Kerols — Fri, 21 Aug 2026 07:03:27 +0000

In the previous part, we learned that a closure is simply:

A function that remembers the variables from the environment where it was created.

Now let's move beyond the basics and see how professional JavaScript developers use closures every day.

Real-World Closures

If you've written JavaScript for a while, you've already used closures—even if you didn't realize it.

Closures appear in:

Event Listeners
Timers (setTimeout, setInterval)
Promises
Async/Await
React Hooks
Express Middleware
Module Pattern
Factory Functions
Memoization
Functional Programming
Currying
Dependency Injection

Closures are one of the foundations of modern JavaScript.

Closures in Event Listeners

Suppose we have a button.

<button id="save">Save</button>

Now imagine this JavaScript:

function setupButton() {

    let clickCount = 0;

    const button = document.getElementById("save");

    button.addEventListener("click", function () {

        clickCount++;

        console.log(`Clicked ${clickCount} times`);

    });

}

setupButton();

Every click increases the counter.

Why?

Because the callback remembers clickCount.

Even after setupButton() has already finished executing.

Memory looks like this:

Event Listener

↓

Closure

↓

clickCount

Without closures, every click would start from zero.

Closures with setTimeout()

One of the easiest ways to see closures is with timers.

function delayedGreeting() {

    let name = "John";

    setTimeout(function () {

        console.log(`Hello ${name}`);

    }, 3000);

}

delayedGreeting();

Output (after 3 seconds)

Hello John

Question:

How does name still exist?

Because the callback function carries a closure.

Even though delayedGreeting() already finished, JavaScript keeps the variable alive.

Closures Inside Loops

One of the most famous interview questions.

Consider this code:

for (var i = 1; i <= 5; i++) {

    setTimeout(function () {

        console.log(i);

    }, 1000);

}

Output

Most beginners expect:

Why?

Because every callback shares the same variable i.

After the loop ends:

i = 6

Every closure references that same variable.

Fix #1 — Using let

for (let i = 1; i <= 5; i++) {

    setTimeout(function () {

        console.log(i);

    }, 1000);

}

Output

Each iteration creates a brand-new variable.

Each closure gets its own copy.

Fix #2 — Using a Closure

Before let existed, developers solved it like this:

for (var i = 1; i <= 5; i++) {

    (function (currentValue) {

        setTimeout(function () {

            console.log(currentValue);

        }, 1000);

    })(i);

}

Each Immediately Invoked Function Expression (IIFE) creates a new closure.

Each callback remembers its own value.

Closures in Factory Functions

Factory functions create objects.

Closures allow every object to have private state.

function createUser(name) {

    return {

        greet() {

            console.log(`Hello ${name}`);

        }

    };

}

const john = createUser("John");

john.greet();

Output

Hello John

Notice that name is completely private.

No one can access it directly.

console.log(john.name);

Output

undefined

Only the closure can access it.

Building a Counter

One of the classic closure examples.

function createCounter() {

    let count = 0;

    return {

        increment() {

            count++;

            return count;

        },

        decrement() {

            count--;

            return count;

        },

        reset() {

            count = 0;

        }

    };

}

const counter = createCounter();

console.log(counter.increment());

console.log(counter.increment());

console.log(counter.decrement());

counter.reset();

console.log(counter.increment());

Output

Notice something important.

There is no way to modify count directly.

Everything must go through the provided methods.

This is true data encapsulation.

Closures and Private Variables

JavaScript didn't originally have private fields.

Developers used closures instead.

function createBankAccount(initialBalance) {

    let balance = initialBalance;

    return {

        deposit(amount) {

            balance += amount;

        },

        withdraw(amount) {

            if (amount <= balance) {

                balance -= amount;

            }

        },

        getBalance() {

            return balance;

        }

    };

}

Usage

const account = createBankAccount(1000);

account.deposit(500);

console.log(account.getBalance());

Output

Trying this:

console.log(account.balance);

Output

undefined

Balance is truly private.

Closures in Express Middleware

Express middleware relies heavily on closures.

function logger(prefix) {

    return function (req, res, next) {

        console.log(prefix, req.method, req.url);

        next();

    };

}

app.use(logger("[API]"));

Here:

prefix

is preserved by the closure.

Every request has access to it.

Closures in React

React Hooks are built around closures.

Example:

function Counter() {

    const [count, setCount] = useState(0);

    function increment() {

        setCount(count + 1);

    }

}

The function remembers the variables from its render.

This explains why stale closures sometimes happen in React.

Example:

setTimeout(() => {

    console.log(count);

}, 5000);

If count changes before five seconds pass...

The callback may still reference the old value.

Understanding closures makes React much easier to understand.

The Once Function

Imagine an expensive initialization process.

You only want it to run once.

function once(fn) {

    let hasRun = false;

    let result;

    return function (...args) {

        if (!hasRun) {

            result = fn(...args);

            hasRun = true;

        }

        return result;

    };

}

Usage

const initialize = once(function () {

    console.log("Initializing...");

    return "Application Ready";

});

console.log(initialize());

console.log(initialize());

console.log(initialize());

Output

Initializing...

Application Ready

Application Ready

Application Ready

Initialization happened exactly one time.

Why Does Once Work?

Memory inside the closure

hasRun = false

result = undefined

First call

↓

Run function

↓

Store result

↓

hasRun = true

Next calls

Skip execution

↓

Return stored result

No global variables.

Everything lives inside the closure.

Building a Memoize Function

Memoization avoids repeating expensive computations.

function memoize(fn) {

    const cache = {};

    return function (...args) {

        const key = JSON.stringify(args);

        if (cache[key]) {

            console.log("Cache Hit");

            return cache[key];

        }

        console.log("Calculating...");

        const result = fn(...args);

        cache[key] = result;

        return result;

    };

}

Usage

const square = memoize(function (number) {

    return number * number;

});

console.log(square(5));

console.log(square(5));

console.log(square(10));

console.log(square(10));

Output

Calculating...

25

Cache Hit

25

Calculating...

100

Cache Hit

100

The cache survives because of the closure.

Without closures, memoization would be impossible.

Module Pattern

Before ES Modules existed, developers used closures for encapsulation.

const UserModule = (function () {

    let users = [];

    function addUser(name) {

        users.push(name);

    }

    function getUsers() {

        return [...users];

    }

    return {

        addUser,

        getUsers

    };

})();

Usage

UserModule.addUser("John");

UserModule.addUser("Alice");

console.log(UserModule.getUsers());

Output

["John", "Alice"]

The internal array cannot be accessed directly.

Everything is hidden inside the closure.

Why Professional Developers Love Closures

Closures provide:

Data Privacy
Encapsulation
State Management
Function Factories
Memoization
Dependency Injection
Functional Programming Patterns
Cleaner APIs
Better Reusability

Many popular JavaScript libraries use closures internally.

If closures disappeared from JavaScript today, React, Vue, Express middleware, Redux utilities, and many modern patterns would become much harder—or impossible—to implement in their current form.

JavaScript Closures — The Complete Guide (From Beginner to Advanced)

Abanoub Kerols — Sun, 16 Aug 2026 06:53:54 +0000

One of the most powerful features in JavaScript isn't a framework, a library, or even a language keyword... it's Closures.

Closures are everywhere.

Every React Hook, every Express middleware, every event listener, every callback, every memoization function, every module pattern, and many advanced JavaScript libraries rely heavily on closures.

Yet, many developers memorize the definition without truly understanding what happens behind the scenes.

In this guide, we'll build an intuitive understanding of JavaScript Closures from scratch, explore how JavaScript stores variables, understand lexical scope, dive into execution contexts, and finally build production-ready examples used by professional software engineers.

What is a Closure?
Why Closures Exist
JavaScript Functions are First-Class Objects
Lexical Scope
Scope Chain
Execution Context
The Call Stack
Functions Remember Their Environment
The Backpack Analogy
Closed Over Variables
Returning Functions
Persistent State
Multiple Independent Closures
Real World Examples
Once Function
Memoization
Module Pattern
Common Mistakes
Performance Considerations
Best Practices
Conclusion

What is a Closure?

The official definition from MDN says:

A closure is a function bundled together with references to its surrounding lexical environment.

Although technically correct...

It doesn't really explain what is happening.

A much simpler definition is:

A Closure is a function that remembers the variables that existed when it was created—even after the outer function has already finished executing.

That's it.

The keyword here is remembers.

Why Do Closures Exist?

Normally, local variables disappear after a function finishes.

Example:

function hello() {
    let message = "Hello";
}

hello();

// message no longer exists
console.log(message);

Output

ReferenceError

The variable lived only inside hello().

After execution finished...

Memory should have been released.

So why does this work?

function outer() {

    let message = "Hello";

    function inner() {
        console.log(message);
    }

    return inner;
}

const fn = outer();

fn();

Output

Hello

How?

The outer function already finished.

Its variables should have disappeared.

But they didn't.

Because of Closure.

JavaScript Functions are More Than Code

Many developers think a function is only executable code.

Actually, a JavaScript function is an object.

It contains:

executable code
name
parameters
internal properties
reference to where it was created

Conceptually:

Function Object

{
    code: ...
    name: "inner"
    [[Environment]] ---> Outer Scope
}

That hidden reference is the secret behind closures.

Lexical Scope

Closures cannot exist without understanding lexical scope.

Lexical means:

Determined by where the code is written.

Example

let language = "JavaScript";

function printLanguage() {
    console.log(language);
}

printLanguage();

Output

JavaScript

The function looks upward through its surrounding scopes.

Not where it is called.

Where it is defined.

Example:

let value = 10;

function outer() {

    let value = 20;

    function inner() {
        console.log(value);
    }

    return inner;
}

const fn = outer();

fn();

Output

Not 10.

Because inner() was defined inside outer().

Scope Chain

Whenever JavaScript cannot find a variable...

It walks upward.

Current Scope

↓

Outer Scope

↓

Global Scope

↓

null

Example

let country = "Egypt";

function one() {

    function two() {

        function three() {
            console.log(country);
        }

        three();
    }

    two();
}

one();

JavaScript searches:

three()

↓

two()

↓

one()

↓

Global

Eventually finds

country

Execution Context

Every function call creates an Execution Context.

It contains

Variables
Parameters
this
Scope Reference

Example

function multiply(a, b) {

    let result = a * b;

    return result;
}

multiply(5, 6);

Execution Context

multiply

a = 5

b = 6

result = 30

Normally...

After the function returns...

Everything disappears.

Except...

If another function still needs it.

That's Closure.

The Call Stack

Consider

function one() {
    two();
}

function two() {
    three();
}

function three() {
    console.log("Done");
}

one();

Call Stack

three()

two()

one()

Global

After finishing

Global

Everything pops off the stack.

Normally memory disappears.

Closures change this behavior.

Functions Have Permanent Memories

Imagine this code.

function createGreeting() {

    let greeting = "Hello";

    return function () {
        console.log(greeting);
    };
}

const greet = createGreeting();

greet();

Output

Hello

Even though

createGreeting()

already finished...

Its variable still exists.

Why?

Because the returned function still references it.

The Backpack Analogy

One of the best mental models for closures is the Backpack.

Imagine every function carries a backpack.

Inside the backpack...

JavaScript stores every variable the function might need later.

Example

function outer() {

    let count = 0;

    return function () {

        count++;

        console.log(count);

    };

}

Backpack

count = 0

Every time the function executes

count

is still there.

Output

The variable never resets because it lives inside the closure.

Closed Over Variables

Variables preserved by closures are called

Closed Over Variables

Example

function counter() {

    let value = 0;

    return function () {

        value++;

        return value;

    };

}

Here

value

is a closed over variable.

It survives every function call.

Returning Functions

Closures become useful when returning functions.

function multiplyBy(x) {

    return function(y) {
        return x * y;
    };

}

const double = multiplyBy(2);

const triple = multiplyBy(3);

console.log(double(8));

console.log(triple(8));

Output

16

24

Each returned function remembers its own value of x.

Persistent State

Without Closure

let count = 0;

function increment() {

    count++;

}

Global variables are dangerous.

With Closure

function createCounter() {

    let count = 0;

    return function() {

        count++;

        return count;

    };

}

Everything becomes private.

No global pollution.

Much safer.

Multiple Independent Closures

Every call creates a completely independent closure.

const counterA = createCounter();

const counterB = createCounter();

Memory

counterA

count = 0

Memory

counterB

count = 0

Now

console.log(counterA());

console.log(counterA());

console.log(counterB());

console.log(counterB());

console.log(counterA());

Output

Each function owns its own memory.

This is one of the most important concepts in closures.

Finite State Machines: A Complete Guide from Fundamentals to Production

Abanoub Kerols — Tue, 11 Aug 2026 07:11:24 +0000

Finite State Machines (FSMs) are one of the most useful concepts in computer science and software engineering.

They provide a structured way to model systems that behave differently depending on their current state and the events they receive.

You can find state machines everywhere:

Authentication systems
Payment processing
Order management
HTTP requests
WebSocket connections
Retry mechanisms
Background jobs
Video players
Game engines
Traffic lights
Elevators
Vending machines
Embedded systems
UI components
Distributed systems
Event-driven architectures

Despite being a relatively simple concept, State Machines become extremely powerful when used to model complex business workflows.

This article starts from the fundamentals and gradually moves toward advanced concepts, implementation techniques, software architecture, and finally a production-oriented Node.js + TypeScript project.

Part 1 — Fundamentals
Part 2 — Finite State Machines
Part 3 — FSM Design
Part 4 — FSM Implementation
Part 5 — Advanced FSM
Part 6 — Real-World Applications
Part 7 — FSM + Modern Software Architecture
Part 8 — Production Project
Conclusion

Part 1 — Fundamentals

What Is a State Machine?

A State Machine is a mathematical and software model used to represent a system that can exist in different states and change between those states when events occur.

The basic idea is:

Current State
      +
    Event
      |
      v
  Transition
      |
      v
   New State

For example, imagine an online order.

An order might have the following states:

PENDING
PAID
PROCESSING
SHIPPED
DELIVERED
CANCELLED

The order changes state when events occur.

For example:

PENDING + PAY
        ↓
       PAID

PAID + START_PROCESSING
        ↓
    PROCESSING

PROCESSING + SHIP
        ↓
     SHIPPED

SHIPPED + DELIVER
        ↓
    DELIVERED

The important idea is that the system's behavior depends on its current state.

Why Do We Need State Machines?

Without a State Machine, developers often implement workflows using large collections of:

if
else if
else

For example:

if (order.status === "pending") {
    if (event === "pay") {
        ...
    }
}

if (order.status === "paid") {
    if (event === "ship") {
        ...
    }
}

As the system grows, this can become difficult to understand.

Eventually we may end up with:

if
 ├── if
 │    ├── if
 │    └── if
 ├── else if
 │    ├── if
 │    └── if
 └── else if
      ├── if
      └── if

State Machines provide explicit structure.

Instead of asking:

"What should this giant function do?"

we ask:

"What states exist, what events can occur, and which transitions are allowed?"

This makes the system easier to:

Understand
Test
Debug
Maintain
Document
Extend
Validate

The Concept of State

A State represents the current condition of a system.

For example:

Order:
PENDING

means the order has been created but has not been paid.

Another state:

PAID

means payment has successfully completed.

Another:

SHIPPED

means the order has been handed over to the shipping process.

A state is therefore a snapshot of the system's current mode of behavior.

The Concept of Event / Input

An Event is something that happens and may cause a state transition.

Examples:

PAY
CANCEL
SHIP
DELIVER
TIMEOUT
RETRY
LOGIN
LOGOUT
DISCONNECT
CONNECT

For example:

State: PENDING

Event: PAY

The machine may transition to:

PAID

An event can come from many sources:

HTTP requests
User actions
Database events
Message queues
Timers
WebSocket messages
External services
Internal application logic

The Concept of Transition

A Transition describes how the machine moves from one state to another.

Conceptually:

FROM STATE
     |
   EVENT
     |
     v
TO STATE

Example:

PENDING --PAY--> PAID

Another example:

PAID --START_PROCESSING--> PROCESSING

A transition can also have conditions and actions.

PENDING
   |
   | PAY
   | [payment successful]
   v
PAID

The Concept of Action

An Action is something the system performs when a transition occurs.

For example:

PENDING --PAY--> PAID

The transition may execute:

sendPaymentConfirmation();

or:

createInvoice();

or:

publishOrderPaidEvent();

Actions are usually side effects.

Examples:

Send an email
Write to a database
Publish an event
Call an API
Create a log
Start a job

A useful distinction is:

State       = Where am I?
Event       = What happened?
Transition  = Where can I go?
Guard       = Am I allowed to go there?
Action      = What should I do?

State Diagram

A State Diagram visually represents the State Machine.

For example:

             PAY
   +------------------------+
   |                        v
+---------+             +--------+
| PENDING | ------------> | PAID |
+---------+             +--------+
    |                       |
    | CANCEL                | SHIP
    v                       v
+-----------+          +----------+
| CANCELLED |          |  SHIPPED |
+-----------+          +----------+
                             |
                             | DELIVER
                             v
                        +-----------+
                        | DELIVERED |
                        +-----------+

A state diagram makes the workflow much easier to understand.

A Simple Practical Example

Let's build a simple light switch.

The light can have two states:

OFF
ON

Events:

TURN_ON
TURN_OFF

Transitions:

OFF --TURN_ON--> ON
ON  --TURN_OFF--> OFF

Diagram:

       TURN_ON
 OFF ------------> ON
  ^                 |
  |                 |
  +--- TURN_OFF ----+

Implementation:

let state = "OFF";

function dispatch(event) {
    if (state === "OFF" && event === "TURN_ON") {
        state = "ON";
        return;
    }

    if (state === "ON" && event === "TURN_OFF") {
        state = "OFF";
        return;
    }

    throw new Error(`Invalid transition: ${state} + ${event}`);
}

Usage:

dispatch("TURN_ON");

console.log(state);
// ON

dispatch("TURN_OFF");

console.log(state);
// OFF

Even this tiny example demonstrates the fundamental concept.

Part 2 — Finite State Machines

Definition of a Finite State Machine

A Finite State Machine is a mathematical model consisting of a finite number of states and rules describing how the machine moves between those states based on input symbols.

A classical FSM can be represented as:

FSM = (Q, Σ, δ, q₀, F)

Where:

Q  = Set of states
Σ  = Set of input symbols
δ  = Transition function
q₀ = Initial state
F  = Set of accepting/final states

Let's understand each component.

Components of an FSM

Consider:

States:
PENDING
PAID
SHIPPED
DELIVERED

Then:

Q = {
    PENDING,
    PAID,
    SHIPPED,
    DELIVERED
}

Events form the input alphabet:

Σ = {
    PAY,
    SHIP,
    DELIVER
}

The transition function determines where the machine goes.

For example:

δ(PENDING, PAY) = PAID
δ(PAID, SHIP) = SHIPPED
δ(SHIPPED, DELIVER) = DELIVERED

The initial state is:

q₀ = PENDING

Accepting states might be:

F = {
    DELIVERED
}

Transition Function

The transition function is one of the most important concepts in FSMs.

It can be expressed as:

δ(currentState, event) = nextState

Example:

δ(PENDING, PAY) = PAID

Meaning:

If the current state is PENDING and the PAY event occurs, transition to PAID.

Another:

δ(PAID, SHIP) = SHIPPED

Initial State

The Initial State is where the machine starts.

For an order:

PENDING

For authentication:

LOGGED_OUT

For a WebSocket:

DISCONNECTED

For a payment:

CREATED

The initial state is usually represented using an arrow:

        +---------+
        | PENDING |
        +---------+
             ^
             |
           START

Final / Accepting States

A final state represents a state where the process can be considered complete.

For example:

ORDER_CREATED
     |
     v
PAID
     |
     v
SHIPPED
     |
     v
DELIVERED

Here:

DELIVERED

could be an accepting state.

However, in software engineering, not every FSM necessarily needs a final state.

For example, a WebSocket connection can continuously move between:

CONNECTED
DISCONNECTED
RECONNECTING

without ever reaching a permanent final state.

Deterministic Finite Automaton — DFA

A Deterministic Finite Automaton has exactly one possible transition for a given:

State + Input

That means:

δ(state, input) = exactly one state

For example:

PENDING + PAY → PAID

There cannot be two different outcomes for the same input.

This makes DFA behavior predictable.

Non-Deterministic Finite Automaton — NFA

A Non-Deterministic Finite Automaton can have multiple possible transitions for the same state and input.

Conceptually:

δ(state, input) → {state1, state2, ...}

For example:

A + X
 ├──> B
 └──> C

NFAs are particularly important in theoretical computer science, formal languages, regular expressions, and compiler design.

In normal application development, developers usually implement deterministic state machines because business workflows typically require predictable behavior.

DFA vs NFA

Feature	DFA	NFA
One transition per input	Yes	Not necessarily
Multiple possible states	No	Yes
Deterministic	Yes	No
Easier to execute	Yes	Usually more complex
Common in business applications	Yes	Less common
Used in theoretical CS	Yes	Yes

An important theoretical fact is that DFA and NFA have equivalent expressive power for regular languages.

Every NFA can be converted into an equivalent DFA.

Moore Machine

A Moore Machine is a finite-state machine where the output depends primarily on the current state.

Output = f(State)

For example:

State: RED
Output: STOP

State: GREEN
Output: GO

Diagram:

RED
 |
 | TIMER
 v
GREEN
 |
 | TIMER
 v
YELLOW

The output is associated with the state.

Mealy Machine

A Mealy Machine produces output based on both:

State + Input

Formally:

Output = f(State, Input)

For example:

State: LOCKED
Input: VALID_PASSWORD
Output: UNLOCK

This differs from a Moore Machine where the output is associated with the state itself.

Moore vs Mealy

Feature	Moore	Mealy
Output depends on	State	State + Input
Output associated with	State	Transition
Response timing	Often state change	Can react immediately
Complexity	Often simpler	Often more compact

In real-world software, you may encounter patterns inspired by both models.

Part 3 — FSM Design

How to Design an FSM from Requirements

A common mistake is to start coding immediately.

Instead, start with requirements.

Suppose we have:

A customer creates an order. The order can be paid, cancelled, shipped, delivered, or refunded.

We can derive the machine systematically.

Step 1 — Extract the States

Look for nouns or lifecycle conditions.

Possible states:

PENDING
PAID
PROCESSING
SHIPPED
DELIVERED
CANCELLED
REFUNDED

Step 2 — Extract Events

Look for actions or things that happen.

PAY
START_PROCESSING
SHIP
DELIVER
CANCEL
REFUND

Step 3 — Design Transitions

Now connect states and events.

PENDING + PAY
    ↓
PAID

PAID + START_PROCESSING
    ↓
PROCESSING

PROCESSING + SHIP
    ↓
SHIPPED

SHIPPED + DELIVER
    ↓
DELIVERED

Step 4 — Add Guards

Sometimes an event alone is not enough.

For example:

PENDING + PAY

does not necessarily mean the order becomes paid.

We may require:

payment.status === "SUCCESS"

Therefore:

PENDING
   |
   | PAY
   | [payment successful]
   v
PAID

The condition is called a Guard.

Example:

if (payment.status === "SUCCESS") {
    transitionTo("PAID");
}

Step 5 — Add Actions

The transition may execute side effects.

PENDING
   |
   | PAY
   |
   +--> updateOrder()
   +--> createInvoice()
   +--> sendEmail()
   +--> publishEvent()
   |
   v
PAID

Invalid Transitions

A State Machine should explicitly define what happens when an invalid event occurs.

For example:

DELIVERED + PAY

does not make sense.

Possible behavior:

throw new Error("Invalid transition");

Or:

return {
    success: false,
    error: "INVALID_TRANSITION"
};

Explicit invalid transitions are important because they prevent impossible states.

State Invariants

A State Invariant is a rule that must always be true while the machine is in a specific state.

For example:

PAID

might require:

paymentId != null

while:

SHIPPED

might require:

trackingNumber != null

Example:

if (state === "SHIPPED") {
    if (!order.trackingNumber) {
        throw new Error(
            "Shipped orders must have a tracking number"
        );
    }
}

Invariants are extremely useful for maintaining domain correctness.

State Explosion Problem

One of the biggest problems with State Machines is state explosion.

Imagine a system with:

Authentication
Payment
Shipping
Inventory
Fraud Detection
Notification

If every combination becomes a state, the number of states can become enormous.

For example:

PAYMENT_PENDING
PAYMENT_SUCCESS
PAYMENT_FAILED
PAYMENT_RETRYING

SHIPPING_PENDING
SHIPPING_PROCESSING
SHIPPING_FAILED
...

Combining everything can create hundreds or thousands of states.

This is called the:

State Explosion Problem

Solutions include:

Hierarchical State Machines
Composite States
Parallel States
Separating independent state machines
Domain decomposition
Statecharts
Event-driven architecture

Part 4 — FSM Implementation

There are many ways to implement an FSM.

FSM Using if/else

The simplest approach:

function transition(
    state: string,
    event: string
): string {

    if (state === "PENDING" && event === "PAY") {
        return "PAID";
    }

    if (state === "PAID" && event === "SHIP") {
        return "SHIPPED";
    }

    if (state === "SHIPPED" && event === "DELIVER") {
        return "DELIVERED";
    }

    throw new Error("Invalid transition");
}

This works well for very small machines.

However, it becomes difficult to maintain when the machine grows.

FSM Using switch

Another common approach:

function transition(
    state: string,
    event: string
): string {

    switch (state) {

        case "PENDING":
            if (event === "PAY") {
                return "PAID";
            }
            break;

        case "PAID":
            if (event === "SHIP") {
                return "SHIPPED";
            }
            break;

        case "SHIPPED":
            if (event === "DELIVER") {
                return "DELIVERED";
            }
            break;
    }

    throw new Error("Invalid transition");
}

This is clearer than deeply nested conditions.

But it still mixes:

State Definition
Transition Definition
Business Logic

FSM Using Objects

We can represent transitions as data.

const transitions = {
    PENDING: {
        PAY: "PAID",
    },

    PAID: {
        SHIP: "SHIPPED",
    },

    SHIPPED: {
        DELIVER: "DELIVERED",
    }
};

Then:

function transition(
    state: string,
    event: string
) {
    const nextState =
        transitions[state]?.[event];

    if (!nextState) {
        throw new Error(
            `Invalid transition: ${state} + ${event}`
        );
    }

    return nextState;
}

This approach separates configuration from execution.

FSM Using Maps

JavaScript and TypeScript Maps are useful when we want structured keys.

const transitions = new Map<string, Map<string, string>>();

transitions.set(
    "PENDING",
    new Map([
        ["PAY", "PAID"]
    ])
);

transitions.set(
    "PAID",
    new Map([
        ["SHIP", "SHIPPED"]
    ])
);

Then:

function transition(
    state: string,
    event: string
) {
    const nextState =
        transitions.get(state)?.get(event);

    if (!nextState) {
        throw new Error("Invalid transition");
    }

    return nextState;
}

Table-Driven FSM

A Table-Driven FSM represents the machine as a transition table.

Current State	Event	Next State
PENDING	PAY	PAID
PAID	PROCESS	PROCESSING
PROCESSING	SHIP	SHIPPED
SHIPPED	DELIVER	DELIVERED
PENDING	CANCEL	CANCELLED

This approach is particularly useful when the number of transitions is large.

The FSM engine can remain generic while the table contains domain-specific behavior.

Generic FSM

A reusable FSM engine might look like:

type Transition<State, Event> = {
    target: State;
    action?: () => void;
};

class FSM<State extends string, Event extends string> {

    private state: State;

    constructor(
        initialState: State,
        private transitions:
            Map<State, Map<Event, Transition<State, Event>>>
    ) {
        this.state = initialState;
    }

    getState(): State {
        return this.state;
    }

    dispatch(event: Event): void {

        const transition =
            this.transitions
                .get(this.state)
                ?.get(event);

        if (!transition) {
            throw new Error(
                `Invalid transition: ${this.state} + ${event}`
            );
        }

        transition.action?.();

        this.state = transition.target;
    }
}

Now the engine is reusable for different domains.

TypeScript FSM

TypeScript becomes particularly useful because states and events can be represented as union types.

type OrderState =
    | "PENDING"
    | "PAID"
    | "PROCESSING"
    | "SHIPPED"
    | "DELIVERED"
    | "CANCELLED";

type OrderEvent =
    | "PAY"
    | "PROCESS"
    | "SHIP"
    | "DELIVER"
    | "CANCEL";

Now TypeScript can prevent invalid values.

Example:

let state: OrderState = "PENDING";

Java FSM

A Java implementation can use enums.

enum OrderState {
    PENDING,
    PAID,
    PROCESSING,
    SHIPPED,
    DELIVERED,
    CANCELLED
}

enum OrderEvent {
    PAY,
    PROCESS,
    SHIP,
    DELIVER,
    CANCEL
}

Then:

public OrderState transition(
    OrderState state,
    OrderEvent event
) {

    return switch (state) {

        case PENDING -> {
            if (event == OrderEvent.PAY)
                yield OrderState.PAID;

            if (event == OrderEvent.CANCEL)
                yield OrderState.CANCELLED;

            throw new IllegalStateException();
        }

        case PAID -> {
            if (event == OrderEvent.PROCESS)
                yield OrderState.PROCESSING;

            throw new IllegalStateException();
        }

        default ->
            throw new IllegalStateException(
                "Invalid transition"
            );
    };
}

Python FSM

Python can implement a simple FSM using dictionaries.

transitions = {
    "PENDING": {
        "PAY": "PAID",
        "CANCEL": "CANCELLED"
    },

    "PAID": {
        "PROCESS": "PROCESSING"
    },

    "PROCESSING": {
        "SHIP": "SHIPPED"
    },

    "SHIPPED": {
        "DELIVER": "DELIVERED"
    }
}

Then:

def transition(state, event):

    next_state = transitions \
        .get(state, {}) \
        .get(event)

    if next_state is None:
        raise ValueError(
            f"Invalid transition: {state} + {event}"
        )

    return next_state

Part 5 — Advanced FSM

Hierarchical State Machines

A Hierarchical State Machine allows states to contain sub-states.

For example:

AUTHENTICATED
├── ACTIVE
├── IDLE
└── LOCKED

Instead of treating every state independently, we can create a hierarchy.

Example:

USER
 ├── LOGGED_OUT
 └── LOGGED_IN
      ├── ACTIVE
      ├── IDLE
      └── LOCKED

This reduces duplication.

Nested States

Nested states allow one state to contain other states.

For example:

ORDER
 ├── PAYMENT
 │    ├── PENDING
 │    ├── PROCESSING
 │    └── SUCCESS
 │
 └── SHIPPING
      ├── PENDING
      ├── SHIPPED
      └── DELIVERED

This is especially useful for complex workflows.

Composite States

A Composite State is a state that internally contains another state machine.

For example:

CHECKOUT

could contain:

CART
ADDRESS
PAYMENT
CONFIRMATION

So:

CHECKOUT
   |
   +-- CART
   |
   +-- ADDRESS
   |
   +-- PAYMENT
   |
   +-- CONFIRMATION

Parallel States

Sometimes multiple processes need to happen independently.

For example, an order might simultaneously have:

Payment:
SUCCESS

Shipping:
PROCESSING

Notification:
SENDING

Instead of creating:

PAYMENT_SUCCESS_SHIPPING_PROCESSING_NOTIFICATION_SENDING

we can use parallel state machines.

Conceptually:

ORDER
 |
 +---- PAYMENT
 |
 +---- SHIPPING
 |
 +---- NOTIFICATION

Each subsystem has its own state.

This dramatically reduces state explosion.

History States

History states allow a machine to remember its previous state.

Example:

ACTIVE
 ├── BROWSING
 ├── CHECKOUT
 └── PAYMENT

Suppose the user leaves the application while in:

PAYMENT

When they return, the system can restore:

PAYMENT

instead of restarting from:

BROWSING

This concept is useful in:

UI workflows
Games
Long-running processes
Distributed workflows

Entry Actions

An Entry Action runs when entering a state.

Example:

ENTER PAID
    ↓
createInvoice()

Conceptually:

const paidState = {
    entry: () => {
        createInvoice();
    }
};

Exit Actions

An Exit Action runs when leaving a state.

LEAVE PROCESSING
       ↓
cleanupProcessing()

Example:

const processingState = {
    exit: () => {
        cleanupProcessing();
    }
};

Guards

Guards are conditions that determine whether a transition is allowed.

Example:

PENDING
   |
   | PAY
   | [amount > 0]
   v
PAID

Implementation:

{
    event: "PAY",
    target: "PAID",
    guard: context => context.amount > 0
}

Guards are useful for:

Authorization
Validation
Payment checks
Inventory checks
Feature flags
Business rules

Internal Transitions

An Internal Transition handles an event without changing state.

Example:

CONNECTED
   |
   | HEARTBEAT
   |
   +----> CONNECTED

The state remains:

CONNECTED

but an action occurs:

heartbeat();

Event Queues

Events do not always need to be processed immediately.

A system may receive:

PAY
SHIP
DELIVER

very quickly.

An event queue can process them sequentially:

Event Queue

PAY
 ↓
SHIP
 ↓
DELIVER

This can help prevent race conditions.

State Persistence

If the application restarts, in-memory state disappears.

For long-running workflows, state may need to be persisted.

For example:

Database

order_id: 123
state: PAYMENT_PENDING
version: 7

When the service restarts:

Database
   ↓
Load state
   ↓
Restore FSM

Persistence is essential for production workflows.

Part 6 — Real-World Applications

Authentication

Authentication is naturally modeled using states.

LOGGED_OUT
     |
     | LOGIN
     v
AUTHENTICATING
     |
     | SUCCESS
     v
AUTHENTICATED
     |
     | LOGOUT
     v
LOGGED_OUT

Additional states:

LOCKED
MFA_REQUIRED
SESSION_EXPIRED

Order Processing

Typical order lifecycle:

CREATED
   ↓
PENDING_PAYMENT
   ↓
PAID
   ↓
PROCESSING
   ↓
SHIPPED
   ↓
DELIVERED

Alternative path:

PENDING_PAYMENT
       |
       | CANCEL
       v
   CANCELLED

Payment Processing

Payment systems commonly have:

CREATED
PENDING
PROCESSING
AUTHORIZED
CAPTURED
FAILED
REFUNDED

Example:

CREATED
   |
   | PROCESS
   v
PROCESSING
   |
   +---- SUCCESS ---> AUTHORIZED
   |
   +---- FAILURE ---> FAILED

E-Commerce Checkout

Checkout can be modeled as:

CART
 ↓
ADDRESS
 ↓
SHIPPING
 ↓
PAYMENT
 ↓
CONFIRMATION

If payment fails:

PAYMENT
   |
   | FAILURE
   v
PAYMENT_ERROR
   |
   | RETRY
   v
PAYMENT

HTTP Request Lifecycle

An HTTP request can conceptually move through:

RECEIVED
   ↓
VALIDATING
   ↓
AUTHENTICATING
   ↓
PROCESSING
   ↓
RESPONDING
   ↓
COMPLETED

Error paths:

VALIDATING
   |
   | INVALID
   v
BAD_REQUEST

AUTHENTICATING
   |
   | FAILURE
   v
UNAUTHORIZED

WebSocket Connection

WebSocket lifecycle is another excellent example.

DISCONNECTED
      |
      | CONNECT
      v
CONNECTING
      |
      | SUCCESS
      v
CONNECTED
      |
      | DISCONNECT
      v
DISCONNECTED

Failure path:

CONNECTING
     |
     | ERROR
     v
RECONNECTING

Retry Systems

Retry logic can be modeled explicitly.

IDLE
 ↓
RUNNING
 ↓
FAILED
 ↓
RETRYING
 ↓
RUNNING

Eventually:

RETRYING
   |
   | MAX_RETRIES
   v
PERMANENT_FAILURE

This is much safer than scattering retry counters across multiple functions.

Job Processing

A background job might use:

QUEUED
 ↓
PROCESSING
 ↓
COMPLETED

Failure:

PROCESSING
   |
   | FAILURE
   v
FAILED
   |
   | RETRY
   v
QUEUED

Game Development

Game characters can be modeled using:

IDLE
RUNNING
JUMPING
ATTACKING
HURT
DEAD

For example:

IDLE
 |
 | MOVE
 v
RUNNING
 |
 | JUMP
 v
JUMPING

This is a classic application of FSMs.

Traffic Lights

A traffic light is one of the simplest FSM examples.

RED
 ↓
GREEN
 ↓
YELLOW
 ↓
RED

The event could be:

TIMER_EXPIRED

Elevator

An elevator can have:

IDLE
MOVING_UP
MOVING_DOWN
DOOR_OPENING
DOOR_OPEN
DOOR_CLOSING
EMERGENCY

Transitions depend on:

Floor requests
Door sensors
Emergency signals
Movement completion

Vending Machine

A vending machine might have:

IDLE
COIN_INSERTED
PRODUCT_SELECTED
PAYMENT_COMPLETE
DISPENSING
OUT_OF_STOCK

Example:

IDLE
 |
 | INSERT_COIN
 v
COIN_INSERTED
 |
 | SELECT_PRODUCT
 v
PRODUCT_SELECTED
 |
 | PAYMENT_OK
 v
DISPENSING
 |
 | COMPLETE
 v
IDLE

Embedded Systems

FSMs are extremely common in embedded systems because embedded devices often have well-defined operating modes.

Examples:

BOOT
INITIALIZING
READY
RUNNING
ERROR
SHUTDOWN

Hardware controllers often depend heavily on explicit state transitions.

Part 7 — FSM + Modern Software Architecture

FSM + OOP

Object-Oriented Programming can model states using classes.

For example:

interface State {
    handle(event: Event): State;
}

Then:

class PendingState implements State {
    handle(event: Event): State {
        if (event === "PAY") {
            return new PaidState();
        }

        throw new Error("Invalid event");
    }
}

This is known as the State Pattern.

FSM + Functional Programming

Functional Programming can model transitions as pure functions.

function transition(
    state: State,
    event: Event
): State {
    ...
}

A pure transition function:

State + Event
      ↓
   New State

has no hidden side effects.

This makes testing very easy.

For example:

expect(
    transition("PENDING", "PAY")
).toBe("PAID");

Functional FSMs are particularly useful when combined with immutable state.

FSM + Event-Driven Architecture

In an Event-Driven Architecture, events drive state transitions.

For example:

PaymentCompleted
        |
        v
Order FSM
        |
        v
PAID

Then:

OrderPaid
    |
    +--> Notification Service
    |
    +--> Shipping Service
    |
    +--> Analytics Service

The State Machine controls the lifecycle while events connect different components.

FSM + Event Sourcing

Event Sourcing stores events instead of only storing the current state.

Instead of:

Order:
state = SHIPPED

we store:

OrderCreated
PaymentCompleted
ProcessingStarted
OrderShipped

The current state can be reconstructed by replaying events:

Initial State
     ↓
OrderCreated
     ↓
PaymentCompleted
     ↓
ProcessingStarted
     ↓
OrderShipped
     ↓
Current State = SHIPPED

This makes FSMs a natural fit for Event Sourcing.

FSM + CQRS

CQRS separates:

Commands

from:

Queries

A command can cause an FSM transition.

For example:

ShipOrderCommand
        |
        v
Order FSM
        |
        v
SHIPPED

The resulting state can then be exposed through the query side.

FSM + Distributed Systems

Distributed systems introduce additional challenges:

Network failures
Duplicate messages
Out-of-order events
Retries
Partial failures
Concurrent updates

FSMs can help define valid lifecycle transitions.

For example:

PENDING
   |
   | PAYMENT_COMPLETED
   v
PAID

If the same event arrives twice:

PAYMENT_COMPLETED
PAYMENT_COMPLETED

the second event should not create an invalid state.

This is where idempotency becomes critical.

FSM + Microservices

A microservice may own its own state machine.

For example:

Order Service
    |
    +-- Order FSM

Payment Service
    |
    +-- Payment FSM

Shipping Service
    |
    +-- Shipping FSM

Instead of one giant FSM:

Order + Payment + Shipping + Inventory

we can create several smaller machines.

This helps reduce state explosion and improves service boundaries.

FSM + Redux

Redux applications already use a state-transition model.

Conceptually:

State + Action
      ↓
   Reducer
      ↓
  New State

This is very similar to an FSM:

State + Event
      ↓
 Transition
      ↓
 New State

The key difference is that Redux is a general state-management architecture, while an FSM explicitly defines legal states and transitions.

FSM + Angular

Angular applications can benefit from FSMs for complex UI workflows.

For example:

IDLE
 |
 | SUBMIT
 v
SUBMITTING
 |
 +---- SUCCESS ---> SUCCESS
 |
 +---- ERROR -----> ERROR

This is much cleaner than maintaining several independent booleans:

isLoading
isSuccess
isError
isSubmitted

Boolean combinations can accidentally create impossible states.

For example:

isLoading = true
isSuccess = true
isError = true

An FSM prevents these invalid combinations.

FSM + RxJS

RxJS is especially useful for event streams.

For example:

events$
    .pipe(
        scan(
            (state, event) =>
                transition(state, event),
            "IDLE"
        )
    );

Conceptually:

Event Stream
     |
     v
RxJS scan()
     |
     v
FSM Transition
     |
     v
State Stream

This is a powerful combination for reactive applications.

FSM + XState

XState is a popular library for implementing state machines and statecharts.

A machine can be described declaratively:

const orderMachine = createMachine({
    initial: "pending",

    states: {
        pending: {
            on: {
                PAY: "paid"
            }
        },

        paid: {
            on: {
                SHIP: "shipped"
            }
        },

        shipped: {
            on: {
                DELIVER: "delivered"
            }
        },

        delivered: {}
    }
});

The advantage is that the state machine becomes explicit and declarative.

XState also supports advanced concepts such as:

Hierarchical states
Parallel states
Guards
Actions
Delays
Actors
State persistence

Part 8 — Production Project

Now let's design a production-oriented Order State Machine using:

Node.js
TypeScript
Express.js
PostgreSQL
Redis

The goal is not simply to demonstrate an FSM.

The goal is to design something closer to a real backend system.

Project Requirements

Our order system should support:

Creating orders
Paying orders
Processing orders
Shipping orders
Delivering orders
Cancelling orders
Retrying failures
Persisting state
Idempotency
Concurrency protection
Testing
Logging
Observability

Architecture

A possible architecture:

                    Client
                      |
                      v
                 Express API
                      |
                      v
                Order Service
                      |
             +--------+--------+
             |                 |
             v                 v
        Order FSM           Redis
             |
             v
         PostgreSQL
             |
             v
        Event Publisher
             |
       +-----+------+
       |            |
       v            v
 Notification    Shipping
 Service         Service

Order States

Let's define:

export enum OrderState {
    PENDING_PAYMENT = "PENDING_PAYMENT",
    PAID = "PAID",
    PROCESSING = "PROCESSING",
    SHIPPED = "SHIPPED",
    DELIVERED = "DELIVERED",
    CANCELLED = "CANCELLED",
    FAILED = "FAILED"
}

Order Events

export enum OrderEvent {
    PAYMENT_COMPLETED = "PAYMENT_COMPLETED",
    START_PROCESSING = "START_PROCESSING",
    SHIP = "SHIP",
    DELIVER = "DELIVER",
    CANCEL = "CANCEL",
    FAILURE = "FAILURE",
    RETRY = "RETRY"
}

Order Context

The FSM should not contain all application data inside the state itself.

We can use a Context object:

export interface OrderContext {
    orderId: string;
    customerId: string;
    amount: number;

    paymentId?: string;
    trackingNumber?: string;

    retryCount: number;
}

The state answers:

What stage is the order in?

The context answers:

What data belongs to this order?

This separation is extremely useful.

Transition Definition

We can define transitions using configuration.

interface Transition {
    target: OrderState;

    guard?: (
        context: OrderContext
    ) => boolean;

    action?: (
        context: OrderContext
    ) => Promise<void>;
}

Then:

const transitions = {
    [OrderState.PENDING_PAYMENT]: {
        [OrderEvent.PAYMENT_COMPLETED]: {
            target: OrderState.PAID
        },

        [OrderEvent.CANCEL]: {
            target: OrderState.CANCELLED
        }
    },

    [OrderState.PAID]: {
        [OrderEvent.START_PROCESSING]: {
            target: OrderState.PROCESSING
        }
    },

    [OrderState.PROCESSING]: {
        [OrderEvent.SHIP]: {
            target: OrderState.SHIPPED
        },

        [OrderEvent.FAILURE]: {
            target: OrderState.FAILED
        }
    },

    [OrderState.SHIPPED]: {
        [OrderEvent.DELIVER]: {
            target: OrderState.DELIVERED
        }
    },

    [OrderState.FAILED]: {
        [OrderEvent.RETRY]: {
            target: OrderState.PROCESSING
        }
    }
};

FSM Engine

Now we can create a generic engine.

class OrderStateMachine {

    constructor(
        private state: OrderState,
        private context: OrderContext
    ) {}

    getState(): OrderState {
        return this.state;
    }

    async dispatch(
        event: OrderEvent
    ): Promise<OrderState> {

        const stateTransitions =
            transitions[this.state];

        const transition =
            stateTransitions?.[event];

        if (!transition) {
            throw new Error(
                `Invalid transition: ${this.state} + ${event}`
            );
        }

        if (
            transition.guard &&
            !transition.guard(this.context)
        ) {
            throw new Error(
                "Transition guard failed"
            );
        }

        if (transition.action) {
            await transition.action(
                this.context
            );
        }

        this.state = transition.target;

        return this.state;
    }
}

Persistence

A production FSM should not rely only on memory.

We can persist the state in PostgreSQL.

Example database structure:

CREATE TABLE orders (
    id UUID PRIMARY KEY,
    customer_id UUID NOT NULL,
    amount NUMERIC NOT NULL,
    state VARCHAR(50) NOT NULL,
    version INTEGER NOT NULL DEFAULT 0,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL
);

The important fields are:

state
version

The version helps with optimistic concurrency.

Optimistic Concurrency

Imagine two requests arrive simultaneously:

Request A: PAY
Request B: CANCEL

Both read:

state = PENDING_PAYMENT
version = 10

If both update the row without protection, we may get inconsistent behavior.

Optimistic concurrency solves this.

Example:

UPDATE orders
SET
    state = $1,
    version = version + 1
WHERE
    id = $2
    AND version = $3;

If zero rows are updated, someone else modified the order.

Then we reject the operation.

Idempotency

Distributed systems can deliver the same event more than once.

For example:

PAYMENT_COMPLETED
PAYMENT_COMPLETED

If the first event changes:

PENDING_PAYMENT → PAID

the second event should not perform the payment transition again.

We can store processed event IDs.

CREATE TABLE processed_events (
    event_id UUID PRIMARY KEY,
    processed_at TIMESTAMP NOT NULL
);

Before processing:

Does event_id exist?

YES → Ignore
NO  → Process

This is a common production pattern.

Retry / Failure States

Failures are normal in distributed systems.

For example:

PROCESSING
    |
    | FAILURE
    v
FAILED
    |
    | RETRY
    v
PROCESSING

We can store:

retryCount

Then:

if (context.retryCount >= 3) {
    transitionTo("PERMANENT_FAILURE");
}

A more complete model might be:

PROCESSING
    |
    | ERROR
    v
RETRYING
    |
    +---- RETRY ----> PROCESSING
    |
    +---- MAX_RETRIES ---> FAILED

Exponential Backoff

Retries should usually not happen immediately.

A common strategy is exponential backoff:

Attempt 1 → 1 second
Attempt 2 → 2 seconds
Attempt 3 → 4 seconds
Attempt 4 → 8 seconds

Formula:

delay = baseDelay × 2^retryCount

With jitter:

delay =
    baseDelay × 2^retryCount
    + randomJitter

This helps prevent many workers from retrying simultaneously.

Express API

We can expose an endpoint:

POST /orders/:id/events

Request:

{
    "event": "PAYMENT_COMPLETED"
}

Controller:

router.post(
    "/orders/:id/events",
    async (req, res) => {

        const { id } = req.params;
        const { event } = req.body;

        const order =
            await orderRepository.findById(id);

        if (!order) {
            return res
                .status(404)
                .json({
                    message: "Order not found"
                });
        }

        const machine =
            new OrderStateMachine(
                order.state,
                order.context
            );

        const newState =
            await machine.dispatch(event);

        await orderRepository.updateState(
            id,
            newState
        );

        return res.json({
            orderId: id,
            state: newState
        });
    }
);

Better Production Design

However, in a real production application, we should avoid directly coupling:

Controller
   ↓
FSM
   ↓
Database

A better architecture is:

Controller
    ↓
Application Service
    ↓
Domain FSM
    ↓
Repository
    ↓
Database

For example:

HTTP Controller
      |
      v
OrderApplicationService
      |
      v
OrderStateMachine
      |
      v
OrderRepository
      |
      v
PostgreSQL

This follows separation of concerns.

Domain Layer

The FSM belongs to the domain layer because it contains business rules.

Example:

class Order {

    constructor(
        public readonly id: string,
        private state: OrderState,
        private context: OrderContext
    ) {}

    async apply(
        event: OrderEvent
    ) {

        const machine =
            new OrderStateMachine(
                this.state,
                this.context
            );

        this.state =
            await machine.dispatch(event);
    }

    getState() {
        return this.state;
    }
}

The domain should not know about:

Express
HTTP
Redis
PostgreSQL

This keeps business logic independent.

Application Layer

The Application Service coordinates operations.

class OrderApplicationService {

    constructor(
        private readonly repository:
            OrderRepository
    ) {}

    async handleEvent(
        orderId: string,
        event: OrderEvent
    ) {

        const order =
            await this.repository
                .findById(orderId);

        if (!order) {
            throw new Error(
                "Order not found"
            );
        }

        await order.apply(event);

        await this.repository.save(order);

        return order;
    }
}

Repository Layer

The repository handles persistence.

interface OrderRepository {

    findById(
        id: string
    ): Promise<Order | null>;

    save(
        order: Order
    ): Promise<void>;
}

The domain remains independent from PostgreSQL.

Event Publishing

After a successful transition:

PENDING_PAYMENT
       |
       | PAYMENT_COMPLETED
       v
      PAID

we may publish:

OrderPaid

Other services can subscribe.

Order Service
     |
     | OrderPaid
     v
Message Broker
     |
     +----> Notification
     |
     +----> Analytics
     |
     +----> Shipping

Transactional Consistency

A critical production problem is:

Update Database
      +
Publish Event

What happens if:

Database update succeeds
Event publishing fails

Now the order is:

PAID

but other services never receive:

OrderPaid

A common solution is the Transactional Outbox Pattern.

Transactional Outbox

Instead of immediately publishing the event:

Database
   |
   +-- Update Order
   |
   +-- Insert Outbox Event

Both happen inside the same database transaction.

Example:

BEGIN;

UPDATE orders
SET state = 'PAID'
WHERE id = $1;

INSERT INTO outbox_events (
    id,
    type,
    payload
)
VALUES (
    $2,
    'OrderPaid',
    $3
);

COMMIT;

Then a background worker reads the outbox:

Outbox
   |
   v
Publisher
   |
   v
Message Broker

This significantly improves reliability.

Observability

A production FSM should be observable.

Important metrics include:

state_transition_total
state_transition_failure_total
invalid_transition_total
fsm_processing_duration
retry_total

Logs should include:

{
    "orderId": "123",
    "from": "PENDING_PAYMENT",
    "event": "PAYMENT_COMPLETED",
    "to": "PAID"
}

This makes debugging much easier.

State Transition Logging

Every transition should ideally be traceable.

Order 123

PENDING_PAYMENT
      |
      | PAYMENT_COMPLETED
      v
PAID
      |
      | START_PROCESSING
      v
PROCESSING
      |
      | SHIP
      v
SHIPPED

A transition log can contain:

orderId
previousState
event
newState
timestamp
actor
correlationId

Testing an FSM

One of the biggest advantages of FSMs is testability.

We can test transitions independently.

Example:

describe(
    "Order State Machine",
    () => {

        it(
            "should transition from pending to paid",
            async () => {

                const machine =
                    new OrderStateMachine(
                        OrderState.PENDING_PAYMENT,
                        context
                    );

                await machine.dispatch(
                    OrderEvent.PAYMENT_COMPLETED
                );

                expect(
                    machine.getState()
                ).toBe(OrderState.PAID);
            }
        );
    }
);

Testing Invalid Transitions

We should also test invalid operations.

it(
    "should reject shipping before payment",
    async () => {

        const machine =
            new OrderStateMachine(
                OrderState.PENDING_PAYMENT,
                context
            );

        await expect(
            machine.dispatch(
                OrderEvent.SHIP
            )
        ).rejects.toThrow();
    }
);

This is extremely important.

A good FSM test suite should test:

Valid transitions
Invalid transitions
Guards
Actions
Retries
Concurrency
Persistence
Recovery

Testing State Invariants

Suppose:

SHIPPED

requires:

trackingNumber

Test:

expect(() =>
    createOrder({
        state: OrderState.SHIPPED,
        trackingNumber: undefined
    })
).toThrow();

This ensures invalid states cannot exist.

Property-Based Testing

FSMs are also excellent candidates for property-based testing.

We can define properties such as:

The machine must never reach an undefined state.

Or:

DELIVERED must never transition back to PENDING_PAYMENT.

Or:

CANCELLED orders cannot become SHIPPED.

This allows automated generation of event sequences.

Example sequence:

PAY
SHIP
DELIVER
CANCEL
PAY
SHIP

The test verifies that no invalid state is produced.

Concurrency Testing

Production systems must test concurrent requests.

Example:

Request A:
PAYMENT_COMPLETED

Request B:
CANCEL

Both arrive simultaneously.

The system must guarantee that only one valid transition succeeds.

Optimistic locking can enforce this.

Version = 10

Request A:
10 → 11

Request B:
10 → FAIL

Request B receives:

CONCURRENT_MODIFICATION

and can retry after reloading the latest state.

Complete Production Flow

Let's put everything together.

                   HTTP Request
                        |
                        v
                Express Controller
                        |
                        v
             Application Service
                        |
                        v
                  Load Order
                        |
                        v
                Current State
                        |
                        v
                  FSM Engine
                        |
              +---------+---------+
              |                   |
           Guard                Invalid
              |                   |
              v                   v
        Transition            Reject Event
              |
              v
          New State
              |
              v
       Database Transaction
              |
        +-----+------+
        |            |
        v            v
   Update Order   Outbox Event
        |            |
        +-----+------+
              |
              v
            Commit
              |
              v
       Background Publisher
              |
              v
        Message Broker
              |
       +------+------+
       |             |
       v             v
 Notification     Shipping

This architecture demonstrates why State Machines are useful beyond simple examples.

Recommended Project Structure

A production Node.js + TypeScript project could look like:

src/
│
├── domain/
│   └── order/
│       ├── order.entity.ts
│       ├── order-state.ts
│       ├── order-event.ts
│       ├── order-state-machine.ts
│       └── order.errors.ts
│
├── application/
│   └── order/
│       ├── create-order.service.ts
│       ├── process-order-event.service.ts
│       └── cancel-order.service.ts
│
├── infrastructure/
│   ├── database/
│   │   ├── postgres.ts
│   │   └── order.repository.ts
│   │
│   ├── messaging/
│   │   └── event-publisher.ts
│   │
│   └── cache/
│       └── redis.ts
│
├── interfaces/
│   └── http/
│       ├── controllers/
│       ├── routes/
│       └── middleware/
│
├── workers/
│   └── outbox.worker.ts
│
├── config/
│   └── environment.ts
│
└── server.ts

This separates:

Domain
Application
Infrastructure
Interfaces
Workers
Configuration

FSM Design Principles

When designing a State Machine, follow these principles.

1. Keep States Meaningful

A state should represent a meaningful business condition.

Bad:

STEP_1
STEP_2
STEP_3

Better:

PENDING_PAYMENT
PAID
PROCESSING
SHIPPED
DELIVERED

2. Keep Events Explicit

Avoid vague events such as:

UPDATE
CHANGE
PROCESS

Prefer:

PAYMENT_COMPLETED
ORDER_SHIPPED
DELIVERY_CONFIRMED
PAYMENT_FAILED

Explicit events make systems easier to understand.

3. Make Invalid Transitions Impossible

Do not allow:

DELIVERED → PAID

unless the domain explicitly requires it.

4. Separate State from Context

State:

PAID

Context:

{
    orderId,
    customerId,
    amount,
    paymentId
}

This prevents the state from becoming a giant data structure.

5. Keep Side Effects Controlled

The transition logic should be predictable.

Instead of mixing everything:

transition() {
    updateDatabase();
    sendEmail();
    callStripe();
    publishKafkaMessage();
    updateRedis();
}

prefer:

FSM
 ↓
Domain Event
 ↓
Application / Infrastructure

This gives better separation.

Common FSM Mistakes

Mistake 1 — Using Too Many Boolean Flags

Instead of:

isLoading
isSuccess
isError
isCancelled

use:

IDLE
LOADING
SUCCESS
ERROR
CANCELLED

One state is often better than many independent booleans.

Mistake 2 — Allowing Impossible States

For example:

isLoading = true
isSuccess = true

An FSM can eliminate these combinations.

Mistake 3 — Putting Everything Into One FSM

Don't create:

OrderPaymentShippingInventoryNotificationFSM

Split independent concerns.

Order FSM
Payment FSM
Shipping FSM
Notification FSM

Mistake 4 — Ignoring Concurrency

An FSM in memory may be correct locally but incorrect in a distributed system.

Always consider:

Concurrent events
Duplicate events
Out-of-order events
Retries
Persistence

Mistake 5 — Treating Persistence as an Afterthought

If state matters, persist it.

For critical workflows:

state
version
transition history
event ID
timestamp

can be extremely valuable.

FSM vs State Pattern

FSM and the State Pattern are related but not identical.

A State Machine focuses on:

States
Events
Transitions
Rules

The State Pattern is an Object-Oriented design pattern where behavior is delegated to state objects.

Example:

Order
  |
  +-- PendingState
  +-- PaidState
  +-- ShippedState

The State Pattern can be used to implement an FSM, but an FSM does not have to use the State Pattern.

FSM vs Workflow Engine

An FSM is usually focused on:

States + Transitions

A Workflow Engine often provides much more:

Long-running workflows
Timers
Retries
Persistence
Distributed execution
Compensation
Human approval
Recovery

Examples of workflow-oriented systems include platforms such as Temporal.

FSMs can be part of a workflow engine, but they are conceptually smaller.

FSM vs Event-Driven Architecture

These concepts are also different.

FSM:

State + Event → New State

Event-driven architecture:

Event → Subscribers

They can work together.

For example:

PaymentCompleted
       |
       v
Order FSM
       |
       v
PAID
       |
       v
OrderPaid
       |
       +----> Notification
       +----> Shipping
       +----> Analytics

FSM Mental Model

A very useful mental model is:

STATE
  +
EVENT
  +
GUARD
  |
  v
TRANSITION
  |
  +---- ACTION
  |
  v
NEW STATE

Or even more simply:

Where am I?
     +
What happened?
     +
Am I allowed?
     ↓
Where do I go?
     +
What should I do?

The Most Important Formula

The core of a State Machine can be summarized as:

δ(State, Event) → State

For a more practical application:

Transition =
    Current State
    +
    Event
    +
    Optional Guard
    →
    Next State
    +
    Optional Action

A Complete Example

Consider an online order:

                    PAYMENT_COMPLETED
       +--------------------------------------+
       |                                      |
       v                                      |
+------------------+                    +----------+
| PENDING_PAYMENT  | -----------------> |   PAID   |
+------------------+                    +----------+
       |                                      |
       | CANCEL                               | PROCESS
       v                                      v
+-------------+                         +-------------+
|  CANCELLED  |                         | PROCESSING  |
+-------------+                         +-------------+
                                              |
                                              | SHIP
                                              v
                                         +---------+
                                         | SHIPPED |
                                         +---------+
                                              |
                                              | DELIVER
                                              v
                                         +-----------+
                                         | DELIVERED |
                                         +-----------+

The machine guarantees that:

PENDING_PAYMENT
    → PAID
    → PROCESSING
    → SHIPPED
    → DELIVERED

is valid.

But:

PENDING_PAYMENT
    → SHIPPED

is invalid.

And:

DELIVERED
    → PENDING_PAYMENT

is also invalid.

This is the core value of State Machines:

They make valid behavior explicit and invalid behavior enforceable.

When Should You Use an FSM?

FSMs are especially useful when:

A system has a lifecycle
There are explicit states
Transitions depend on events
Invalid transitions matter
Business rules are complex
The workflow needs to be visualized
You need strong testability
You need predictable behavior

Examples:

Authentication
Payments
Orders
Checkout
Jobs
Retries
Connections
UI workflows
Games
Embedded systems

When Should You Avoid an FSM?

Not every problem needs one.

If the logic is simply:

const result = calculatePrice(input);

there is probably no reason to introduce an FSM.

FSMs are useful when there is a meaningful lifecycle.

If there are no meaningful states or transitions, an FSM may add unnecessary complexity.

Final Production Checklist

Before deploying an FSM-based system, ask:

[ ] Are all states explicitly defined?
[ ] Are all events explicitly defined?
[ ] Is there a clear initial state?
[ ] Are valid transitions documented?
[ ] Are invalid transitions rejected?
[ ] Are guards tested?
[ ] Are actions controlled?
[ ] Are invariants enforced?
[ ] Is state persisted when necessary?
[ ] Is concurrency handled?
[ ] Is idempotency implemented?
[ ] Are duplicate events handled?
[ ] Are retries controlled?
[ ] Is exponential backoff used?
[ ] Is transition history observable?
[ ] Are metrics available?
[ ] Are logs structured?
[ ] Are transitions unit tested?
[ ] Are invalid transitions tested?
[ ] Is state explosion controlled?
[ ] Are independent workflows separated?

Conclusion

Finite State Machines are much more than a theoretical computer science concept.

They provide a practical way to model systems that evolve through well-defined states.

The fundamental model is simple:

State
 +
Event
 ↓
Transition
 ↓
New State

But this simple abstraction can scale into powerful architectural patterns.

We can use:

Guards
Actions
Entry / Exit Actions
Hierarchical States
Nested States
Parallel States
History
Event Queues
Persistence
Concurrency Control
Idempotency
Retries
Event Sourcing
CQRS
Event-Driven Architecture
Microservices

In modern backend systems, State Machines are particularly valuable for workflows such as:

Orders
Payments
Authentication
Jobs
Retries
Shipping
Subscriptions
WebSocket Connections

The most important lesson is not how to write an FSM.

It is how to think in terms of explicit states, explicit events, explicit transitions, and explicit business rules.

Instead of writing code that implicitly describes what the system can do, a State Machine lets us explicitly define:

What states are possible?
What events can occur?
Which transitions are legal?
Which transitions are invalid?
What conditions must be satisfied?
What side effects should happen?
How should the system recover from failure?

That is why State Machines remain useful from simple applications to production distributed systems.

At the simplest level:

State + Event → Next State

At the production level:

Event
  ↓
Validation
  ↓
Current State
  ↓
Guard
  ↓
FSM Transition
  ↓
New State
  ↓
Persistence
  ↓
Outbox Event
  ↓
Message Broker
  ↓
Distributed Consumers
  ↓
Observability

Once you start seeing software systems as state transitions, many complex workflows become easier to design, reason about, test, and maintain.

A well-designed State Machine does not merely describe what a system does — it defines what the system is allowed to do.

Functional Programming vs Object-Oriented Programming in JavaScript

Abanoub Kerols — Thu, 06 Aug 2026 07:47:32 +0000

A Practical Guide to FP, OOP, Prototypes, Composition, Currying, Immutability, and Encapsulation

Modern JavaScript supports multiple programming paradigms. Two of the most important are:

Object-Oriented Programming (OOP)
Functional Programming (FP)

JavaScript is particularly interesting because it is a multi-paradigm language. You can build applications using classes and inheritance, functional composition and higher-order functions, or combine both approaches.

Understanding these paradigms is more important than simply knowing their syntax. The real skill is knowing how the underlying concepts affect architecture, state management, testability, reusability, and maintainability.

This article explores the major concepts behind both paradigms and shows how they work internally in JavaScript.

Programming Paradigms
Functional Programming
Object-Oriented Programming
Abstract Classes and Inheritance
Prototypes and Constructors
Composition Over Inheritance
Functional Composition
Factory Functions
Currying
Partial Application
Higher-Order Functions
Lambda Functions
Recursive Functions
Pure Functions
Immutable vs Mutable State
Private Properties and Methods
FP vs OOP
Using FP and OOP Together
Real-World Architecture Example
Best Practices
Conclusion

1. Programming Paradigms

A programming paradigm is a way of thinking about how software should be structured.

Instead of asking:

"What syntax should I use?"

we should ask:

"How should I model the problem?"

Two major approaches are:

Programming
│
├── Imperative
│   ├── Procedural
│   └── Object-Oriented
│
└── Declarative
    └── Functional

Consider a simple requirement:

Calculate the total price of products.

An imperative approach might say:

let total = 0;

for (const product of products) {
    total += product.price;
}

A functional approach describes the transformation:

const total = products.reduce(
    (sum, product) => sum + product.price,
    0
);

The difference is not just syntax.

It is about how we reason about the program.

2. Functional Programming

Functional Programming treats computation primarily as the evaluation of functions.

The central idea is:

Build programs by composing small functions that transform data.

For example:

const addTax = price => price * 1.14;

const addShipping = price => price + 100;

const calculateOrderTotal = price =>
    addShipping(addTax(price));

console.log(calculateOrderTotal(1000));

Each function performs one transformation.

Conceptually:

price
  ↓
addTax
  ↓
addShipping
  ↓
result

Functional programming emphasizes:

Pure functions
Immutability
Function composition
Higher-order functions
Referential transparency
Declarative programming
Avoiding shared mutable state

3. Object-Oriented Programming

Object-Oriented Programming organizes software around objects.

An object combines:

State + Behavior

For example:

class BankAccount {
    constructor(balance) {
        this.balance = balance;
    }

    deposit(amount) {
        this.balance += amount;
    }

    withdraw(amount) {
        if (amount > this.balance) {
            throw new Error("Insufficient funds");
        }

        this.balance -= amount;
    }
}

Usage:

const account = new BankAccount(1000);

account.deposit(500);
account.withdraw(200);

console.log(account.balance);

The object owns both:

State
  ↓
balance

Behavior
  ↓
deposit()
withdraw()

OOP commonly uses:

Encapsulation
Abstraction
Inheritance
Polymorphism
Composition

4. Abstract Classes and Inheritance

Abstraction means exposing what an object can do while hiding implementation details.

For example:

class PaymentProcessor {
    processPayment(amount) {
        throw new Error("processPayment() must be implemented");
    }
}

Then:

class StripePayment extends PaymentProcessor {
    processPayment(amount) {
        console.log(`Processing ${amount} using Stripe`);
    }
}

And:

class PayPalPayment extends PaymentProcessor {
    processPayment(amount) {
        console.log(`Processing ${amount} using PayPal`);
    }
}

Now we can work with the abstraction:

function checkout(processor, amount) {
    processor.processPayment(amount);
}

Usage:

checkout(new StripePayment(), 500);
checkout(new PayPalPayment(), 500);

This demonstrates polymorphism.

The caller doesn't need to know the concrete implementation.

Important JavaScript Difference

Unlike Java or C#, JavaScript does not have a traditional abstract class keyword.

We usually simulate abstraction using:

class PaymentProcessor {
    processPayment() {
        throw new Error("Not implemented");
    }
}

Or we can use TypeScript:

abstract class PaymentProcessor {
    abstract processPayment(amount: number): void;
}

class StripePayment extends PaymentProcessor {
    processPayment(amount: number) {
        console.log(amount);
    }
}

5. Prototypes and Constructors

JavaScript is fundamentally prototype-based.

Classes are largely syntactic sugar over JavaScript's prototype system.

Consider:

function User(name) {
    this.name = name;
}

User.prototype.sayHello = function () {
    console.log(`Hello ${this.name}`);
};

Now:

const user1 = new User("John");
const user2 = new User("Alice");

Both objects can access:

user1.sayHello();
user2.sayHello();

But the method does not need to be copied into every object.

Instead:

user1
   │
   ▼
User.prototype
   │
   └── sayHello()

user2
   │
   ▼
User.prototype
   │
   └── sayHello()

This is the prototype chain.

What Does `new` Do?

When we write:

const user = new User("John");

JavaScript roughly performs these steps:

1. Create a new object
2. Link object to User.prototype
3. Execute User with `this`
4. Return the object

Conceptually:

const user = Object.create(User.prototype);

User.call(user, "John");

This is not a complete specification-level implementation, but it provides the right mental model.

6. Composition Over Inheritance

Inheritance can become problematic when hierarchies become deep.

Imagine:

Animal
  ↓
Mammal
  ↓
FlyingMammal
  ↓
FlyingSwimmingMammal

As requirements grow, the hierarchy becomes difficult to maintain.

Composition takes another approach.

Instead of asking:

"What is this object?"

we ask:

"What capabilities does this object have?"

For example:

const canWalk = state => ({
    walk() {
        console.log(`${state.name} is walking`);
    }
});

const canFly = state => ({
    fly() {
        console.log(`${state.name} is flying`);
    }
});

const canSwim = state => ({
    swim() {
        console.log(`${state.name} is swimming`);
    }
});

Now:

const bird = {
    name: "Eagle",
    ...canWalk({ name: "Eagle" }),
    ...canFly({ name: "Eagle" })
};

And:

const duck = {
    name: "Duck",
    ...canWalk({ name: "Duck" }),
    ...canFly({ name: "Duck" }),
    ...canSwim({ name: "Duck" })
};

Instead of building a large inheritance tree, we compose capabilities.

7. Functional Composition

Functional composition means combining functions to create a new function.

Suppose we have:

const double = x => x * 2;

const square = x => x * x;

We can compose them:

const doubleThenSquare = x =>
    square(double(x));

Then:

doubleThenSquare(3);

Execution:

3
 ↓
double
 ↓
6
 ↓
square
 ↓
36

Building a `compose` Function

We can generalize the concept:

const compose = (...functions) =>
    value =>
        functions.reduceRight(
            (result, fn) => fn(result),
            value
        );

Now:

const doubleThenSquare = compose(
    square,
    double
);

console.log(doubleThenSquare(3));

Result:

We can also create pipe, which executes from left to right:

const pipe = (...functions) =>
    value =>
        functions.reduce(
            (result, fn) => fn(result),
            value
        );

Then:

const processPrice = pipe(
    price => price * 1.14,
    price => price + 100,
    price => Math.round(price)
);

Usage:

processPrice(1000);

This style is very common in functional JavaScript.

8. Factory Functions

A factory function is a function that creates objects.

Instead of:

class User {
    constructor(name) {
        this.name = name;
    }

    greet() {
        return `Hello ${this.name}`;
    }
}

we can use:

function createUser(name) {
    return {
        name,

        greet() {
            return `Hello ${this.name}`;
        }
    };
}

Usage:

const user = createUser("John");

console.log(user.greet());

Factory functions are particularly useful when combined with composition.

Factory + Composition

const createUser = name => ({
    name
});

const withAuthentication = user => ({
    ...user,

    login() {
        console.log(`${user.name} logged in`);
    }
});

const withPermissions = user => ({
    ...user,

    hasPermission(permission) {
        return permission === "admin";
    }
});

Now:

const admin = withPermissions(
    withAuthentication(
        createUser("John")
    )
);

This gives us a composable object.

9. Currying

Currying transforms a function that takes multiple arguments into a sequence of functions that each take one argument.

Normal function:

const add = (a, b) => a + b;

Curried version:

const add = a => b => a + b;

Usage:

add(10)(20);

Result:

Why Is Currying Useful?

Because it allows us to specialize functions.

For example:

const multiply = a => b => a * b;

const double = multiply(2);
const triple = multiply(3);

Now:

double(10); // 20
triple(10); // 30

We created specialized functions from a general function.

10. Partial Application

Currying and partial application are related but not identical.

Partial application means:

Fix some arguments now and provide the rest later.

Consider:

const createUser = (role, name, age) => ({
    role,
    name,
    age
});

We can specialize the role:

const createAdmin = (name, age) =>
    createUser("admin", name, age);

Now:

createAdmin("John", 30);

Conceptually:

createUser
   │
   ├── role = admin
   │
   ▼
createAdmin

Partial application is useful for creating reusable domain-specific functions.

11. Higher-Order Functions

A higher-order function is a function that:

Receives another function as an argument
Returns a function
Or both

For example:

function executeOperation(a, b, operation) {
    return operation(a, b);
}

Usage:

executeOperation(10, 20, (a, b) => a + b);

Result:

JavaScript's array methods are excellent examples:

map()
filter()
reduce()
some()
every()
find()

For example:

const users = [
    { name: "John", active: true },
    { name: "Alice", active: false },
    { name: "Bob", active: true }
];

const activeUsers = users.filter(
    user => user.active
);

filter is a higher-order function because it receives a function.

12. Lambda Functions

In JavaScript, lambda functions are generally represented by arrow functions.

Example:

const square = x => x * x;

Compared to:

function square(x) {
    return x * x;
}

Arrow functions provide concise syntax.

They are especially useful for callbacks:

users.map(user => user.name);

Important: Arrow Functions and `this`

Arrow functions do not create their own this.

Example:

const user = {
    name: "John",

    regular() {
        console.log(this.name);
    },

    arrow: () => {
        console.log(this.name);
    }
};

The regular method receives this based on how it is called.

The arrow function captures this lexically from the surrounding scope.

This difference becomes extremely important in JavaScript applications.

13. Recursive Functions

A recursive function calls itself.

The classic example is factorial:

function factorial(n) {
    if (n === 0) {
        return 1;
    }

    return n * factorial(n - 1);
}

Execution:

factorial(4)

4 × factorial(3)

4 × 3 × factorial(2)

4 × 3 × 2 × factorial(1)

4 × 3 × 2 × 1

24

The critical part is the base case:

if (n === 0) {
    return 1;
}

Without a base case, recursion can continue indefinitely until the call stack is exhausted.

Recursive Tree Traversal

Recursion becomes especially useful when working with hierarchical data.

const tree = {
    value: 1,

    children: [
        {
            value: 2,
            children: []
        },
        {
            value: 3,
            children: [
                {
                    value: 4,
                    children: []
                }
            ]
        }
    ]
};

We can traverse it recursively:

function traverse(node) {
    console.log(node.value);

    for (const child of node.children) {
        traverse(child);
    }
}

This pattern appears in:

File systems
DOM trees
ASTs
Organizational structures
Dependency graphs
Nested menus

14. Pure Functions

A pure function has two important properties:

1. Same input → same output

const add = (a, b) => a + b;

For:

add(2, 3);

the result will always be:

2. No side effects

A pure function doesn't modify external state.

Impure:

let total = 0;

function add(amount) {
    total += amount;
}

The function changes external state.

Pure:

function add(total, amount) {
    return total + amount;
}

Now the state is explicit.

Why Pure Functions Matter

Pure functions are easier to:

Test
Debug
Cache
Reason about
Parallelize
Reuse

For example:

expect(add(10, 20)).toBe(30);

There is no dependency on external state.

15. Immutable vs Mutable State

Mutable state means changing existing data.

const user = {
    name: "John",
    age: 30
};

user.age = 31;

The same object was modified.

With immutable updates:

const updatedUser = {
    ...user,
    age: 31
};

Now:

user
 ↓
original object

updatedUser
 ↓
new object

The original remains unchanged.

Why Immutability Matters

Immutability makes state transitions easier to reason about.

Consider:

const state1 = {
    count: 0
};

const state2 = {
    ...state1,
    count: state1.count + 1
};

const state3 = {
    ...state2,
    count: state2.count + 1
};

We now have:

state1 → state2 → state3

This idea is fundamental to state-management systems.

For example, reducer-style state updates:

function reducer(state, action) {
    switch (action.type) {
        case "INCREMENT":
            return {
                ...state,
                count: state.count + 1
            };

        default:
            return state;
    }
}

Instead of modifying state directly, the reducer returns a new state.

Mutable State Isn't Always Bad

It is important not to turn immutability into a dogma.

Mutation can sometimes be more efficient.

For example:

const array = [];

for (let i = 0; i < 1_000_000; i++) {
    array.push(i);
}

Repeatedly creating new arrays could introduce unnecessary allocations.

The important question is:

Where is mutation allowed, and who owns it?

A practical architecture may use:

Immutable at boundaries
        ↓
Controlled mutation internally
        ↓
Immutable result

This gives you predictable APIs without forcing every internal operation to allocate new objects.

16. Private Properties and Methods

Encapsulation means hiding internal implementation details.

Modern JavaScript supports private class fields using #.

class BankAccount {
    #balance;

    constructor(balance) {
        this.#balance = balance;
    }

    deposit(amount) {
        this.#balance += amount;
    }

    getBalance() {
        return this.#balance;
    }
}

Now:

const account = new BankAccount(1000);

account.deposit(500);

console.log(account.getBalance());

But:

account.#balance;

is invalid.

The property is truly private.

Private Methods

JavaScript also supports private methods:

class UserService {
    #validate(user) {
        if (!user.email) {
            throw new Error("Email is required");
        }
    }

    createUser(user) {
        this.#validate(user);

        console.log("User created");
    }
}

The caller can use:

service.createUser(user);

but cannot directly call:

service.#validate(user);

17. FP vs OOP

Let's compare the mental models.

Concept	Functional Programming	Object-Oriented Programming
Main abstraction	Functions	Objects
Primary focus	Data transformations	State + behavior
State	Prefer immutable	Often encapsulated/mutable
Reuse	Composition	Inheritance/composition
Side effects	Minimized	Encapsulated
Polymorphism	Higher-order functions / protocols	Inheritance / interfaces
Data flow	Explicit	Often object-centered
Testing	Pure functions are easy	Objects require state setup
Best for	Transformations	Stateful domains

But this table should not lead to:

"FP is better."

or:

"OOP is better."

The better question is:

"Which model fits this problem?"

18. Using FP and OOP Together

Real-world JavaScript applications frequently combine both paradigms.

For example:

class UserService {
    constructor(repository) {
        this.repository = repository;
    }

    async getActiveUsers() {
        const users = await this.repository.findAll();

        return users
            .filter(user => user.active)
            .map(user => ({
                id: user.id,
                name: user.name
            }));
    }
}

The service uses OOP:

class UserService

and functional programming internally:

.filter(...)
.map(...)

This is often a very practical approach.

19. Real-World Architecture Example

Consider an e-commerce system.

We might have:

OrderService
     │
     ├── Repository
     │
     ├── PaymentService
     │
     └── NotificationService

OOP can model long-lived services:

class OrderService {
    constructor(orderRepository, paymentService) {
        this.orderRepository = orderRepository;
        this.paymentService = paymentService;
    }

    async createOrder(order) {
        // orchestration
    }
}

FP can handle transformations:

const calculateSubtotal = items =>
    items.reduce(
        (total, item) =>
            total + item.price * item.quantity,
        0
    );

Tax:

const calculateTax = rate => subtotal =>
    subtotal * rate;

Discount:

const applyDiscount = discount => total =>
    total - discount;

Then compose the calculation:

const calculateTotal = (items, taxRate, discount) => {
    const subtotal = calculateSubtotal(items);

    const tax = calculateTax(taxRate)(subtotal);

    return applyDiscount(discount)(
        subtotal + tax
    );
};

The architecture becomes:

        OOP
         │
         ▼
   Application Services
         │
         ▼
       FP
         │
         ▼
 Pure Domain Logic
         │
         ▼
       Data

This separation can be extremely powerful.

20. A More Advanced Example

Suppose we need to process orders.

Raw data:

const orders = [
    {
        id: 1,
        status: "completed",
        total: 500
    },
    {
        id: 2,
        status: "pending",
        total: 300
    },
    {
        id: 3,
        status: "completed",
        total: 700
    }
];

We can build small pure functions:

const isCompleted = order =>
    order.status === "completed";

const getTotal = order =>
    order.total;

const sum = (a, b) =>
    a + b;

Then:

const revenue = orders
    .filter(isCompleted)
    .map(getTotal)
    .reduce(sum, 0);

Result:

Each function has one responsibility.

This makes the code easy to test:

isCompleted(orders[0]); // true

getTotal(orders[0]); // 500

sum(500, 700); // 1200

21. A Practical Decision Framework

Instead of choosing FP or OOP based on preference, consider the problem.

Use Functional Programming heavily when:

Data transformation is the main problem.
You have pipelines of operations.
You need predictable business rules.
You want highly testable logic.
You want to minimize shared state.

Examples:

Data processing
Validation
Calculations
Reducers
Transformations
Parsing
Mapping
Filtering
Aggregation

Use OOP heavily when:

You have long-lived entities.
Objects own state.
You need encapsulation.
You have complex domain behavior.
You need dependency injection.
You are modeling external resources/services.

Examples:

PaymentService
DatabaseRepository
FileStorage
ConnectionPool
Order
UserSession
Cache

Use Composition when:

You have reusable capabilities.

Instead of:

BaseUser
  ↓
AdminUser
  ↓
SuperAdminUser

consider:

User
 + Authentication
 + Authorization
 + Logging
 + Auditing

22. The Deeper Idea: Data vs Behavior

One of the biggest philosophical differences between FP and OOP is how they organize behavior.

OOP tends to ask:

"Who owns this behavior?"

For example:

order.calculateTotal();

The behavior belongs to order.

FP tends to ask:

"What transformation should happen to this data?"

For example:

calculateTotal(order);

Neither approach is universally correct.

They represent two different ways of modeling the same problem.

23. Referential Transparency

A function is referentially transparent when we can replace the function call with its result without changing program behavior.

For example:

const square = x => x * x;

Then:

square(5)

can always be replaced with:

Consider:

const result = square(5) + square(5);

We can reason about it as:

const result = 25 + 25;

This property makes functional code easier to reason about.

Compare that with:

let counter = 0;

function increment() {
    return ++counter;
}

Calling:

increment();

cannot be replaced with a fixed value because the result depends on external state.

24. Closures and Functional Programming

Closures are another fundamental JavaScript feature.

Consider:

function createCounter() {
    let count = 0;

    return function () {
        count++;

        return count;
    };
}

Usage:

const counter = createCounter();

counter(); // 1
counter(); // 2
counter(); // 3

The returned function remembers:

count

even after createCounter() has finished.

This creates private state without using a class.

25. Factory Functions + Closures

This allows us to build encapsulated objects using FP techniques.

function createBankAccount(initialBalance) {
    let balance = initialBalance;

    return {
        deposit(amount) {
            balance += amount;
        },

        withdraw(amount) {
            if (amount > balance) {
                throw new Error("Insufficient funds");
            }

            balance -= amount;
        },

        getBalance() {
            return balance;
        }
    };
}

Now:

const account = createBankAccount(1000);

account.deposit(500);

console.log(account.getBalance());

But:

account.balance;

is:

undefined

because balance exists only inside the closure.

This is an alternative form of encapsulation.

26. OOP Encapsulation vs Closure Encapsulation

OOP:

class BankAccount {
    #balance;

    constructor(balance) {
        this.#balance = balance;
    }
}

Functional:

function createBankAccount(balance) {
    return {
        getBalance() {
            return balance;
        }
    };
}

Both can provide encapsulation.

The difference is the underlying model.

OOP
Object
 ├── State
 └── Methods

FP
Closure
 ├── Captured State
 └── Functions

27. A Production-Oriented Hybrid Design

A mature JavaScript application might look like:

┌──────────────────────────────┐
│        Controllers           │
└──────────────┬───────────────┘
               │
┌──────────────▼───────────────┐
│      Application Services    │
│             OOP              │
└──────────────┬───────────────┘
               │
┌──────────────▼───────────────┐
│       Domain Functions       │
│             FP               │
│                              │
│ Pure calculations            │
│ Validation                   │
│ Transformations              │
└──────────────┬───────────────┘
               │
┌──────────────▼───────────────┐
│      Infrastructure          │
│                              │
│ Database                     │
│ Redis                        │
│ APIs                         │
└──────────────────────────────┘

The important architectural idea is:

Keep business logic as pure as possible and isolate side effects.

For example:

const calculateOrderTotal = order => {
    // pure
};

class OrderService {
    constructor(repository) {
        this.repository = repository;
    }

    async createOrder(order) {
        const total = calculateOrderTotal(order);

        return this.repository.save({
            ...order,
            total
        });
    }
}

The calculation is pure.

The repository handles the side effect.

28. Practical Rules

When writing JavaScript applications, these rules are useful.

Rule 1: Prefer small functions

Instead of:

processEverything();

prefer:

validateOrder();
calculateTotal();
applyDiscount();
saveOrder();
sendNotification();

Rule 2: Minimize shared mutable state

Shared mutable state creates hidden dependencies.

Prefer:

const newState = updateState(oldState);

over uncontrolled global mutation.

Rule 3: Prefer composition over deep inheritance

Instead of:

A
└── B
    └── C
        └── D

consider:

A + capability1 + capability2 + capability3

Rule 4: Keep side effects at the boundaries

Pure:

const calculateTax = (price, rate) =>
    price * rate;

Side effect:

await database.save(order);

Don't mix them unnecessarily.

Rule 5: Use encapsulation where state has invariants

For example:

class BankAccount {
    #balance;

    withdraw(amount) {
        if (amount > this.#balance) {
            throw new Error("Insufficient funds");
        }

        this.#balance -= amount;
    }
}

The object protects its invariant.

29. Final Mental Model

The easiest way to remember the concepts is:

FUNCTIONAL PROGRAMMING
        │
        ├── Functions
        ├── Pure Functions
        ├── Immutability
        ├── Composition
        ├── Currying
        ├── Higher-Order Functions
        └── Recursion


OBJECT-ORIENTED PROGRAMMING
        │
        ├── Objects
        ├── Encapsulation
        ├── Abstraction
        ├── Inheritance
        ├── Polymorphism
        └── Composition


JAVASCRIPT
        │
        ├── Prototype-based
        ├── First-class Functions
        ├── Closures
        ├── Classes
        ├── Functional Features
        └── Object-oriented Features

The most important lesson is that JavaScript does not force you to choose one paradigm.

You can combine them.

For example:

class OrderService {
    constructor(repository) {
        this.repository = repository;
    }

    async process(order) {
        const validated = validateOrder(order);

        const total = calculateTotal(validated);

        const finalOrder = {
            ...validated,
            total
        };

        return this.repository.save(finalOrder);
    }
}

Here:

OrderService uses OOP
validateOrder can be a pure function
calculateTotal can be functional
{ ...validated } uses immutable-style updates
repository is encapsulated through the service
save() represents a side effect

This hybrid style is often more useful in real-world applications than trying to build an entire system using only FP or only OOP.

Conclusion

Functional Programming and Object-Oriented Programming are not simply collections of syntax features. They are different ways of reasoning about software.

FP focuses on:

Transforming data through predictable functions.

OOP focuses on:

Encapsulating state and behavior inside objects.

JavaScript gives developers the ability to use both.

Understanding prototypes explains how JavaScript objects actually work. Understanding composition helps avoid unnecessarily complex inheritance hierarchies. Higher-order functions, currying, and closures provide powerful functional abstractions. Pure functions and immutability make business logic easier to test and reason about. Private properties and methods provide strong encapsulation when objects need to protect their internal state.

The real goal is not to become "an FP developer" or "an OOP developer."

The goal is to become a developer who can choose the right abstraction for the problem.

Use objects when ownership and state matter.

Use functions when transformation and predictability matter.

Use composition when you need flexibility.

Use immutability when predictable state transitions matter.

And combine the paradigms when the system benefits from both.

Advanced Multithreading in Node.js

Abanoub Kerols — Mon, 03 Aug 2026 08:18:48 +0000

Event Loop Internals, libuv Architecture, V8 Isolates, Shared Memory, Worker Pools, and Performance Optimization

Introduction

Node.js has earned its reputation as a highly efficient runtime for building scalable network applications. One of the biggest misconceptions about Node.js is that it is "single-threaded." While JavaScript execution begins on a single thread, the Node.js runtime is built on top of a sophisticated architecture involving multiple native threads, asynchronous I/O, an event-driven execution model, and optional JavaScript worker threads for true parallel computation.

Understanding these internal mechanisms is essential for building high-performance backend systems, especially when working with CPU-intensive workloads, microservices, data processing pipelines, real-time analytics, or AI-powered applications.

This article explores Node.js from the inside out, covering the Event Loop, libuv, V8 Isolates, Worker Threads, shared memory, synchronization primitives, worker pools, and production performance tuning.

Node.js Runtime Architecture

A simplified Node.js runtime consists of several major components.

                    Node.js Runtime

                +---------------------+
                |    JavaScript Code  |
                +----------+----------+
                           |
                     V8 JavaScript Engine
                           |
                +----------+----------+
                |     Event Loop      |
                +----------+----------+
                           |
                        libuv
          +---------------+----------------+
          |                                |
     Thread Pool                  Operating System
          |                                |
   File System, Crypto,             Network, Timers,
   Compression, DNS                 TCP/UDP, Epoll, IOCP

Each layer has a specific responsibility.

V8 executes JavaScript.
The Event Loop schedules asynchronous callbacks.
libuv provides cross-platform asynchronous I/O.
The Operating System performs low-level operations.

Understanding V8

V8 is Google's high-performance JavaScript engine written in C++.

Its responsibilities include:

Parsing JavaScript
Compiling JavaScript
Optimizing frequently executed code
Garbage collection
Memory management
Executing JavaScript

Every Node.js process starts with one V8 instance.

However, every Worker Thread owns its own independent V8 instance.

This design is extremely important.

What is a V8 Isolate?

A V8 Isolate is an independent JavaScript execution environment.

Each isolate contains:

Heap
Stack
Global Object
Garbage Collector
Event Loop
Execution Context

Think of an isolate as a completely separate JavaScript world.

Node Process

      |

+-------------+
| Main Isolate|
+-------------+

      |

Worker Thread

      |

+--------------+
| Worker Isolate|
+--------------+

Variables inside one isolate cannot be directly accessed from another.

// main.js

let counter = 10;

Worker:

console.log(counter);

Output:

ReferenceError

Workers do not share JavaScript memory by default.

Why Use Isolates?

Isolates solve several difficult problems.

They provide:

Memory safety
Independent garbage collection
Crash isolation
Better scalability

If one Worker crashes, the main thread continues executing.

Deep Dive into the Event Loop

The Event Loop is responsible for deciding what JavaScript executes next.

Its job is to repeatedly inspect multiple queues and execute callbacks when they become ready.

Internally, every iteration is called a tick.

while(true){

    execute_ready_callbacks();

}

Of course, the actual implementation is significantly more complex.

Event Loop Phases

The Event Loop consists of six major phases.

          Event Loop

        +--------------+
        | Timers       |
        +--------------+
               |
               V
        +--------------+
        | Pending I/O  |
        +--------------+
               |
               V
        +--------------+
        | Idle/Prepare |
        +--------------+
               |
               V
        +--------------+
        | Poll         |
        +--------------+
               |
               V
        +--------------+
        | Check        |
        +--------------+
               |
               V
        +--------------+
        | Close        |
        +--------------+

Every phase has its own callback queue.

Timers Phase

Handles callbacks from:

setTimeout()

setInterval()

Example

setTimeout(() => {

    console.log("Timer");

},1000);

The callback is executed after the timer expires.

Pending Callbacks

Processes certain operating-system callbacks.

Examples:

TCP errors
Some network operations

Most developers rarely interact with this phase directly.

Idle / Prepare

Used internally by libuv.

Applications typically never execute code here.

Poll Phase

This is the most important phase.

It performs:

Waiting for I/O
Executing completed I/O callbacks
Determining whether timers are ready

Examples:

Database queries
Reading files
Incoming HTTP requests

Check Phase

Processes callbacks scheduled by:

setImmediate()

Example

setImmediate(() => {

    console.log("Immediate");

});

Close Callbacks

Handles resource cleanup.

Example

socket.on("close",()=>{
    console.log("Socket Closed");
});

Microtasks

Microtasks execute before the Event Loop continues.

Examples include:

Promise.resolve()

queueMicrotask()

process.nextTick()

Example

console.log(1);

Promise.resolve().then(()=>{

    console.log(2);

});

console.log(3);

Output

1
3
2

process.nextTick()

This queue has even higher priority.

console.log(1);

process.nextTick(()=>{

    console.log(2);

});

console.log(3);

Output

1
3
2

However,

process.nextTick()

executes before Promise callbacks.

Priority:

Current Code

↓

nextTick Queue

↓

Promise Queue

↓

Event Loop

Overusing process.nextTick() can starve the Event Loop because it continuously schedules work before the loop proceeds to later phases.

libuv Architecture

libuv is a cross-platform asynchronous library written in C.

Node.js relies heavily on it.

Responsibilities include:

Event Loop implementation
Thread Pool
TCP
UDP
Pipes
DNS
File System
Timers
Process management

Without libuv, Node.js would not exist in its current form.

libuv Thread Pool

The default thread pool contains:

4 Threads

Configurable via:

UV_THREADPOOL_SIZE=8

Supported tasks include:

fs
crypto
zlib
dns.lookup()

Not all asynchronous APIs use the thread pool.

Networking generally relies on the operating system's non-blocking I/O facilities instead.

CPU-Bound vs I/O-Bound Workloads

I/O-bound tasks spend most of their time waiting for external resources.

Examples:

HTTP requests
Database queries
Reading files
Network communication

CPU-bound tasks spend most of their time performing calculations.

Examples:

Image processing
AI inference
Video encoding
Compression algorithms
Mathematical simulations

Worker Threads are designed primarily for CPU-bound JavaScript.

Worker Threads Architecture

Node Process

        |

+--------------------+
| Main Thread        |
+--------------------+

        |

-------------------------------

Worker 1

Worker 2

Worker 3

Worker 4

Each Worker owns:

Separate Event Loop
Separate Heap
Separate Garbage Collector
Separate V8 Isolate

Workers execute JavaScript in parallel across multiple CPU cores.

Message Passing

Communication happens through structured messages.

Main Thread

worker.postMessage({

    task:100

});

Worker

parentPort.on("message",(msg)=>{

    console.log(msg.task);

});

Messages are serialized using the structured clone algorithm, similar to the Web Workers API.

Structured Clone Algorithm

Structured cloning copies JavaScript objects safely between isolates.

Supported examples include:

Objects
Arrays
Maps
Sets
TypedArrays
Dates

Unsupported examples include:

Functions
DOM nodes
Native resources
Closures

Copying very large objects repeatedly can become expensive.

Transferable Objects

Transferable Objects eliminate expensive copying.

Instead of cloning memory, ownership moves from one thread to another.

const buffer = new ArrayBuffer(1024);

worker.postMessage(

    buffer,

    [buffer]

);

After transfer:

Main thread:

Buffer

↓

Detached

Worker:

Buffer

↓

Owns Memory

Advantages:

Zero-copy transfer
Lower latency
Reduced memory pressure

Transferable Objects are ideal for large binary payloads such as images, audio, or serialized datasets.

SharedArrayBuffer

Sometimes copying data is undesirable.

Instead, multiple workers can access the same memory.

const shared = new SharedArrayBuffer(4);

const array = new Int32Array(shared);

Main thread:

array[0] = 50;

Worker:

console.log(array[0]);

Output

Both threads reference the same memory region.

Race Conditions

Shared memory introduces synchronization challenges.

Suppose two workers execute:

counter++;

Both threads may read the same value before writing back.

Example:

Worker A reads 5

Worker B reads 5

Worker A writes 6

Worker B writes 6

Expected:

Actual:

This is called a race condition.

Atomics

JavaScript provides atomic operations through the Atomics API.

Atomics.add(array,0,1);

This guarantees that the increment is performed safely.

Common atomic operations include:

add
sub
load
store
exchange
compareExchange
wait
notify

Atomics are essential whenever multiple threads modify shared memory concurrently.

Lock-Free Programming

Instead of traditional mutexes, JavaScript relies on atomic instructions.

Advantages:

Low latency
Reduced contention
High scalability

Disadvantages:

More difficult to design correctly
Easier to introduce subtle concurrency bugs

Lock-free algorithms should be used only when necessary and carefully tested.

Worker Pools

Creating Workers repeatedly is expensive.

Every Worker initializes:

V8
Heap
Garbage Collector
Event Loop

This startup cost can dominate small tasks.

Instead:

Request

↓

Worker Pool

↓

Existing Worker

Workers remain alive and are reused.

Piscina

Piscina is one of the most popular Worker Thread pool libraries for Node.js.

Features include:

Automatic scheduling
Worker reuse
Queue management
Task prioritization
Backpressure support
Async task execution
Performance monitoring

Example

const Piscina = require("piscina");

const piscina = new Piscina({

    filename:"worker.js"

});

const result = await piscina.run({

    number:1000

});

Piscina simplifies worker management and is a common choice for production services that perform repeated CPU-intensive tasks.

Memory Considerations

Each Worker owns:

Heap
Stack
Garbage Collector

Creating too many workers increases:

RAM usage
Context switching
CPU overhead

A common guideline is to keep the number of active workers close to the number of available CPU cores, then benchmark for your workload rather than assuming more workers always improve throughput.

Garbage Collection

Each isolate performs garbage collection independently.

Benefits:

No global pause
Better responsiveness
Lower contention

Large shared memory allocations are not managed like normal JavaScript objects, so developers should still monitor overall memory usage carefully.

Measuring Performance

Never assume optimization works.

Measure first.

Useful metrics include:

Response time
Throughput
CPU utilization
Memory usage
Event Loop delay
Worker queue length
Garbage collection pauses

Event Loop Lag

One important production metric is Event Loop latency.

A blocked Event Loop results in:

Slow API responses
Delayed timers
Poor user experience

Monitoring Event Loop delay can reveal CPU bottlenecks long before they become outages.

Benchmarking Strategy

A reliable benchmarking process typically follows these steps:

Establish a baseline without Worker Threads.
Identify CPU-bound hotspots using a profiler.
Introduce Worker Threads or a worker pool.
Measure latency, throughput, CPU utilization, and memory consumption under representative load.
Compare results across multiple runs.
Choose the design that improves real-world performance rather than microbenchmarks.

Benchmark in an environment that closely resembles production. Development laptops often produce misleading results due to different hardware and background workloads.

Profiling Tools

Common tools for production analysis include:

Node.js Inspector
Chrome DevTools
node --prof
clinic.js
autocannon for HTTP load testing
perf_hooks for application timing
Operating system tools such as top, htop, Task Manager, or Performance Monitor

Using profiling before optimization helps avoid spending time on code that is not actually limiting performance.

Best Practices

Keep the Event Loop responsive by avoiding long synchronous computations.
Use asynchronous APIs for I/O instead of creating Workers.
Reserve Worker Threads for CPU-bound JavaScript.
Prefer a Worker Pool such as Piscina instead of creating Workers per request.
Use Transferable Objects for large binary payloads to avoid unnecessary copying.
Use SharedArrayBuffer only when multiple threads truly need shared state.
Protect shared memory with Atomics whenever concurrent writes are possible.
Continuously monitor Event Loop latency, CPU utilization, memory usage, and queue lengths in production.
Benchmark every optimization and validate improvements under realistic workloads.

Conclusion

Node.js is far more than a single-threaded JavaScript runtime. Beneath its simple programming model lies a sophisticated architecture composed of the V8 engine, isolated JavaScript execution environments, the libuv asynchronous I/O library, a native thread pool, and Worker Threads capable of true parallel computation. Together, these components allow Node.js to efficiently handle thousands of concurrent connections while also scaling CPU-intensive workloads across multiple processor cores.

Mastering advanced multithreading in Node.js requires understanding how the Event Loop schedules work, how libuv delegates native operations, how V8 isolates provide memory isolation, how SharedArrayBuffer and Atomics enable safe shared-memory programming, and how worker pools such as Piscina reduce thread management overhead. Combined with careful profiling, benchmarking, and production monitoring, these techniques enable developers to build highly scalable, low-latency systems that make full use of modern multicore hardware while preserving the simplicity and productivity that have made Node.js one of the most popular server-side platforms.

Multithreading in Node.js: A Complete Guide with Theory and Practical Examples

Abanoub Kerols — Wed, 29 Jul 2026 07:48:34 +0000

When developers first learn Node.js, they often hear the phrase:

"Node.js is single-threaded."

While this statement is technically true, it is also incomplete.

Modern Node.js is capable of utilizing multiple threads, background workers, thread pools, and even multiple CPU cores. Understanding how these components work is essential for building high-performance applications.

This article explains the theory behind multithreading in Node.js, how it differs from traditional multithreading, and when to use Worker Threads, the Event Loop, the libuv Thread Pool, and the Cluster module.

What is a Thread?

A thread is the smallest unit of execution inside a process.

Imagine a restaurant.

The restaurant is the process.
Each chef is a thread.
Every chef can prepare food independently.

One chef means one task at a time.

Four chefs mean four tasks can run simultaneously.

Many programming languages create multiple threads that execute code in parallel.

Examples:

Java
C#
C++
Go

Node.js approaches concurrency differently.

Is Node.js Single-Threaded?

Yes—and no.

JavaScript Execution

JavaScript itself runs on a single main thread.

Only one JavaScript function executes at a time.

console.log("Task A");
console.log("Task B");
console.log("Task C");

Output

Task A
Task B
Task C

Everything executes sequentially.

However...

Node.js internally uses multiple threads for many operations.

Examples include:

File System
DNS
Compression
Cryptography
Worker Threads

So while JavaScript execution is single-threaded, Node.js as a runtime is definitely not.

Why Was Node.js Designed This Way?

Traditional servers often assign:

1 Request
      ↓
1 Thread

If 5,000 users connect simultaneously...

5000 Requests
↓

5000 Threads

Creating thousands of threads consumes huge amounts of:

Memory
CPU
Context switching

Node.js instead uses:

5000 Requests
↓

One Event Loop
↓

Non-blocking I/O

This dramatically reduces memory usage.

Process vs Thread

Process	Thread
Independent program	Part of a process
Own memory	Shares process memory
Heavy	Lightweight
Expensive to create	Cheap to create
Communication is slower	Communication is faster

Example

Google Chrome

Process
 ├── Thread
 ├── Thread
 ├── Thread
 └── Thread

Node.js normally runs as:

Process

Main Thread

But it can create additional threads when needed.

Understanding the Event Loop

The Event Loop is the heart of Node.js.

Imagine a receptionist.

People arrive with different requests.

Some requests take seconds.

Instead of waiting...

The receptionist sends long tasks elsewhere and immediately serves the next customer.

That is exactly how Node.js behaves.

Example

const fs = require("fs");

console.log("Start");

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

console.log("End");

Output

Start
End
Finished Reading

Why?

Reading the file happens in the background.

The Event Loop continues processing other work.

Blocking vs Non-Blocking Code

Blocking

while(true){}

The Event Loop freezes.

Nothing else executes.

Non-blocking

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

console.log("Running...");

Output

Running...
Done

The timer runs asynchronously.

The Hidden Thread Pool

Node.js uses libuv, a powerful C library.

libuv maintains a thread pool.

Default size:

4 Threads

These threads perform expensive tasks.

Examples:

File system
DNS lookup
Crypto
Compression

Example

const crypto = require("crypto");

crypto.pbkdf2(
    "password",
    "salt",
    100000,
    64,
    "sha512",
    () => {
        console.log("Done");
    }
);

The hash calculation runs in a background thread.

The Event Loop remains free.

Increasing Thread Pool Size

Default:

4 Threads

Can be changed.

Linux

UV_THREADPOOL_SIZE=8 node app.js

Windows

set UV_THREADPOOL_SIZE=8
node app.js

Useful for heavy:

Crypto
File processing

Not useful for CPU-intensive JavaScript loops.

Why CPU-Heavy Tasks Are a Problem

Consider this function.

function heavyWork(){

    let total = 0;

    for(let i=0;i<1e10;i++){
        total += i;
    }

    return total;
}

Now imagine an Express server.

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

    heavyWork();

    res.send("Done");

});

During calculation...

Every other request waits.

Even though Node.js supports asynchronous I/O, JavaScript itself is still executing on one thread.

Solution: Worker Threads

Node.js introduced Worker Threads to solve CPU-intensive problems.

Each Worker has:

Separate JavaScript engine
Separate Event Loop
Separate memory

Diagram

Main Thread

      |

-------------------------
|           |           |

Worker1   Worker2   Worker3

Each worker executes JavaScript independently.

Creating a Worker

main.js

const Worker = require("worker_threads").Worker;

const worker = new Worker("./worker.js");

worker.on("message",(msg)=>{
    console.log(msg);
});

worker.js

const { parentPort } = require("worker_threads");

let total = 0;

for(let i=0;i<1e9;i++){

    total += i;

}

parentPort.postMessage(total);

The heavy computation runs on another thread.

The main thread remains responsive.

Communication Between Threads

Workers communicate using messages.

Main Thread

worker.postMessage(100);

Worker

parentPort.on("message",(number)=>{

    console.log(number);

});

Everything is event-based.

Passing Data to Workers

worker.postMessage({
    name:"John",
    age:30
});

Worker

parentPort.on("message",(user)=>{

    console.log(user.name);

});

Shared Memory

Normally...

Workers do NOT share variables.

Instead...

They copy data.

However, Node.js supports

SharedArrayBuffer

which allows memory sharing.

Useful for:

Scientific computing
Large datasets
Machine Learning

Worker Lifecycle

Create Worker

↓

Execute

↓

Send Message

↓

Finish

↓

Terminate

Terminate manually

worker.terminate();

Error Handling

worker.on("error",(err)=>{

    console.log(err);

});

Exit event

worker.on("exit",(code)=>{

    console.log(code);

});

Worker Threads vs Child Process

Worker Thread	Child Process
Same process	New process
Lightweight	Heavy
Faster communication	Slower
Shared memory possible	No shared memory
Better for CPU work	Better for running external programs

Worker Threads vs Cluster

Cluster creates:

CPU Core 1

Node Process

CPU Core 2

Node Process

CPU Core 3

Node Process

Every process has:

Own Event Loop
Own Memory
Own V8 Engine

Cluster improves scalability for web servers.

Worker Threads improve CPU-heavy computations.

Worker Threads vs libuv Thread Pool

Many developers confuse these.

Worker Threads	libuv Thread Pool
Execute JavaScript	Execute native C/C++ operations
Created manually	Automatic
CPU-intensive work	I/O operations
Separate Event Loop	No JavaScript execution

Real-World Use Cases

Worker Threads are excellent for:

Image processing
Video encoding
PDF generation
Machine Learning inference
Encryption
Large mathematical calculations
Data analytics
CSV processing
Financial calculations
Compression

Avoid using them for:

Database queries
HTTP requests
Reading files
Network communication

Those are already asynchronous.

Performance Considerations

Creating a Worker has a cost.

Avoid:

One Request

↓

Create Worker

↓

Destroy Worker

Better:

Worker Pool

↓

Reuse Existing Workers

Libraries such as Piscina provide efficient worker pools.

Common Mistakes

Mistake 1

Using Workers for simple tasks.

Creating a Worker is slower than executing tiny calculations.

Mistake 2

Blocking the Event Loop.

while(true){}

Never perform long-running synchronous loops on the main thread.

Mistake 3

Confusing asynchronous programming with multithreading.

Asynchronous code is not automatically multithreaded.

await fetch(url);

This is asynchronous I/O, not parallel JavaScript execution.

Mistake 4

Ignoring message serialization costs.

Large objects passed between workers are copied unless transferable or shared-memory mechanisms are used.

Best Practices

Keep the Event Loop free for handling incoming requests.
Use asynchronous APIs for I/O operations whenever possible.
Use Worker Threads only for CPU-bound tasks.
Reuse workers through a worker pool instead of constantly creating new ones.
Monitor CPU and memory usage before introducing multithreading.
Transfer or share large buffers efficiently when performance matters.
Handle worker errors and exits gracefully.
Benchmark your application to verify that workers actually improve performance.

Summary

Node.js executes JavaScript on a single main thread, but the runtime itself uses multiple mechanisms to achieve concurrency and parallelism. The Event Loop efficiently handles asynchronous I/O without blocking, while the libuv Thread Pool transparently performs operations such as file system access, DNS lookups, cryptography, and compression. For CPU-intensive JavaScript tasks, Worker Threads enable true parallel execution by running JavaScript in separate threads with independent V8 instances and Event Loops. At a larger scale, the Cluster module distributes incoming requests across multiple Node.js processes to utilize all available CPU cores.

Choosing the right tool depends on the nature of the workload: use asynchronous I/O for network and file operations, rely on the libuv Thread Pool for supported native tasks, adopt Worker Threads for computationally expensive JavaScript, and use clustering when scaling web servers across multiple cores. Understanding these components allows developers to build Node.js applications that are responsive, scalable, and capable of efficiently utilizing modern multi-core hardware.

Mastering Angular ControlValueAccessor (CVA): The Complete Guide with Real-World Examples

Abanoub Kerols — Sun, 12 Jul 2026 17:30:00 +0000

Angular provides many built-in form controls such as <input>, <textarea>, <select>, and checkboxes. These elements work seamlessly with both Template-driven Forms and Reactive Forms because Angular already knows how to communicate with them.

But what happens when you build your own reusable component?

Imagine creating:

A star rating component ⭐
A color picker 🎨
A date range selector 📅
A phone number input 📞
A rich text editor ✍️

By default, Angular has no idea how these components should exchange values with a form.

This is exactly why ControlValueAccessor (CVA) exists.

What is ControlValueAccessor?
ControlValueAccessor is an Angular interface that acts as a bridge between:

Angular Forms API
Your custom component

It teaches Angular how to:

Write values into your component
Read values from your component
Mark the component as touched
Enable or disable the component

Without CVA, Angular treats your component as just another HTML element.

With CVA, Angular treats it exactly like a native <input>.

Think of CVA Like a Translator

Imagine two people speaking different languages.

Angular Forms speaks one language.
Your custom component speaks another.

ControlValueAccessor translates between them.

Reactive Form
      |
      |
ControlValueAccessor
      |
      |
Custom Component

Why Do We Need It?
Suppose you build this component:
<app-counter></app-counter>

<form [formGroup]="form">

    <app-counter formControlName="quantity"></app-counter>

</form>

Angular immediately throws an error:
No value accessor for form control with name: 'quantity'

Why?

Because Angular doesn't know:

How to pass the value
How to receive updates
When the control becomes touched
How to disable it

CVA solves all of this.

The ControlValueAccessor Interface
The interface looks like this:

export interface ControlValueAccessor {

    writeValue(obj: any): void;

    registerOnChange(fn: any): void;

    registerOnTouched(fn: any): void;

    setDisabledState?(isDisabled: boolean): void;

}

Only four methods.

But each has an important responsibility.

Method 1 — writeValue()
Angular calls this whenever the form value changes.

Example:

this.form.patchValue({
    quantity: 10
});

Angular internally executes:
component.writeValue(10);

Your implementation:

writeValue(value: number): void {
    this.value = value;
}

Think of it as:
Form ➜ Component

Method 2 — registerOnChange()
Angular gives you a callback function.

Whenever your component value changes, you must call it.

registerOnChange(fn: any): void {
    this.onChange = fn;
}

Later:

increment() {
    this.value++;
    this.onChange(this.value);
}

Flow:

User Clicks
      ↓
Component Updates
      ↓
onChange(value)
      ↓
Angular Form Updates

Think of it as:
Component ➜ Form

Method 3 — registerOnTouched()
Angular also provides another callback.

This tells Angular that the user interacted with the control.

registerOnTouched(fn: any): void {
    this.onTouched = fn;
}

When should you call it?

Usually on:

blur
click
focus lost
first interaction

Example:

onBlur() {
    this.onTouched();
}

Now Angular knows:
control.touched === true

Method 4 — setDisabledState()
When someone writes:

control.disable();

Angular calls:

setDisabledState(true);

Implementation

setDisabledState(isDisabled: boolean): void {
    this.disabled = isDisabled;
}

Then your template:
<button [disabled]="disabled">
Now disabling works exactly like native inputs.

The Data Flow

Form.setValue()
        |
        |
writeValue()
        |
        |
Custom Component
        |
User Interaction
        |
        |
onChange()
        |
        |
Reactive Form

A Complete Counter Component
counter.component.ts

import {
    Component,
    forwardRef
} from '@angular/core';

import {
    ControlValueAccessor,
    NG_VALUE_ACCESSOR
} from '@angular/forms';

@Component({
    selector: 'app-counter',

    templateUrl: './counter.component.html',

    providers: [
        {
            provide: NG_VALUE_ACCESSOR,
            useExisting: forwardRef(() => CounterComponent),
            multi: true
        }
    ]
})
export class CounterComponent implements ControlValueAccessor {

    value = 0;

    disabled = false;

    onChange = (_: number) => {};

    onTouched = () => {};

    writeValue(value: number): void {
        this.value = value ?? 0;
    }

    registerOnChange(fn: any): void {
        this.onChange = fn;
    }

    registerOnTouched(fn: any): void {
        this.onTouched = fn;
    }

    setDisabledState(isDisabled: boolean): void {
        this.disabled = isDisabled;
    }

    increment() {
        if (this.disabled) return;

        this.value++;

        this.onChange(this.value);

        this.onTouched();
    }

    decrement() {
        if (this.disabled) return;

        this.value--;

        this.onChange(this.value);

        this.onTouched();
    }

}

counter.component.html

<button (click)="decrement()" [disabled]="disabled">
    -
</button>

<span>{{ value }}</span>

<button (click)="increment()" [disabled]="disabled">
    +
</button>

Parent Component

form = this.fb.group({

    quantity: [5]

});

<form [formGroup]="form">

    <app-counter formControlName="quantity"></app-counter>

</form>

Everything now works exactly like:
<input formControlName="quantity">

Understanding the Lifecycle
When the page loads:

Angular Creates Component
        ↓
registerOnChange()
        ↓
registerOnTouched()
        ↓
writeValue(initialValue)

When the user clicks "+" :

value++
      ↓
onChange(value)
      ↓
FormControl Updated

When the form resets:

form.reset()
      ↓
writeValue(null)
      ↓
Component Updated

When disabled:

control.disable()
       ↓
setDisabledState(true)

Common Mistakes

Mistake #1

Changing the value without calling onChange

Wrong:
this.value++;

Correct:

this.value++;

this.onChange(this.value);

Mistake #2
Never calling onTouched

Wrong:

click() {
    this.value++;
}

Correct:

click() {

    this.value++;

    this.onTouched();

}

Mistake #3
Ignoring disabled state

Wrong

increment() {

    this.value++;

}

Correct:
if (this.disabled) return;

Mistake #4
Forgetting NG_VALUE_ACCESSOR

Without:

providers: [
    ...
]

Angular cannot discover your accessor.

CVA with Validators

CVA only handles value communication.

Validation is separate.

You can still use:

Validators.required

Validators.min(1)

Validators.max(10)

Example:

quantity: new FormControl(
    1,
    Validators.min(1)
)

Angular validates normally.

CVA + Signals (Angular 17+)
Instead of:
value = 0;

You can use:
value = signal(0);

Writing value:

writeValue(value: number) {
    this.value.set(value);
}

Updating:

increment() {

    this.value.update(v => v + 1);

    this.onChange(this.value());

}

Signals work perfectly with CVA and make state updates more declarative.

Real-World Components That Use CVA
Almost every reusable form component benefits from implementing ControlValueAccessor:

Custom dropdowns
Searchable selects
Multi-select components
Tag inputs
Date pickers
Time pickers
Color pickers
File uploaders
Phone number inputs
OTP inputs
Rich text editors
Sliders
Range selectors
Rating components
Toggle switches
Tree selectors
Custom checkboxes
Custom radio buttons
Markdown editors

Best Practices

Keep writeValue() free of side effects; update internal state only.
Always call onChange()when the value changes due to user interaction, not when writeValue() is invoked by Angular.
CallonTouched() when the user has meaningfully interacted with the control (often on blur, sometimes on the first interaction depending on the UX).
Respect the disabled state in both your component logic and template.
Expose a single source of truth for the value to avoid synchronization bugs.
Combine CVA with OnPushchange detection or Signals for better performance in reusable components.
Make your component accessible by supporting keyboard navigation, focus management, and ARIA attributes.

Final Thoughts
ControlValueAccessor is one of the most important APIs for building professional Angular applications. It allows your custom components to integrate seamlessly with Angular Forms, making them behave exactly like native form controls. By correctly implementing writeValue(), registerOnChange(), registerOnTouched(), and setDisabledState(), you unlock support for Reactive Forms, Template-driven Forms, validation, form resets, disabling, and all the other powerful features of Angular's forms ecosystem.

Mastering CVA is essential if you want to create reusable UI libraries, design systems, or enterprise-grade Angular applications where custom form controls are a common requirement. Once you understand the data flow between Angular Forms and your component, implementing new form controls becomes a predictable and repeatable process.

Designing a Scalable Notification System in Node.js: An OOP + SOLID Approach for Production

Abanoub Kerols — Sat, 20 Jun 2026 08:00:21 +0000

Notifications are a critical component of modern applications — from real-time alerts to marketing emails and push notifications. Designing a robust, maintainable, and scalable notification system is a classic system design interview question and a common real-world requirement for backend engineers.
This article walks through a professional, production-oriented design using Node.js, emphasizing OOP principles, SOLID, and practical tools like NestJS, BullMQ, and Socket.IO.

1. Clarifying Requirements
Start every design discussion by clarifying requirements:
Functional Requirements:

Send notifications in real-time or asynchronously
Support multiple channels: Email, Push (mobile/web), SMS
Respect user preferences (opt-in/opt-out per channel)
Support bulk notifications
Track delivery status (sent/failed)

Non-Functional Requirements:

High scalability (millions of users)
Low latency for real-time notifications
Fault tolerance and retry mechanisms
Extensibility (easy to add new channels like WhatsApp)

2. High-Level Architecture
A typical production-grade flow looks like this:
Client → API Gateway → Notification Service → Queue (BullMQ/Redis) → Workers → External Providers (SendGrid, Firebase, Twilio)

Database: Stores notification history, status, and user preferences (MongoDB or PostgreSQL)
Real-time: WebSockets (Socket.IO) for instant delivery

This architecture ensures decoupling, scalability, and retry capabilities.

3. OOP Design & SOLID Principles (The Clean Core)
Instead of messy if/else chains, we use proper object-oriented design.

Core Abstraction

// notification.interface.ts
export interface Notification {
  send(to: string, message: string): Promise<void>;
}

Concrete Implementations

// email.notification.ts
export class EmailNotification implements Notification {
  async send(to: string, message: string): Promise<void> {
    console.log(`📧 Sending EMAIL to ${to}: ${message}`);
    // Integrate SendGrid / Nodemailer here
  }
}

// Similarly for SMSNotification and PushNotification

Notification Service (Polymorphism in Action)

export class NotificationService {
  constructor(private notifier: Notification) {}

  async notify(userId: string, message: string): Promise<void> {
    await this.notifier.send(userId, message);
  }
}

SOLID Principles Applied:

Single Responsibility: Each notification class handles only its channel.
Open/Closed: Add new channels (e.g., WhatsAppNotification) without modifying existing code.
Liskov Substitution: Any Notification implementation can replace another seamlessly.
Interface Segregation: Small, focused interface.
Dependency Inversion: High-level modules depend on abstractions, not concrete classes.

4. Factory Pattern for Flexibility

// notification.factory.ts
export class NotificationFactory {
  static create(type: string): Notification {
    switch (type.toLowerCase()) {
      case 'email': return new EmailNotification();
      case 'sms':   return new SMSNotification();
      case 'push':  return new PushNotification();
      default: throw new Error('Invalid notification type');
    }
  }
}

5. Production-Ready Implementation with Queue (BullMQ)

// notification.queue.ts
import { Queue } from 'bullmq';

export const notificationQueue = new Queue('notifications', {
  connection: { host: 'localhost', port: 6379 }
});

Worker (Background Processing)

// notification.processor.ts
import { Worker } from 'bullmq';
import { NotificationFactory } from '../factory/notification.factory';

const worker = new Worker('notifications', async (job) => {
  const { type, to, message } = job.data;
  const notifier = NotificationFactory.create(type);
  await notifier.send(to, message);
}, { connection: { host: 'localhost', port: 6379 } });

Service Layer (NestJS)

@Injectable()
export class NotificationService {
  async sendNotification(type: string, to: string, message: string) {
    await notificationQueue.add('send', { type, to, message }, {
      attempts: 3,
      backoff: { type: 'exponential' }
    });
  }
}

6. API Controller + Real-time WebSockets

// notification.controller.ts
@Post()
async send(@Body() body: { type: string; to: string; message: string }) {
  await this.service.sendNotification(body.type, body.to, body.message);
  return { status: 'queued' };
}

WebSocket Gateway (Real-time)

@WebSocketGateway()
export class NotificationGateway {
  @WebSocketServer() server: Server;

  sendToUser(userId: string, message: string) {
    this.server.to(userId).emit('notification', message);
  }
}

7. Project Structure (Clean Architecture Style)

notification-system/
├── src/
│   ├── modules/notification/
│   │   ├── interfaces/
│   │   ├── implementations/
│   │   ├── factory/
│   │   ├── services/
│   │   ├── queue/
│   │   └── notification.controller.ts
│   └── app.module.ts
├── docker-compose.yml

8. Advanced Production Considerations

Rate Limiting & anti-spam protection
Idempotency keys to prevent duplicate notifications
User Preferences stored in DB
Notification Templates service
A/B Testing for different notification strategies
Monitoring: Job success/failure rates, latency
Scaling: Horizontal scaling of workers + Kafka for higher throughput

Tech Stack Recommendation:

NestJS (structure + DI)
BullMQ + Redis (queue)
Socket.IO (real-time)
MongoDB/PostgreSQL + Redis (cache)
Docker for local/prod

Conclusion & Interview Tips

When asked to "design a notification system," demonstrate both high-level architecture thinking and clean code principles. Mentioning OOP + SOLID, Factory Pattern, and queue-based processing will set you apart from candidates who only talk about queues and providers.

Node.js Streams, Web Streams, Workers, and Real-Time Processing — The Practical Guide

Abanoub Kerols — Thu, 11 Jun 2026 12:19:24 +0000

Modern applications do not process small files anymore.

They process:

Gigabytes of CSV data
Real-time payments
Live chat messages
Streaming APIs
Video uploads
Database records
AI responses
Continuous logs and analytics

If you load everything into memory first, your application becomes slow, expensive, and eventually crashes.

This is where Streams, Async Iterators, Workers, and Web Streams become critical.

In this article, we’ll go from the fundamentals to real-world production patterns using Node.js.

What Are JavaScript Events?

Before understanding Streams, we first need to understand events.

JavaScript is event-driven.

An event is simply:

“Something happened.”

Examples:

User clicked a button
File finished loading
Payment completed
Stream received data
Socket disconnected

Node.js internally uses an event system called the Event Emitter.

Example:

import EventEmitter from 'events';

const emitter = new EventEmitter();

emitter.on('payment-approved', (data) => {
  console.log('Payment approved:', data);
});

emitter.emit('payment-approved', {
  user: 'John',
  amount: 100
});

Output:
Payment approved: { user: 'John', amount: 100 }
This event-based architecture is one of the foundations behind Streams.

Observer Pattern in Practice — E-commerce Payments

Streams and events are heavily related to the Observer Pattern.

The Observer Pattern means:
One object emits updates, many objects react independently.

Example:

class PaymentService extends EventEmitter {}

const payment = new PaymentService();

payment.on('approved', (data) => {
  console.log('Sending email...', data);
});

payment.on('approved', (data) => {
  console.log('Updating analytics...', data);
});

payment.on('approved', (data) => {
  console.log('Creating invoice...', data);
});

payment.emit('approved', {
  orderId: 10,
  total: 300
});

One event triggered:

Email service
Analytics
Invoice generation

This is how many real-world architectures work internally.

Buffers — The Core Concept Behind Streams
Streams process data in small chunks.

These chunks are usually represented using Buffers.

A Buffer is raw binary data.

Example:

const buffer = Buffer.from('Hello');

console.log(buffer);

Output:
<Buffer 48 65 6c 6c 6f>

Streams move these chunks progressively instead of loading everything at once.

What Are Streams?
A Stream is a way to process data progressively.

Instead of:
read entire file -> process -> send

Streams do:

read chunk -> process -> send
read chunk -> process -> send
read chunk -> process -> send

This makes applications:

Faster
More memory efficient
Scalable

Types of Streams in Node.js
Node.js has 4 main stream types.

Stream Type	Purpose
Readable	Read data
Writable	Write data
Duplex	Read + write
Transform	Modify data while streaming

Readable Stream Example

import fs from 'fs';

const stream = fs.createReadStream('./bigfile.txt', {
  encoding: 'utf8'
});

stream.on('data', (chunk) => {
  console.log(chunk);
});

The file is read piece by piece.

Writable Stream Example

import fs from 'fs';

const writable = fs.createWriteStream('./output.txt');

writable.write('Hello\n');
writable.write('World\n');

writable.end();

Transform Stream Example
Transform streams modify data while it flows.

import { Transform } from 'stream';

class UpperCase extends Transform {
  _transform(chunk, encoding, callback) {
    callback(null, chunk.toString().toUpperCase());
  }
}

process.stdin
  .pipe(new UpperCase())
  .pipe(process.stdout);

input:
hello

Output:
HELLO

Duplex Streams
Duplex streams can:

Read
Write at the same time.

Examples:

TCP sockets
WebSockets
Chat systems

Duplex Streams in Practice — Chat Between Servers
Node.js has a native TCP module called net.

server:

import net from 'net';

const server = net.createServer((socket) => {
  socket.write('Connected!\n');

  socket.on('data', (data) => {
    console.log('Client:', data.toString());

    socket.write(`Server received: ${data}`);
  });
});

server.listen(3000);

Client:

import net from 'net';

const client = net.connect(3000);

client.write('Hello server');

client.on('data', (data) => {
  console.log(data.toString());
});

This is a real duplex communication channel.

.pipe() vs pipeline()
Most developers use .pipe().

Example:
readable.pipe(writable);

But .pipe() has a problem:

weak error handling

The safer approach is pipeline().

import { pipeline } from 'stream/promises';

await pipeline(
  readable,
  transform,
  writable
);

Benefits:

automatic cleanup
proper error propagation
prevents memory leaks

In production systems, pipeline() is usually preferred.

Massive CSV Processing — CSV to NDJSON

Imagine:

10GB CSV file
millions of records

Bad approach:
const data = fs.readFileSync('./huge.csv');

This loads everything into RAM.

Instead, use streams.

Streaming CSV Parser

import fs from 'fs';
import csv from 'csv-parser';

fs.createReadStream('./huge.csv')
  .pipe(csv())
  .on('data', (row) => {
    console.log(row);
  });

Now rows are processed progressively.

Converting CSV to NDJSON

NDJSON means:

One JSON object per line.

Example:

{"id":1}
{"id":2}
{"id":3}

Transform stream:

import { Transform } from 'stream';

class ToNDJSON extends Transform {
  constructor() {
    super({ objectMode: true });
  }

  _transform(chunk, enc, cb) {
    cb(null, JSON.stringify(chunk) + '\n');
  }
}

Pipeline:

await pipeline(
  fs.createReadStream('./huge.csv'),
  csv(),
  new ToNDJSON(),
  fs.createWriteStream('./output.ndjson')
);

This is how big data ingestion systems work.

Async Iterators and Generator Functions
Streams integrate perfectly with async iteration.

Example:

for await (const chunk of stream) {
  console.log(chunk.toString());
}

This creates clean, readable stream processing.

Generator Functions

async function* generateNumbers() {
  yield 1;
  yield 2;
  yield 3;
}

for await (const num of generateNumbers()) {
  console.log(num);
}

Generators are extremely useful for:

on-demand processing
pagination
streaming APIs
lazy loading

SQL Streaming on Demand
Instead of loading 1 million rows:
SELECT * FROM users;
Some database drivers support streaming results progressively.

Example concept:

const stream = db.queryStream('SELECT * FROM users');

for await (const row of stream) {
  console.log(row);
}

Benefits:

lower memory usage
faster response time
scalable ETL systems

Aborting Async Operations
Modern Node.js supports AbortController.

Example:

const controller = new AbortController();

setTimeout(() => {
  controller.abort();
}, 3000);

fetch(url, {
  signal: controller.signal
});

Useful for:

canceling requests
timeouts
stopping streams
shutting down workers

Consuming Web APIs as Streams
Some APIs stream data progressively.

Example:

const response = await fetch(url);

for await (const chunk of response.body) {
  console.log(chunk);
}

This is used heavily in:

AI streaming responses
video streaming
live analytics
stock market feeds

Web Streams API

Node.js now supports the Web Streams standard.
This makes backend and frontend streaming more unified.

Main stream types:

ReadableStream
WritableStream
TransformStream

Creating a Web Readable Stream

const stream = new ReadableStream({
  start(controller) {
    controller.enqueue('Hello');
    controller.enqueue('World');
    controller.close();
  }
});

Consuming Massive Data — Frontend + Backend Streaming
Backend:

app.get('/stream', (req, res) => {
  const file = fs.createReadStream('./huge.txt');

  file.pipe(res);
});

Frontend:

const response = await fetch('/stream');

const reader = response.body.getReader();

while (true) {
  const { done, value } = await reader.read();

  if (done) break;

  console.log(value);
}

This enables progressive rendering.

Huge applications use this pattern:

Netflix
YouTube
ChatGPT-like streaming UIs
dashboards

Parallel Processing with Child Processes

Node.js is single-threaded for JavaScript execution.
Heavy CPU tasks block the event loop.

Solution:

child processes
workers

Example:

import { fork } from 'child_process';

const process = fork('./worker.js');

process.send({ start: true });

process.on('message', (msg) => {
  console.log(msg);
});

Useful for:

image processing
video compression
large parsing jobs
AI inference

Worker Threads
Workers are lighter than child processes.

Example:

import { Worker } from 'worker_threads';

const worker = new Worker('./worker.js');

worker.on('message', (data) => {
  console.log(data);
});

N-Tier Architecture with Workers
Modern frontend architectures increasingly use workers.

Examples:

parsing CSV in browser workers
background search indexing
image editing
AI tokenization

Main UI thread stays responsive

Parsing CSV to JSON On Demand
Streaming parser:

async function* parseCSV(stream) {
  for await (const chunk of stream) {
    yield transform(chunk);
  }
}

This pattern enables:

lazy processing
scalable pipelines
real-time analytics

Finding Occurrences and Reporting Progress

Example:

scanning 100GB logs
finding errors progressively

let count = 0;

for await (const chunk of stream) {
  const matches = chunk.toString().match(/ERROR/g);

  if (matches) {
    count += matches.length;
  }

  console.log('Current count:', count);

This allows:

live progress reporting
streaming dashboards
real-time monitoring

Why Streams Matter in Modern Systems
Streams are no longer optional.

They power:

AI systems
video platforms
analytics pipelines
ETL systems
chat applications
distributed systems
server-side rendering
real-time dashboards

Without streams:

memory explodes
latency increases
scalability collapses

Final Thoughts

Learning Streams changes how you think about backend systems.

You stop thinking:

Load everything first

and start thinking:

Process data progressively

That mindset is essential for building scalable modern applications.

Once you combine:

Streams
Async Iterators
Web Streams
Workers
Pipelines
AbortControllers

you begin building systems that behave like real production infrastructure instead of small demo applications.

You Might Not Need a Framework: Building Modern Web Apps with Vanilla JavaScript

Abanoub Kerols — Tue, 28 Apr 2026 09:22:35 +0000

In today's frontend world, it's easy to reach for React, Vue, or Svelte the moment a project needs interactivity, state management, or routing. But the modern browser has evolved dramatically. With native DOM APIs, the History API, Web Components, and powerful language features like Proxies, you can build rich, performant single-page applications (SPAs) using nothing but Vanilla JavaScript.

This approach gives you:

Smaller bundle sizes
Better performance (no virtual DOM overhead)
Full control and understanding of your code
No framework lock-in or version churn

Let's explore how to create a lightweight "Vanilla JS Framework" using five key pillars:

Vanilla JavaScript
The DOM
Routing
Web Components
Reactive Programming with Proxies

We'll build toward a simple todo-style SPA that demonstrates all of them working together.

1. Vanilla JavaScript: The Foundation
Start with plain, modern ES6+ JavaScript—no transpilers, no build tools required for small-to-medium apps (though you can add Vite later if you want).
Use native modules (import/export), arrow functions, template literals, destructuring, and async/await. Organize your code into modules for clarity.

Example project structure:

my-vanilla-app/
├── index.html
├── js/
│   ├── main.js
│   ├── router.js
│   ├── store.js          // reactive state
│   └── components/
│       └── todo-item.js
└── styles.css

In index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Vanilla Todo</title>
  <script type="module" src="js/main.js"></script>
</head>
<body>
  <div id="app"></div>
</body>
</html>

This keeps everything lightweight and browser-native.

2. The DOM: Direct Manipulation Done Right
Forget innerHTML spam. Use modern DOM methods for efficiency and security.
Key techniques:

document.createElement(), append(), replaceChildren()
querySelector / closest for traversal
Event delegation instead of attaching listeners to every element
classList, dataset, and textContent for updates

Example: Rendering a list efficiently

// js/main.js
function renderTodos(todos, container) {
  container.replaceChildren(); // Clear efficiently

  const fragment = document.createDocumentFragment();

  todos.forEach(todo => {
    const el = document.createElement('todo-item');
    el.setAttribute('data-id', todo.id);
    el.todo = todo; // Custom property for the component
    fragment.append(el);
  });

  container.append(fragment);
}

Event delegation example:

document.getElementById('app').addEventListener('click', e => {
  if (e.target.matches('.delete-btn')) {
    const id = e.target.closest('todo-item').dataset.id;
    // handle delete
  }
});

This is fast, memory-efficient, and avoids common pitfalls of frameworks.

3. Routing: Client-Side Navigation Without Libraries

Modern browsers give you the History API (pushState, replaceState, popstate event) for clean URLs—no hash routing needed.

Simple Router Implementation:

// js/router.js
export class Router {
  constructor(routes) {
    this.routes = routes;
    this.currentRoute = null;

    window.addEventListener('popstate', () => this.handleRoute());
    document.addEventListener('click', e => {
      if (e.target.matches('a[data-link]')) {
        e.preventDefault();
        this.navigate(e.target.getAttribute('href'));
      }
    });
  }

  navigate(path) {
    history.pushState({}, '', path);
    this.handleRoute();
  }

  handleRoute() {
    const path = window.location.pathname || '/';
    const route = this.routes[path] || this.routes['/404'];

    if (route) {
      route(); // Render the view function
    }
  }

  init() {
    this.handleRoute();
  }
}

Usage:

import { Router } from './router.js';

const router = new Router({
  '/': () => renderHome(),
  '/todos': () => renderTodosPage(),
  '/404': () => renderNotFound()
});

router.init();

This gives you bookmarkable, shareable URLs with zero dependencies.

4. Web Components: Reusable, Encapsulated UI Elements

Web Components (Custom Elements + Shadow DOM + HTML Templates) are native browser features that let you create reusable components with style and markup isolation.
Creating a Todo Item Component:

// js/components/todo-item.js
class TodoItem extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
  }

  set todo(data) {
    this._todo = data;
    this.render();
  }

  render() {
    this.shadowRoot.innerHTML = `
      <style>
        :host { display: block; padding: 8px; border-bottom: 1px solid #eee; }
        .done { text-decoration: line-through; opacity: 0.6; }
      </style>
      <label>
        <input type="checkbox" ${this._todo.done ? 'checked' : ''}>
        <span class="${this._todo.done ? 'done' : ''}">${this._todo.text}</span>
      </label>
      <button class="delete">×</button>
    `;

    // Add event listeners inside shadow DOM
    this.shadowRoot.querySelector('input').addEventListener('change', () => {
      this.dispatchEvent(new CustomEvent('toggle', { 
        detail: { id: this._todo.id },
        bubbles: true 
      }));
    });
  }

  connectedCallback() {
    this.render();
  }
}

customElements.define('todo-item', TodoItem);

Now you can use it like native HTML: . Shadow DOM prevents style leakage, and connectedCallback / disconnectedCallback give you lifecycle hooks ⁠Mellowdevs.medium.

5. Reactive Programming with Proxies: Automatic UI Updates
JavaScript's Proxy API lets you intercept property access and mutations—perfect for building lightweight reactivity without signals or virtual DOM.

Simple Reactive Store:

// js/store.js
export function createStore(initialState) {
  const listeners = new Set();

  const handler = {
    set(target, prop, value) {
      target[prop] = value;
      listeners.forEach(listener => listener(target));
      return true;
    }
  };

  const state = new Proxy({ ...initialState }, handler);

  function subscribe(callback) {
    listeners.add(callback);
    callback(state); // Initial call
    return () => listeners.delete(callback);
  }

  return { state, subscribe };
}

Usage in your app:

import { createStore } from './store.js';

const { state, subscribe } = createStore({
  todos: [],
  filter: 'all'
});

// React to changes
subscribe((newState) => {
  renderTodos(newState.todos, document.getElementById('todo-list'));
});

// Update state normally
state.todos.push({ id: Date.now(), text: 'Learn Vanilla JS', done: false });

For finer control, you can use Reflect with more advanced traps, or dispatch custom events from the store. This pattern powers the reactivity in many "zero-dependency" libraries and mimics the core idea behind Vue's reactivity or Solid's signals Medium.

Putting It All Together
In main.js, wire everything up:

import { Router } from './router.js';
import { createStore } from './store.js';
import './components/todo-item.js';

const { state, subscribe } = createStore({ todos: [] });

const router = new Router({
  '/': () => renderDashboard(state),
  '/todos': () => renderTodoApp(state, subscribe)
});

router.init();

Add form handlers, localStorage persistence, and you're done—a fully functional SPA with routing, components, and reactivity, all in Vanilla JS.

When Should You Still Use a Framework?

Vanilla JS shines for:

Small-to-medium apps
Performance-critical interfaces
Learning projects
Sites where bundle size and simplicity matter

Frameworks still win for very large teams, complex ecosystems (TypeScript + huge component libraries), or when you need battle-tested solutions for accessibility, server-side rendering, etc.
But for many projects in 2025–2026, the browser is more than capable. You might not need a framework after all

Recently built a small SPA using Vanilla JavaScript

I wanted to step away from frameworks for a bit and focus on the fundamentals, so I built this project using only native browser APIs.

💡 What I implemented:

Custom client-side routing (SPA behavior)
Dynamic DOM rendering & event handling
Component-based structure using Web Components
State management without external libraries
Clean separation of concerns and scalable structure

A full SPA using Vanilla JavaScript no frameworks

Mastering React.js: The Ultimate Practical Guide with Real-World Examples, Every Hook Explained, Routing & Redux

Abanoub Kerols — Thu, 23 Apr 2026 09:57:39 +0000

React.js remains the king of front-end development in 2026. Built by Meta in 2013 and open-sourced in 2015, it powers Facebook, Instagram, Netflix, Airbnb, WhatsApp Web, and millions of production apps.
Unlike full frameworks, React is a library focused only on the UI layer — giving you total freedom. Its secret weapons? Virtual DOM, component architecture, and Hooks.
Let’s rewrite everything with way more practical examples, deep dive into every major Hook, full React Router routing, and Redux Toolkit (the modern standard).

1. JSX & Components – The Foundation

function Greeting({ name }) {
  return <h1>Hello, {name}! 👋 Today is {new Date().toLocaleDateString()}</h1>;
}

// Usage
<Greeting name="Abanoub" />

2. Props vs State – Real Example
Props = data passed down (read-only)
State = data that changes inside the component

// Parent
function App() {
  const [userName, setUserName] = useState("Abanoub");
  return <Profile name={userName} setName={setUserName} />;
}

// Child
function Profile({ name, setName }) {
  return (
    <>
      <h2>{name}</h2>
      <button onClick={() => setName("Ahmed")}>Change Name</button>
    </>
  );
}

3. Every React Hook Explained with Practical Examples
useState – Local State Management
Most used hook.

function Counter() {
  const [count, setCount] = useState(0);
  const [step, setStep] = useState(1);

  return (
    <>
      <h2>Count: {count}</h2>
      <button onClick={() => setCount(c => c + step)}>+</button>
      <button onClick={() => setCount(c => c - step)}>-</button>
      <input type="number" value={step} onChange={e => setStep(+e.target.value)} />
    </>
  );
}

useEffect – Side Effects (API calls, timers, subscriptions)

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(true);
    fetch(`https://jsonplaceholder.typicode.com/users/${userId}`)
      .then(res => res.json())
      .then(data => {
        setUser(data);
        setLoading(false);
      });
  }, [userId]); // ← runs again only when userId changes

  useEffect(() => {
    document.title = user ? user.name : "Loading...";
  }, [user]);

  return loading ? <p>Loading...</p> : <h1>{user.name}</h1>;
}

useContext – Global Data Without Prop Drilling

// ThemeContext.js
const ThemeContext = createContext();

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState("light");
  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

// Any component
function Button() {
  const { theme, setTheme } = useContext(ThemeContext);
  return (
    <button onClick={() => setTheme(theme === "light" ? "dark" : "light")}>
      Switch to {theme === "light" ? "Dark" : "Light"}
    </button>
  );
}

useReducer – Complex State Logic (like Redux but local)
Perfect for forms, shopping carts, game logic.

const initialState = { count: 0, step: 1 };

function reducer(state, action) {
  switch (action.type) {
    case "increment": return { ...state, count: state.count + state.step };
    case "decrement": return { ...state, count: state.count - state.step };
    case "setStep": return { ...state, step: action.payload };
    default: return state;
  }
}

function AdvancedCounter() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <>
      <h2>Count: {state.count}</h2>
      <button onClick={() => dispatch({ type: "increment" })}>+</button>
      <button onClick={() => dispatch({ type: "decrement" })}>-</button>
      <input 
        value={state.step} 
        onChange={e => dispatch({ type: "setStep", payload: +e.target.value })} 
      />
    </>
  );
}

useRef – Access DOM elements or persist values without re-render

function Timer() {
  const intervalRef = useRef(null);
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    intervalRef.current = setInterval(() => setSeconds(s => s + 1), 1000);
    return () => clearInterval(intervalRef.current);
  }, []);

  return <h2>Seconds: {seconds}</h2>;
}

// Another use: focus input
function FocusInput() {
  const inputRef = useRef(null);
  return (
    <>
      <input ref={inputRef} />
      <button onClick={() => inputRef.current.focus()}>Focus</button>
    </>
  );
}

useMemo – Cache expensive calculations

function ExpensiveList({ items, filter }) {
  const filteredItems = useMemo(() => {
    console.log("Filtering..."); // this runs only when filter changes
    return items.filter(item => item.includes(filter));
  }, [items, filter]);

  return <ul>{filteredItems.map(item => <li key={item}>{item}</li>)}</ul>;
}

useCallback – Memoize functions (prevents child re-renders)

function Parent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    setCount(c => c + 1);
  }, []); // empty deps = never recreated

  return <Child onClick={handleClick} />;
}

const Child = React.memo(function Child({ onClick }) {
  console.log("Child rendered");
  return <button onClick={onClick}>Click me</button>;
});

Custom Hooks – Reuse Logic

function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch(url).then(res => res.json()).then(setData).finally(() => setLoading(false));
  }, [url]);

  return { data, loading };
}

// Usage anywhere
function Dashboard() {
  const { data: posts, loading } = useFetch("https://jsonplaceholder.typicode.com/posts");
  // ...
}

4. Routing with React Router v6+ (Practical Multi-Page App)

npm install react-router-dom

// main.jsx
import { BrowserRouter, Routes, Route, Link, Navigate } from "react-router-dom";

function App() {
  return (
    <BrowserRouter>
      <nav>
        <Link to="/">Home</Link> | 
        <Link to="/about">About</Link> | 
        <Link to="/users/1">User 1</Link>
      </nav>

      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
        <Route path="/users/:id" element={<UserProfile />} />
        <Route path="*" element={<Navigate to="/" />} />
      </Routes>
    </BrowserRouter>
  );
}

Protected Route Example

function ProtectedRoute({ children }) {
  const isLoggedIn = useContext(AuthContext);
  return isLoggedIn ? children : <Navigate to="/login" />;
}

// Usage
<Route path="/dashboard" element={<ProtectedRoute><Dashboard /></ProtectedRoute>} />

5. Redux Toolkit – The Modern State Management Solution
Forget old Redux boilerplate. Redux Toolkit is the official way.

npm install @reduxjs/toolkit react-redux

// store.js
import { configureStore } from '@reduxjs/toolkit';
import cartReducer from './cartSlice';

export const store = configureStore({
  reducer: { cart: cartReducer }
});

// cartSlice.js
import { createSlice } from '@reduxjs/toolkit';

const cartSlice = createSlice({
  name: 'cart',
  initialState: { items: [] },
  reducers: {
    addToCart: (state, action) => {
      state.items.push(action.payload);
    },
    removeFromCart: (state, action) => {
      state.items = state.items.filter(item => item.id !== action.payload);
    }
  }
});

export const { addToCart, removeFromCart } = cartSlice.actions;
export default cartSlice.reducer;

Using in Component

import { useSelector, useDispatch } from 'react-redux';
import { addToCart } from './cartSlice';

function Product({ product }) {
  const dispatch = useDispatch();
  const cartCount = useSelector(state => state.cart.items.length);

  return (
    <>
      <button onClick={() => dispatch(addToCart(product))}>
        Add to Cart ({cartCount})
      </button>
    </>
  );
}

6. Bonus: Full Mini E-commerce App Structure (React + Router + Redux + Hooks)

App.jsx → BrowserRouter + Routes
CartPage.jsx → uses Redux + useSelector
ProductPage.jsx → useState for quantity + useEffect for API
ThemeProvider wrapping everything with useContext

Final Tips from a Senior Developer

Always use useCallback + React.memo for performance.
Prefer Redux Toolkit or Zustand for global state (Context + useReducer for simple cases).
Use React Router v6.22+ with createBrowserRouter for data loaders in big apps.
Learn TypeScript + React — it will save you weeks of bugs.

npm create vite@latest my-react-app -- --template react
cd my-react-app
npm install react-router-dom @reduxjs/toolkit react-redux
npm run dev

Angular Security Deep Dive: CSS, DOM Manipulation, and XSS Prevention (2026 Edition)

Abanoub Kerols — Sun, 19 Apr 2026 09:08:51 +0000

Angular's security model is "secure by default" for most template interactions, but CSS and direct DOM manipulations introduce unique risks. Attackers can exploit unsafe style bindings to perform CSS-based XSS, data exfiltration, or UI manipulation (e.g., hiding elements, phishing overlays, or keylogging via crafted styles). Direct DOM access bypasses Angular's protections entirely.
This expanded section explains Angular's handling of CSS and DOM, with multiple code examples, security contexts, and best practices.

1. Angular's Security Contexts for CSS and DOM
Angular automatically sanitizes values based on the SecurityContext:

HTML — [innerHTML], interpolation
Style — [style], [ngStyle], inline styles
URL — [href], [src]
Resource URL — iframes, scripts (most restricted)

For CSS, Angular's sanitizer removes dangerous properties (e.g., behavior:, expression(), or certain url() values that could load external resources or execute code in older browsers). However, modern attacks often use subtle techniques like:

background-image with malicious SVGs
position: fixed + z-index to create overlays
CSS animations or transitions that trigger unwanted behavior

Key Rule: Prefer Angular's declarative bindings over raw DOM manipulation.

2. Safe vs. Unsafe CSS Bindings — Examples
Example 1: Basic Style Binding (Sanitized by Default)
HTML

<!-- css-security.component.html -->
<div [style.background-color]="userColor">
  Dynamic background (safe)
</div>

<div [style]="dynamicStyles">
  Full style object (sanitized)
</div>

<div [ngStyle]="{'color': userTextColor, 'font-size': userFontSize}">
  ngStyle binding
</div>

// css-security.component.ts
import { Component, inject } from '@angular/core';
import { DomSanitizer, SafeStyle } from '@angular/platform-browser';

@Component({
  selector: 'app-css-security',
  standalone: true,
  templateUrl: './css-security.component.html'
})
export class CssSecurityComponent {
  private sanitizer = inject(DomSanitizer);

  userColor = 'red'; // Safe if controlled
  userTextColor = '#000';
  userFontSize = '16px';

  // Simulated attacker input (e.g., from API)
  dangerousStyle = 'color: red; background: url("javascript:alert(\'XSS\')")'; // Usually blocked

  dynamicStyles: SafeStyle | null = null;

  constructor() {
    // Safe approach: Let Angular sanitize
    // Or bypass ONLY if fully trusted (high risk)
    this.dynamicStyles = this.sanitizer.bypassSecurityTrustStyle(
      'color: blue; font-weight: bold;'
    );
  }
}

What Angular does:

Normal [style.property] and [ngStyle] are sanitized.
Full [style] binding (string) goes through the Style context sanitizer, which strips many dangerous declarations.

Pitfall: In some older scenarios or with complex values, subtle CSS injections (e.g., expression() in IE, or modern url() with data URIs containing scripts) could still pose risks if not handled carefully.

3. Advanced: bypassSecurityTrustStyle and SafeStyle
Use bypassSecurityTrustStyle when you need dynamic, complex CSS (e.g., user themes, generated styles from a design tool).
Example 2: Trusted Dynamic Styles with Caution

// safe-style.pipe.ts (recommended reusable approach)
import { Pipe, PipeTransform } from '@angular/core';
import { DomSanitizer, SafeStyle } from '@angular/platform-browser';

@Pipe({
  name: 'safeStyle',
  standalone: true
})
export class SafeStylePipe implements PipeTransform {
  constructor(private sanitizer: DomSanitizer) {}

  transform(value: string | null): SafeStyle | null {
    if (!value) return null;
    // Optional: Add custom validation here (e.g., allowlist properties)
    return this.sanitizer.bypassSecurityTrustStyle(value);
  }
}

Usage:

<div [style]="userProvidedStyles | safeStyle">
  Content with trusted styles
</div>

Real-World Risk Example (Never do this with untrusted input):
TypeScript

// Dangerous — avoid with user data
dangerousCss = `background: url("data:image/svg+xml,<svg onload=alert('CSS-XSS')></svg>"); position: fixed; z-index: 9999;`;

Even with sanitization, some SVG-based or animation-based attacks have been demonstrated in the wild. Always validate on the server and prefer allowlisting allowed CSS properties.

4. DOM Manipulation Risks and Safe Alternatives
Direct DOM access is one of the most common ways to bypass Angular security.
Bad Practice (High Risk):

// Avoid this
import { ElementRef } from '@angular/core';

constructor(private el: ElementRef) {}

ngAfterViewInit() {
  this.el.nativeElement.innerHTML = userHtml; // Bypasses all sanitization!
  // Or: document.getElementById(...) manipulations
}

Recommended: Use Renderer2 for Safe DOM Operations
TypeScript

import { Component, inject, Renderer2, ElementRef } from '@angular/core';

@Component({...})
export class SafeDomComponent {
  private renderer = inject(Renderer2);
  private el = inject(ElementRef);

  setSafeText(content: string) {
    // Clears previous content and sets text safely
    this.renderer.setProperty(this.el.nativeElement, 'textContent', content);
  }

  addSafeClass(className: string) {
    this.renderer.addClass(this.el.nativeElement, className);
  }

  createSafeElement(tag: string, text: string) {
    const child = this.renderer.createElement(tag);
    this.renderer.setProperty(child, 'textContent', text);
    this.renderer.appendChild(this.el.nativeElement, child);
  }
}

Why Renderer2? It abstracts browser differences and works better with server-side rendering (SSR). It doesn't allow raw HTML/JS injection like innerHTML or insertAdjacentHTML.
For HTML Content: Stick to [innerHTML] with proper sanitization (see previous examples) or a custom pipe using DomSanitizer.sanitize(SecurityContext.HTML, value).

5. Content Security Policy (CSP) for CSS and DOM Protection
CSP is a critical extra layer that restricts what CSS and scripts can do, even if sanitization fails.
Recommended Production CSP (server header or meta tag):

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'nonce-{random-nonce}';
  style-src 'self' 'unsafe-inline' 'nonce-{random-nonce}';  /* Angular styles often need 'unsafe-inline' */
  img-src 'self' data: https:;
  font-src 'self' https:;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  require-trusted-types-for 'script';

Angular-Specific Tips (2026):

Angular frequently requires 'unsafe-inline' for style-src due to dynamic component styles.
Newer Angular versions (19+) support better nonce/hash integration and autoCsp options in angular.json.
Use Trusted Types to prevent unsafe DOM operations at the browser level.

Combine CSP with Angular's built-in protections for defense-in-depth.

6. Recent Vulnerabilities Involving DOM/CSS (2026 Context)

CVE-2026-32635 (High severity): i18n attribute bindings (e.g., i18n-href, i18n-src) could bypass DomSanitizer, allowing XSS via attributes that affect DOM/CSS loading. Fix: Upgrade to patched versions (Angular 19.2.20+, 20.3.18+, 21.2.4+). Workaround: Manually sanitize values bound to these attributes.
SVG/MathML attribute issues in the compiler (e.g., xlink:href, attributeName) have allowed javascript: URLs in some bindings.
ICU message and translation pipeline flaws could inject unsanitized HTML/CSS.

Action: Always upgrade Angular promptly. Audit templates for i18n-* + dynamic bindings. Use DomSanitizer.sanitize() explicitly for sensitive attributes.
7. Best Practices for CSS and DOM Security

Prefer Angular Templates over direct DOM or innerHTML.
Sanitize First — Use DomSanitizer.sanitize() before bypassSecurityTrustStyle() or bypassSecurityTrustHtml().
Avoid nativeElement and document.* APIs unless wrapped in Renderer2.
Server-Side Sanitization — Use libraries like DOMPurify on the backend for any rich content.
Enable Strict CSP + Trusted Types in production.
Use AOT Compilation (default in production) — Prevents many template injection vectors.
Test with Tools — Run security scanners, OWASP ZAP, or manual reviews for style injection.

Pitfall Summary:

[style] with untrusted strings → potential layout attacks or exfiltration.
Direct DOM writes → full bypass of Angular security.
Dynamic CSS from users → phishing or clickjacking via overlays.

Conclusion
Angular handles most CSS and DOM interactions securely through context-aware sanitization and templating. However, the moment you introduce dynamic styles, innerHTML, or nativeElement, you must explicitly manage trust using DomSanitizer, Renderer2, and layered defenses like CSP.
Security in CSS/DOM is about never assuming input is safe — even "just styles" can be weaponized.

DEV Community: Abanoub Kerols

JavaScript Closures — Part 2 (Advanced Concepts & Real-World Applications)

Real-World Closures

Closures in Event Listeners

Closures with setTimeout()

Closures Inside Loops

Fix #1 — Using let

Fix #2 — Using a Closure

Closures in Factory Functions

Building a Counter

Closures and Private Variables

Closures in Express Middleware

Closures in React

The Once Function

Why Does Once Work?

Building a Memoize Function

Module Pattern

Why Professional Developers Love Closures

JavaScript Closures — The Complete Guide (From Beginner to Advanced)

Table of Contents

What is a Closure?

Why Do Closures Exist?

JavaScript Functions are More Than Code

Lexical Scope

Scope Chain

Execution Context

The Call Stack

Functions Have Permanent Memories

The Backpack Analogy

Closed Over Variables

Returning Functions

Persistent State

Multiple Independent Closures

Finite State Machines: A Complete Guide from Fundamentals to Production

Table of Contents

Part 1 — Fundamentals

What Is a State Machine?

Why Do We Need State Machines?

The Concept of State

The Concept of Event / Input

The Concept of Transition

The Concept of Action

State Diagram

A Simple Practical Example

Part 2 — Finite State Machines

Definition of a Finite State Machine

Components of an FSM

Transition Function

Initial State

Final / Accepting States

Deterministic Finite Automaton — DFA

Non-Deterministic Finite Automaton — NFA

DFA vs NFA

Moore Machine

Mealy Machine

Moore vs Mealy

Part 3 — FSM Design

How to Design an FSM from Requirements

Step 1 — Extract the States

Step 2 — Extract Events

Step 3 — Design Transitions

Step 4 — Add Guards

Step 5 — Add Actions

Invalid Transitions

State Invariants

State Explosion Problem

Part 4 — FSM Implementation

FSM Using if/else

FSM Using switch

FSM Using Objects

FSM Using Maps

Table-Driven FSM

Generic FSM

TypeScript FSM

Java FSM

Python FSM

Part 5 — Advanced FSM

Hierarchical State Machines

Nested States

Composite States