DEV Community: Sai Swaroop Bijinapalli

Node.js Fundamentals: Runtime, Architecture, Core Modules, Streams, Buffers & Non-Blocking I/O

Sai Swaroop Bijinapalli — Tue, 25 Aug 2026 11:11:49 +0000

Sure. Since you want to create a blog on this topic, I’d structure it as a beginner-friendly technical blog that explains what Node.js is, how its architecture works, and why non-blocking I/O is important.

A good title would be:

Node.js Fundamentals: Runtime, Architecture, Core Modules, Streams, Buffers & Non-Blocking I/O

Node.js Fundamentals: Runtime, Architecture, Core Modules, Streams, Buffers & Non-Blocking I/O

Node.js is one of the most popular technologies for building backend applications using JavaScript. If you are coming from frontend JavaScript, Node.js allows you to use the same language on the server side.

But Node.js is more than simply "JavaScript outside the browser." It has its own runtime, event loop, core modules, streams, buffers, and a non-blocking I/O architecture.

In this blog, we will understand these concepts step by step.

1. What is Node.js?

Node.js is a JavaScript runtime environment that allows us to execute JavaScript outside the browser.

Normally, JavaScript runs inside a browser:

Browser
   ↓
JavaScript
   ↓
JavaScript Engine

With Node.js:

JavaScript
    ↓
Node.js Runtime
    ↓
V8 Engine
    ↓
Operating System

Node.js uses Google's V8 JavaScript engine to execute JavaScript.

However, Node.js also provides additional capabilities that browsers normally do not provide, such as:

Reading and writing files
Creating HTTP servers
Working with the operating system
Network communication
Streams
Buffers
Process management

This makes Node.js useful for backend development.

2. Node.js Runtime

A runtime environment provides everything required to execute a programming language.

The Node.js runtime can be simplified into a few major components:

                 Node.js
                    │
        ┌───────────┴───────────┐
        ↓                       ↓
       V8                     libuv
        │                       │
  Executes JS          Handles async I/O
                                │
                         Event Loop
                                │
                         Operating System

V8

V8 is the JavaScript engine used by Node.js.

Its main responsibility is executing JavaScript code.

For example:

const name = "Node.js";

console.log(name);

V8 is responsible for executing this JavaScript.

libuv

libuv is an important part of Node.js's asynchronous architecture.

It helps Node.js handle:

Event loop
Asynchronous I/O
Networking
Timers
Thread pool operations

This is one of the reasons Node.js can handle many I/O operations efficiently.

3. Node.js Architecture

A simplified Node.js architecture looks like this:

              JavaScript Code
                     ↓
                Node.js APIs
                     ↓
                  libuv
                     ↓
                Event Loop
                     ↓
        ┌────────────┴────────────┐
        ↓                         ↓
   Operating System          Thread Pool

For example, when Node.js needs to read a file, your JavaScript code can start the operation without necessarily waiting for the entire file operation to finish.

While the operation is happening, Node.js can continue executing other JavaScript.

When the operation is complete, the appropriate callback or promise continuation can be processed.

This behavior is known as non-blocking I/O.

4. What is the Event Loop?

The event loop is one of the most important concepts in Node.js.

Node.js uses the event loop to coordinate asynchronous operations and execute callbacks when their work is ready.

Consider this example:

console.log("Start");

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

console.log("End");

The output is:

Start
End
Timer finished

Why does "End" appear before "Timer finished"?

Because setTimeout() schedules the callback to run later.

The JavaScript execution can continue instead of waiting for the timer.

Conceptually:

console.log("Start")
        ↓
Register timer
        ↓
console.log("End")
        ↓
Timer becomes ready
        ↓
Callback executes

The event loop continuously coordinates this kind of asynchronous work.

5. Event Loop Phases

Node.js's event loop contains several phases.

A simplified view is:

┌─────────────────────┐
│       Timers        │
├─────────────────────┤
│   Pending Callbacks │
├─────────────────────┤
│    Idle / Prepare   │
├─────────────────────┤
│        Poll         │
├─────────────────────┤
│        Check        │
├─────────────────────┤
│    Close Callbacks  │
└─────────────────────┘
          ↺

Timers

This phase handles callbacks associated with timers such as:

setTimeout()
setInterval()

Pending Callbacks

Some callbacks from certain system operations can be processed here.

Poll

The poll phase is responsible for handling many I/O-related callbacks and determining whether there is additional I/O work to process.

Check

The check phase is where callbacks registered using setImmediate() are executed.

setImmediate(() => {
    console.log("Immediate");
});

Close Callbacks

This phase handles certain close events, such as socket close callbacks.

The exact event-loop behavior can become quite detailed, but the important beginner concept is:

The event loop coordinates asynchronous operations without requiring JavaScript execution to stop and wait for every I/O operation.

6. Node.js Core Modules

Node.js provides many built-in modules.

These modules can be used without installing external packages.

Some important modules are:

fs
path
os
events
stream
buffer
http
crypto

Let's look at some of the most commonly used ones.

7. The `fs` Module

fs stands for File System.

It allows Node.js applications to work with files and directories.

const fs = require("fs");

For example, we can read a file:

fs.readFile("data.txt", "utf8", (err, data) => {
    if (err) {
        console.log(err);
        return;
    }

    console.log(data);
});

We can also write a file:

fs.writeFile("data.txt", "Hello Node.js", (err) => {
    if (err) {
        console.log(err);
    }
});

Common fs operations include:

readFile()
writeFile()
appendFile()
mkdir()
unlink()

The fs module is especially important when building applications that interact with files.

8. The `path` Module

The path module helps us work with file and directory paths.

const path = require("path");

For example:

const filePath = path.join("users", "data", "file.txt");

console.log(filePath);

path.join() creates a path using the correct path separator for the operating system.

Some useful methods are:

path.join()
path.resolve()
path.basename()
path.dirname()
path.extname()

For example:

const file = "/home/user/app.js";

console.log(path.basename(file));

Output:

app.js

9. The `os` Module

The os module provides information about the operating system.

const os = require("os");

For example:

console.log(os.platform());
console.log(os.arch());
console.log(os.cpus());
console.log(os.totalmem());
console.log(os.freemem());

This can be useful when an application needs information about the environment in which Node.js is running.

10. The `events` Module

Node.js follows an event-driven architecture.

The events module provides EventEmitter, which allows us to create and respond to custom events.

const EventEmitter = require("events");

const emitter = new EventEmitter();

We can listen for an event:

emitter.on("login", () => {
    console.log("User logged in");
});

Then emit the event:

emitter.emit("login");

Output:

User logged in

The basic idea is:

.on()
  ↓
Listen for an event

.emit()
  ↓
Trigger an event

This event-driven approach is used throughout Node.js.

11. What Are Streams?

Imagine we have a 5 GB file.

One approach would be:

5 GB file
   ↓
Load everything into memory
   ↓
Process it

This can consume a large amount of memory.

Streams allow us to process data in smaller pieces called chunks.

Large File
    ↓
 Chunk
    ↓
Process
    ↓
 Chunk
    ↓
Process
    ↓
 Chunk
    ↓
Process

This makes streams especially useful for large files, network communication, and other continuous data.

12. Types of Streams

Node.js has four important stream types:

Readable
Writable
Duplex
Transform

Readable Stream

A readable stream is used to read data.

For example:

const fs = require("fs");

const stream = fs.createReadStream("large.txt");

The data flows from the source into our application.

File
 ↓
Readable Stream
 ↓
Application

Writable Stream

A writable stream is used to write data.

const stream = fs.createWriteStream("output.txt");

stream.write("Hello");
stream.write(" Node.js");

stream.end();

The data flows from our application to the destination.

Application
    ↓
Writable Stream
    ↓
File

Duplex Stream

A duplex stream can both read and write data.

Readable
    +
Writable
    =
Duplex

A network socket is a common example.

Send data
    ↕
Socket
    ↕
Receive data

Transform Stream

A transform stream reads data, modifies it, and produces new output.

Input
  ↓
Transform
  ↓
Output

For example:

"hello"
   ↓
uppercase transformation
   ↓
"HELLO"

Compression streams are another common example.

13. Buffers

A Buffer is used to work with raw binary data.

Computers don't only deal with text. Files, images, videos, network packets, and other data can be represented as bytes.

Node.js provides the Buffer class for handling this type of data.

For example:

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

console.log(buffer);

You may see something similar to:

<Buffer 48 65 6c 6c 6f>

We can convert the Buffer back to text:

console.log(buffer.toString());

Output:

Hello

Buffers are commonly used with:

File systems
Streams
Network communication
Binary data

14. The `process` Object

Node.js provides a global object called process.

It represents the currently running Node.js process.

For example:

console.log(process);

We don't normally need to import it.

Command-line arguments

console.log(process.argv);

If we run:

node app.js hello

Node.js makes the command-line arguments available through process.argv.

Environment variables

We can access environment variables using:

console.log(process.env);

For example:

console.log(process.env.PORT);

This is commonly used for configuration such as:

PORT
DATABASE_URL
API_KEY
NODE_ENV

Exiting the process

We can explicitly terminate a process:

process.exit(1);

Exit code 0 generally indicates successful completion, while a non-zero code commonly indicates an error.

15. What Does Non-Blocking I/O Mean?

This is one of the most important ideas in Node.js.

I/O means Input/Output.

Examples include:

Reading a file
Writing a file
Sending a network request
Receiving network data
Communicating with a database

A blocking approach looks conceptually like this:

Start operation
      ↓
   WAIT
      ↓
Operation finishes
      ↓
Continue

The program cannot continue that particular execution path until the operation finishes.

Node.js is designed around a non-blocking approach.

Conceptually:

Start I/O operation
        ↓
Don't wait
        ↓
Continue executing JavaScript
        ↓
Do other work
        ↓
I/O completes
        ↓
Handle the result

For example:

const fs = require("fs");

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

console.log("Next task");

The important idea is that the file operation is started, while JavaScript can continue executing other work.

16. Why Is Non-Blocking I/O Useful?

Imagine a server receives 1,000 requests.

Many of those requests may involve waiting for:

Database
File system
Network
External API

If the server blocked while waiting for each operation, resources could be wasted waiting.

Node.js instead tries to keep the JavaScript execution moving:

Request 1 → I/O operation
Request 2 → I/O operation
Request 3 → I/O operation
Request 4 → I/O operation
       ...
       ↓
Results become ready
       ↓
Callbacks / promise continuations execute

This makes Node.js particularly well suited to I/O-heavy applications such as APIs, web servers, real-time applications, and network services.

17. How Everything Connects

Now let's connect all the concepts.

                         Node.js
                            │
              ┌─────────────┴─────────────┐
              ↓                           ↓
             V8                         libuv
              │                           │
        Executes JS               Async operations
                                          │
                                   ┌──────┴──────┐
                                   ↓             ↓
                              Event Loop    Thread Pool
                                   │
                                   ↓
                              Callbacks

Node.js also provides core modules:

fs       → File system
path     → File paths
os       → Operating system information
events   → Event-driven programming
streams  → Process data in chunks
buffer   → Raw binary data
process  → Current Node.js process

All of these concepts work together to form the Node.js runtime.

Conclusion

Node.js is not simply a way to run JavaScript outside the browser. It is a runtime built around an event-driven and non-blocking I/O model.

The important concepts to remember are:

V8 executes JavaScript.
libuv provides important asynchronous I/O capabilities and the event loop implementation.
The event loop coordinates asynchronous callbacks.
Core modules provide functionality such as file-system and operating-system access.
Streams process data incrementally instead of requiring the entire data set to be loaded at once.
Buffers handle raw binary data.
The process object provides information and control over the running Node.js process.
Non-blocking I/O allows Node.js to continue doing useful work instead of unnecessarily waiting for I/O operations.

Once these concepts are clear, topics such as Express.js, HTTP servers, APIs, asynchronous programming, streams, and backend architecture become much easier to understand.

Deep Git Workflows: Rebasing, Conflict Resolution and Branching Strategies

Sai Swaroop Bijinapalli — Thu, 20 Aug 2026 06:28:42 +0000

Deep Git Workflows: Rebasing, Conflict Resolution and Branching Strategies

Git is more than just a tool for storing code. It helps developers manage changes, collaborate with teams, experiment with new features, fix bugs, and maintain a clear history of how a project evolved.

As projects become larger and multiple developers work on the same codebase, basic commands such as git add, git commit, and git push are not enough. Developers need to understand advanced Git workflows such as rebasing, merging, conflict resolution, stashing, cherry-picking, reverting, resetting, tagging, and branching strategies.

A well-managed Git history can also act as documentation for a project because it tells us what changed, when it changed, and why it changed.

1. Merge vs Rebase

Two common ways to combine changes from different branches are merge and rebase.

Suppose the project looks like this:

A---B---C        main
     \
      D---E      feature

The feature branch was created from main, and both branches continued to receive commits.

Git Merge

To merge the feature branch:

git switch main
git merge feature

Git combines the histories and may create a merge commit:

A---B---C---------M
     \           /
      D---E-----/

The merge approach preserves the original development history.

Advantages of Merge

Preserves the complete history.
Does not rewrite existing commits.
Safe for shared branches.
Clearly shows that two branches were combined.

Disadvantage

If a project has many branches and frequent merges, the history can become complicated.

2. Git Rebase

Rebase takes commits from one branch and replays them on top of another branch.

For example:

A---B---C        main
     \
      D---E      feature

Run:

git switch feature
git rebase main

The result becomes:

A---B---C---D'---E'

Git reapplies the feature commits on top of the latest main. The Git documentation describes rebase as reapplying commits on top of another base.

The ' is important. D' and E' are new commit objects because their parent history has changed.

Advantages of Rebase

Produces a cleaner, linear history.
Makes project history easier to read.
Helps clean up local feature branches.
Makes Pull Request history easier to understand.

Disadvantage

Rebase rewrites commit history.

Therefore, you should be careful when rebasing commits that other developers have already based their work on. Git's documentation specifically warns that rewriting a branch others depend on can force downstream developers to repair their history.

3. Merge vs Rebase

The basic difference can be remembered like this:

Merge  → Preserve the story
Rebase → Rewrite the story more cleanly

Merge	Rebase
Preserves history	Rewrites history
May create merge commit	Creates a linear history
Good for shared branches	Good for private/local branches
Safer for collaboration	Useful for cleaning history
Shows branch structure	Hides unnecessary branching details

A practical rule is:

Do not casually rebase shared/public history. Rebase your own local feature work when you need a cleaner history.

4. Interactive Rebase

Interactive rebase provides more control over your commits.

Suppose you have:

A---B---C---D---E

You can inspect the last three commits with:

git rebase -i HEAD~3

Git opens a list such as:

pick C Add login
pick D Fix login CSS
pick E Fix login validation

You can modify these commands to clean up your history.

Common operations include:

pick — keep the commit.
reword — change the commit message.
edit — stop and modify the commit.
squash — combine the commit with the previous one.
fixup — combine commits while discarding the later commit message.
drop — remove a commit.

Git's interactive rebase supports reordering and combining commits.

5. Squashing Commits

During development, you may create commits such as:

Add login
Fix login
Fix login again
Fix validation
Final login fix

These commits may be useful while developing, but they are not necessarily useful in the final project history.

You can squash them:

git rebase -i HEAD~5

Change:

pick A Add login
pick B Fix login
pick C Fix login again
pick D Fix validation
pick E Final login fix

to:

pick A Add login
squash B Fix login
squash C Fix login again
squash D Fix validation
squash E Final login fix

The result can become one meaningful commit:

Add login functionality

This makes the history much easier to understand.

Git's workflow documentation recommends keeping changes as small logical steps and notes that interactive rebase can be used to clean up commits before publishing them.

6. Reordering Commits

You can also change the order of commits.

For example:

pick A Add login
pick B Update README
pick C Add authentication

can become:

pick A Add login
pick C Add authentication
pick B Update README

This can make the history follow a more logical development sequence.

However, reordering commits can cause conflicts if later commits depend on earlier ones.

7. Editing Commits

Suppose you realize that a commit is missing a file.

You can use:

edit

For example:

pick A Add login
edit B Add authentication
pick C Update README

Git stops at commit B.

You can modify the files:

git add .
git commit --amend
git rebase --continue

This allows you to correct or improve an existing commit.

8. Resolving Merge Conflicts

A conflict happens when Git cannot automatically decide which version of a change should be kept.

For example, one branch contains:

const username = "Swaroop";

while another branch contains:

const username = "Sai";

If both branches changed the same line, Git may produce:

<<<<<<< HEAD
const username = "Swaroop";
=======
const username = "Sai";
>>>>>>> feature

The developer must decide what the correct code should be.

For example:

const username = "Sai Swaroop";

Then:

git add .
git commit

During a rebase:

git add .
git rebase --continue

If you want to cancel the rebase:

git rebase --abort

Git's documentation recommends resolving the conflict, staging the resolved files, and then continuing the rebase.

9. Git Stash

Sometimes you have unfinished work but need to switch branches.

For example:

feature/login
    ↓
unfinished changes

You don't want to commit incomplete code.

Use:

git stash

Git temporarily stores the changes.

Now you can switch branches:

git switch main

After finishing your other work:

git switch feature/login
git stash pop

Your unfinished changes are restored.

Think of git stash as:

Temporarily putting unfinished work aside without committing it.

Git includes stash as one of its standard branching and merging tools.

10. Git Cherry-Pick

Cherry-pick is useful when you want to copy a particular commit from another branch.

Suppose:

main:
A---B---C

feature:
     \
      D---E

You only want commit E on main.

Run:

git switch main
git cherry-pick E

You get:

A---B---C---E'

The changes from E are applied as a new commit on main.

A common use case is a bug fix.

For example:

feature/payment
    ↓
Fix payment calculation

You may want that specific fix in a release branch without bringing the entire feature branch.

11. Git Revert

Suppose your history is:

A---B---C---D

You discover that D introduced a bug.

You can run:

git revert D

Git creates a new commit that reverses the changes from D:

A---B---C---D---R

R represents the revert commit.

This is generally safer for shared branches because the original history remains intact.

Git defines revert as creating a new commit that reverses the changes introduced by an earlier commit.

12. Git Reset

Reset works differently.

Suppose:

A---B---C---D

You run:

git reset --hard C

Now the branch points to:

A---B---C

Commit D is no longer part of the current branch history.

Git documentation describes reset as moving the branch tip and therefore changing the branch history.

There are three important reset modes.

Soft Reset

git reset --soft HEAD~1

Moves the branch backward but keeps the changes staged.

Mixed Reset

git reset --mixed HEAD~1

Moves the branch backward and keeps the changes in the working directory, but unstages them.

This is the default reset mode.

Hard Reset

git reset --hard HEAD~1

Moves the branch backward and discards the changes.

Be careful with --hard.

13. Revert vs Reset

The easiest way to remember the difference:

Revert → Undo using a NEW commit
Reset  → Move the branch BACKWARD

Revert	Reset
Creates a new commit	Moves branch pointer
Preserves history	Changes history
Safer for shared branches	Better for local cleanup
Good for undoing published changes	Useful for undoing local commits

If a commit has already been pushed and other developers may depend on it, git revert is generally the safer choice.

14. Git Tags

Tags are used to mark important points in Git history.

For example:

A---B---C---D---E
        ↑
       v1.0.0

Create a tag:

git tag v1.0.0

View tags:

git tag

Push a tag:

git push origin v1.0.0

Tags are useful for software releases:

v1.0.0
v1.1.0
v2.0.0

A tag makes it easy to identify the exact commit associated with a release.

15. Branching Strategies

A branching strategy defines how developers organize branches within a project.

Three commonly discussed approaches are:

Git Flow
GitHub Flow
Trunk-Based Development

16. Git Flow

Git Flow typically uses branches such as:

main
develop
feature/*
release/*
hotfix/*

For example:

             feature/login
                  |
                  ↓
develop ----------●
                  |
                  ↓
               release
                  |
                  ↓
main -------------●

A developer might create:

git switch -c feature/login

After development, the feature is integrated into develop.

When a release is prepared, a release branch can be created and eventually merged into main.

Advantages

Clear separation between development and production.
Useful for scheduled release cycles.
Provides dedicated release and hotfix branches.

Disadvantages

More complicated.
More branches to maintain.
Can be unnecessary for projects that deploy continuously.

17. GitHub Flow

GitHub Flow is simpler.

main
  |
  ↓
feature branch
  |
  ↓
Pull Request
  |
  ↓
main

Example:

git switch main
git pull

git switch -c feature/login

git add .
git commit -m "Add login functionality"

git push -u origin feature/login

Then a Pull Request is created.

After review and approval:

feature/login → main

This workflow is popular for projects where changes are integrated and deployed frequently.

18. Trunk-Based Development

Trunk-based development focuses on keeping the main branch continuously integrated.

main ──●────●────●────●────●────●──
       ↑    ↑    ↑    ↑
      small feature changes

Branches, when used, are usually short-lived.

Instead of keeping a feature branch for several weeks, developers integrate small changes frequently.

The main idea is:

Small changes + frequent integration = fewer large conflicts.

This approach works particularly well with automated testing and Continuous Integration/Continuous Deployment (CI/CD).

19. Comparing Branching Strategies

Strategy	Complexity	Branches	Suitable For
Git Flow	High	Many	Scheduled releases
GitHub Flow	Medium	Feature branches	Web applications
Trunk-Based	Low	Very short-lived	CI/CD and frequent deployment

There is no single strategy that is best for every project. Teams should choose based on release frequency, team size, deployment process, and project requirements.

20. Clean Git History as Documentation

One of the most valuable Git practices is maintaining a clean and meaningful history.

Imagine running:

git log --oneline

and seeing:

a81f2 fix
91bd3 changes
7ab12 final
82abc fix again
72ccd testing
61aaa final final

This tells very little about the project.

Now compare:

a81f2 Add employee search functionality
91bd3 Add employee authentication
7ab12 Add employee management API
82abc Add PostgreSQL integration

The second history is much easier to understand.

A developer joining the project later can use the Git history to understand the evolution of the application.

Git's workflow documentation recommends small, logical commits because they make code review easier and make history more useful for later inspection and analysis.

Git history can help answer questions such as:

When was this feature introduced?
Which commit changed this file?
When did this bug appear?
Which commit introduced the database integration?
What changes were part of version 1.0?
Which commit should be reverted?

Therefore:

A good Git history is a form of technical documentation.

21. A Practical Workflow

Imagine you're developing a login feature.

Start with:

A---B---C    main

Create your branch:

git switch -c feature/login

Make several commits:

A---B---C
         \
          D---E---F

Your commits might be:

D Add login form
E Fix login CSS
F Fix login validation

Before creating a Pull Request, you decide to clean the history.

Run:

git rebase -i HEAD~3

Change:

pick D Add login form
pick E Fix login CSS
pick F Fix login validation

to:

pick D Add login functionality
squash E Fix login CSS
squash F Fix login validation

Now the feature branch has a cleaner history.

Next, update it with the latest main:

git switch main
git pull

git switch feature/login
git rebase main

If the branch has already been pushed, rebasing changes its commit history, so pushing may require:

git push --force-with-lease

--force-with-lease is preferable to blindly using --force because it provides a safety check against overwriting unexpected remote updates.

22. The Golden Rules of Advanced Git

Keep these rules in mind:

Rule 1 — Rebase your own local work

Private feature branch
        ↓
       Rebase
        ↓
Clean history

Rule 2 — Be careful rebasing shared history

Shared branch
      ↓
Avoid rewriting history
      ↓
Merge / Revert

Rule 3 — Use stash for unfinished work

Unfinished changes
       ↓
git stash
       ↓
Switch branch
       ↓
git stash pop

Rule 4 — Use cherry-pick for a specific commit

Need ONE particular change
          ↓
     cherry-pick

Rule 5 — Use revert for safely undoing published changes

Published commit
      ↓
    revert
      ↓
New reversing commit

Rule 6 — Use reset carefully

Local history cleanup
        ↓
      reset

Rule 7 — Use tags for releases

Commit
  ↓
Tag
  ↓
v1.0.0

Conclusion

Advanced Git is not about memorizing dozens of commands. It is about understanding how and when to manipulate project history.

The most important concepts are:

merge       → combine branches while preserving history
rebase      → replay commits on a new base
interactive → clean/reorder/edit commits
stash       → temporarily save unfinished changes
cherry-pick → copy a specific commit
revert      → undo changes with a new commit
reset       → move the branch pointer
tag         → mark important releases

The biggest decision is often merge vs rebase.

Rebase can produce a clean and readable history, but it rewrites commits. Merge preserves the original history and is safer for shared branches. Git's own documentation emphasizes that rebasing published/shared history can create problems for developers who depend on the original commits.

Ultimately, the goal is not simply to make Git history look pretty. The goal is to make history understandable, useful, and safe for the team.

A clean history tells the story of a project—and that story can become valuable technical documentation for developers in the future.

TypeScript Concepts

Sai Swaroop Bijinapalli — Tue, 18 Aug 2026 12:58:41 +0000

TypeScript: A Beginner-Friendly Guide

TypeScript is a strongly typed programming language built on top of JavaScript. It was developed by Microsoft to make JavaScript applications easier to develop, maintain, and scale.

TypeScript adds features such as static typing, interfaces, generics, access modifiers, and better tooling while still allowing developers to use normal JavaScript features.

What is TypeScript?

TypeScript is a superset of JavaScript. This means that valid JavaScript code can generally be used in a TypeScript project, while TypeScript provides additional features on top of it.

For example, in JavaScript:

let age = 22;

In TypeScript, we can explicitly specify the type:

let age: number = 22;

If we later try:

age = "Hello";

TypeScript reports an error because age was declared as a number.

This helps catch many mistakes during development instead of discovering them only when the application runs.

Why Do We Use TypeScript?

JavaScript is dynamically typed, so a variable can change its type during execution.

For example:

let value = 10;

value = "Hello";

JavaScript allows this.

In TypeScript:

let value: number = 10;

value = "Hello"; // Error

TypeScript helps developers identify this kind of problem early.

Main advantages of TypeScript

Catches many errors during development
Provides better code completion in VS Code
Makes large projects easier to maintain
Makes function parameters and return values clearer
Provides better documentation through types
Supports interfaces and generics
Improves refactoring and code navigation

Basic TypeScript Types

TypeScript provides several commonly used types.

1. String

let username: string = "Swaroop";

The variable username can contain only a string.

2. Number

let age: number = 22;

The variable age can contain a number.

3. Boolean

let isLoggedIn: boolean = true;

The value can only be true or false.

4. Arrays

We can specify the type of elements inside an array.

let numbers: number[] = [10, 20, 30];

Another way is:

let names: Array<string> = ["Sai", "Rahul", "John"];

Both represent an array containing strings.

TypeScript Functions

TypeScript allows us to specify types for function parameters and return values.

function calculateSalary(salary: number): number {
    return salary * 12;
}

Here:

salary: number

means salary must be a number.

And:

): number

means the function must return a number.

For example:

calculateSalary(50000);

is valid.

But:

calculateSalary("50000");

produces a type error.

Interfaces

An interface defines the structure that an object should follow.

For example:

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

Now we can create an object using that structure:

const user: User = {
    name: "Swaroop",
    age: 22,
    email: "swaroop@example.com"
};

TypeScript knows that a User must have:

name  → string
age   → number
email → string

If we write:

const user: User = {
    name: "Swaroop",
    age: "22",
    email: "swaroop@example.com"
};

TypeScript reports an error because age should be a number.

Why are interfaces useful?

Interfaces are especially useful when working with:

Objects
API responses
Function parameters
Classes
Large applications

They make the expected structure of data clear.

Generics

Generics are one of the most useful TypeScript features.

A generic allows us to write reusable and type-safe code.

Consider this function:

function getValue(value: string): string {
    return value;
}

This function only accepts strings.

We could create another function for numbers, but that would duplicate code.

Instead, we can use a generic:

function getValue<T>(value: T): T {
    return value;
}

Here, T is a type parameter.

We can use it with different types:

const name = getValue<string>("Swaroop");

const age = getValue<number>(22);

const isStudent = getValue<boolean>(true);

The same function works with different types while maintaining type safety.

Simple way to understand generics

Think of T as a placeholder for a type.

T → string
T → number
T → boolean

The actual type is determined when the function is used.

TypeScript vs JavaScript

JavaScript	TypeScript
Dynamically typed	Statically typed
`.js` files	`.ts` files
No built-in static type checking	Provides static type checking
Errors may appear during runtime	Many errors can be caught during development
Uses JavaScript syntax	Adds features on top of JavaScript

TypeScript does not replace JavaScript. TypeScript code is generally transpiled/compiled into JavaScript, which can then run in browsers or Node.js.

The basic flow is:

TypeScript
    ↓
TypeScript Compiler
    ↓
JavaScript
    ↓
Browser / Node.js

Type Inference

One useful feature of TypeScript is type inference.

You don't always have to explicitly write the type.

For example:

let name = "Swaroop";

TypeScript automatically understands:

name → string

Similarly:

let age = 22;

TypeScript understands:

age → number

So you don't always need:

let name: string = "Swaroop";
let age: number = 22;

TypeScript can infer the types automatically.

TypeScript and Object-Oriented Programming

TypeScript also supports classes and object-oriented programming.

For example:

class Employee {
    constructor(
        public name: string,
        public salary: number
    ) {}

    getSalary(): number {
        return this.salary;
    }
}

We can create an object:

const employee = new Employee("Swaroop", 50000);

console.log(employee.name);
console.log(employee.getSalary());

TypeScript adds type safety to the class as well.

Conclusion

TypeScript makes JavaScript development more structured and type-safe. Its type system helps developers catch mistakes early, while features such as interfaces and generics make code easier to reuse and maintain.

For beginners, the most important concepts to learn first are:

Basic Types
     ↓
Functions
     ↓
Interfaces
     ↓
Generics
     ↓
Classes
     ↓
Advanced TypeScript

JavaScript Week 06: Modules, Design Patterns, and Memory Management

Sai Swaroop Bijinapalli — Mon, 17 Aug 2026 06:29:58 +0000

A practical guide to CommonJS, ESM, design patterns, closures, garbage collection, memory leaks, and the Open/Closed Principle.

Introduction

As JavaScript applications grow, writing code that simply works is not enough. We also need code that is organized, reusable, maintainable, and easy to extend.

In this week, I explored several concepts that help achieve this:

CommonJS and ESM modules
Design patterns
Singleton Pattern
Factory Pattern
Observer Pattern
Pub/Sub Pattern
Module Pattern
JavaScript memory management
Closures
Garbage Collection
Memory Leaks
Open/Closed Principle

These concepts are connected. Modules help organize code, design patterns provide reusable solutions to common problems, and memory management helps us understand how JavaScript handles the data created by our applications.

1. What Are JavaScript Modules?

A module is a separate file containing code that can be reused by other files.

Instead of putting the entire application into one large file:

app.js
├── user logic
├── database logic
├── authentication
├── notification logic
└── utility functions

we can divide it into smaller modules:

project/
├── user.js
├── database.js
├── auth.js
├── notification.js
└── app.js

This makes the application easier to understand and maintain.

JavaScript mainly uses two module systems:

CommonJS
ES Modules (ESM)

2. CommonJS

CommonJS is a module system that has traditionally been widely used in Node.js applications.

It uses:

require()

for importing and:

module.exports

for exporting.

Example

math.js

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

function subtract(a, b) {
    return a - b;
}

module.exports = {
    add,
    subtract
};

Now another file can import these functions.

app.js

const { add, subtract } = require("./math");

console.log(add(10, 5));
console.log(subtract(10, 5));

Output:

15
5

The main idea is:

math.js
   ↓
module.exports
   ↓
app.js
   ↓
require()

3. ES Modules (ESM)

ES Modules are the standardized modern module system in JavaScript.

ESM uses:

export

and:

import

Example

math.js

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

export function subtract(a, b) {
    return a - b;
}

app.js

import { add, subtract } from "./math.js";

console.log(add(10, 5));
console.log(subtract(10, 5));

In Node.js, ESM can be enabled by setting:

{
    "type": "module"
}

in package.json.

4. CommonJS vs ESM

CommonJS	ESM
Uses `require()`	Uses `import`
Uses `module.exports`	Uses `export`
Traditionally common in Node.js	Modern JavaScript standard
Common in older Node.js projects	Common in modern applications
Example: `require("./math")`	Example: `import { add } from "./math.js"`

Simple way to remember

CommonJS → require + module.exports

ESM → import + export

Both solve the same general problem: organizing and sharing code between files.

5. What Are Design Patterns?

A design pattern is a reusable solution to a commonly occurring software design problem.

A design pattern is not a library or framework. It is more like a proven approach to structuring code.

For example, suppose multiple components need to know when a particular event occurs.

Without a pattern, we might create many direct connections:

Component A → Component B
Component A → Component C
Component A → Component D

As the application grows, this becomes difficult to maintain.

A design pattern such as Observer can provide a cleaner structure:

             Event Source
                  |
        ┌─────────┼─────────┐
        ↓         ↓         ↓
     Observer  Observer  Observer

Design patterns help improve:

Reusability
Maintainability
Flexibility
Scalability
Code organization
Communication between developers

6. Singleton Pattern

The Singleton Pattern ensures that only one instance of an object exists and provides a common way to access it.

Imagine an application configuration:

              Application
                   |
             Config Manager
                   |
        ┌──────────┼──────────┐
        ↓          ↓          ↓
       API         DB       Services

We may want all parts of the application to use the same configuration object.

Example

class Config {
    constructor() {
        if (Config.instance) {
            return Config.instance;
        }

        this.port = 5000;
        this.database = "PostgreSQL";

        Config.instance = this;
    }
}

const config1 = new Config();
const config2 = new Config();

console.log(config1 === config2);

Output:

true

Both variables refer to the same instance.

Common use cases

Singleton can be useful for:

Application configuration
Logging
Cache managers
Shared service managers

However, Singleton should not be used everywhere. Excessive use can make testing and dependency management more difficult.

7. Factory Pattern

The Factory Pattern is a creational pattern used to create objects without requiring the calling code to know the exact creation logic.

Imagine a notification system supporting:

Email
SMS
Push notifications

Instead of creating each object directly, we can use a factory.

              Notification Factory
                      |
             ┌────────┼────────┐
             ↓        ↓        ↓
           Email      SMS     Push

Example

class EmailNotification {
    send() {
        console.log("Sending Email");
    }
}

class SMSNotification {
    send() {
        console.log("Sending SMS");
    }
}

class PushNotification {
    send() {
        console.log("Sending Push Notification");
    }
}

function createNotification(type) {
    if (type === "email") {
        return new EmailNotification();
    }

    if (type === "sms") {
        return new SMSNotification();
    }

    if (type === "push") {
        return new PushNotification();
    }

    throw new Error("Unknown notification type");
}

Usage:

const notification = createNotification("email");

notification.send();

Output:

Sending Email

The caller only needs to specify the type:

createNotification("email");

It does not need to know how EmailNotification is constructed.

Common use cases

Factory patterns are useful for:

Notifications
Database drivers
Payment methods
UI components
Different service implementations

8. Observer Pattern

The Observer Pattern allows one object to notify multiple objects when something changes.

The object being observed is commonly called the Subject, while the objects receiving notifications are called Observers.

                 Subject
                    |
                 notify()
                    |
        ┌───────────┼───────────┐
        ↓           ↓           ↓
    Observer A  Observer B  Observer C

Example

class Subject {
    constructor() {
        this.observers = [];
    }

    subscribe(observer) {
        this.observers.push(observer);
    }

    notify(message) {
        this.observers.forEach(observer => {
            observer(message);
        });
    }
}

const subject = new Subject();

subject.subscribe(message => {
    console.log("User A:", message);
});

subject.subscribe(message => {
    console.log("User B:", message);
});

subject.notify("New video uploaded!");

Output:

User A: New video uploaded!
User B: New video uploaded!

A real-world example is a YouTube channel.

When a channel uploads a new video, multiple subscribers can be notified.

9. Pub/Sub Pattern

Pub/Sub stands for Publisher/Subscriber.

It is similar to Observer, but the publisher and subscribers communicate through an intermediate event system, often called an Event Bus.

Publisher
    |
    ↓
 Event Bus
    |
    ├──→ Subscriber A
    ├──→ Subscriber B
    └──→ Subscriber C

The publisher does not need to know who the subscribers are.

Example

class EventBus {
    constructor() {
        this.events = {};
    }

    on(event, callback) {
        if (!this.events[event]) {
            this.events[event] = [];
        }

        this.events[event].push(callback);
    }

    emit(event, data) {
        if (!this.events[event]) {
            return;
        }

        this.events[event].forEach(callback => {
            callback(data);
        });
    }
}

const bus = new EventBus();

bus.on("login", username => {
    console.log(`${username} logged in`);
});

bus.emit("login", "Swaroop");

Output:

Swaroop logged in

Observer vs Pub/Sub

The main difference is coupling.

Observer:

Subject → Observers

The subject generally knows about its observers.

Pub/Sub:

Publisher → Event Bus → Subscribers

The publisher and subscribers are more independent.

Pub/Sub is especially useful in event-driven systems.

10. Module Pattern

The Module Pattern is used to organize code and provide encapsulation.

One important benefit is keeping some data private while exposing only selected functions.

Example

const counter = (function () {

    let count = 0;

    return {
        increment() {
            count++;
        },

        getCount() {
            return count;
        }
    };

})();

Usage:

counter.increment();
counter.increment();

console.log(counter.getCount());

Output:

But:

console.log(counter.count);

returns:

undefined

because count is not directly exposed.

The structure is:

Module
│
├── Private Data
│   └── count
│
└── Public API
    ├── increment()
    └── getCount()

The Module Pattern is strongly connected to closures.

11. JavaScript Memory Basics

Whenever JavaScript creates values and objects, memory is required to store them.

A simplified view is:

JavaScript Memory
       |
   ┌───┴────┐
   ↓        ↓
 Stack     Heap

Stack

The stack is commonly associated with:

Function calls
Execution contexts
Primitive values and references

Heap

The heap is commonly used for dynamically allocated objects and other data.

For example:

const user = {
    name: "Swaroop"
};

The object is stored in memory, while the variable holds a reference to it.

The exact memory implementation is engine-specific, but this stack/heap model is useful for understanding JavaScript memory behavior.

12. Garbage Collection

JavaScript automatically manages memory using Garbage Collection (GC).

The basic idea is that objects that are no longer reachable can eventually have their memory reclaimed.

For example:

let user = {
    name: "Swaroop"
};

user = null;

After user is changed to null, the original object may no longer be reachable.

Conceptually:

Object
  ↑
 user

After:

user = null;

the reference is removed:

Object

(no reachable reference)

The garbage collector can eventually reclaim that memory.

Important point

Garbage collection does not necessarily happen immediately when an object becomes unused.

The JavaScript engine decides when garbage collection should occur.

13. Closures

A closure occurs when a function remembers and can access variables from its surrounding lexical scope, even after the outer function has finished executing.

Example

function createCounter() {
    let count = 0;

    return function () {
        count++;
        return count;
    };
}

const counter = createCounter();

console.log(counter());
console.log(counter());

Output:

1
2

Normally, we might expect count to disappear when createCounter() finishes.

But the returned function still references count.

Therefore, the JavaScript engine keeps the required environment reachable.

createCounter()
      |
      ↓
 count = 0
      |
      ↓
returned function
      |
      ↓
remembers count

Closures are useful for:

Private variables
Encapsulation
Function factories
Callbacks
Maintaining state

14. Closures and Memory

Closures are not automatically a problem.

In fact, closures are one of the most useful features of JavaScript.

However, a closure can keep references to data alive for as long as the closure itself remains reachable.

For example:

function createFunction() {
    const largeData = new Array(1000000).fill("data");

    return function () {
        console.log(largeData.length);
    };
}

const fn = createFunction();

The returned function references largeData, so that data remains reachable through the closure.

If a long-lived object keeps fn alive unnecessarily, the referenced data may also remain in memory.

This is why understanding closures is important when debugging memory usage.

15. What Is a Memory Leak?

A memory leak happens when an application continues to hold references to memory that it no longer needs.

Because the memory is still reachable, the garbage collector cannot reclaim it.

Conceptually:

Application
    |
    ↓
Unnecessary reference
    |
    ↓
Object remains reachable
    |
    ↓
Garbage Collector cannot remove it

Common Causes

1. Growing collections

const users = [];

function addUser(user) {
    users.push(user);
}

If the array continues growing forever without removing unnecessary entries, memory usage can increase.

2. Event listeners

When an event listener is no longer needed, it should be removed when appropriate.

element.addEventListener("click", handler);

Later:

element.removeEventListener("click", handler);

3. Timers

A timer that continues running unnecessarily can keep references alive.

const intervalId = setInterval(() => {
    console.log("Running...");
}, 1000);

When it is no longer needed:

clearInterval(intervalId);

4. Unnecessary global references

Large objects stored in long-lived global structures can remain reachable for the lifetime of the application.

5. Long-lived closures

A closure can unintentionally retain references to data that is no longer needed.

16. Design Patterns as Reusable Solutions

The most important thing about design patterns is not memorizing their names.

Instead, think:

What problem am I trying to solve?

Then select an appropriate pattern.

Problem	Pattern
Need a single shared instance	Singleton
Need flexible object creation	Factory
Need to notify dependent objects	Observer
Need loosely coupled event communication	Pub/Sub
Need private state and encapsulation	Module
Need organized code across files	Modules

For example:

Problem:
Different parts of an application need the same configuration.

Solution:
Singleton.

Another example:

Problem:
The application supports Email, SMS and Push notifications.

Solution:
Factory.

And:

Problem:
Several components need to react when an event occurs.

Solution:
Observer or Pub/Sub.

This problem-solving mindset is more valuable than simply memorizing pattern definitions.

17. Open/Closed Principle

The Open/Closed Principle (OCP) is one of the SOLID principles.

It states:

Software entities should be open for extension but closed for modification.

In simpler words:

We should be able to add new behavior without repeatedly changing existing, working code.

18. Open/Closed Principle: Bad Example

Consider a notification function:

function sendNotification(type, message) {

    if (type === "email") {
        console.log("Sending Email:", message);
    }

    else if (type === "sms") {
        console.log("Sending SMS:", message);
    }

    else if (type === "push") {
        console.log("Sending Push:", message);
    }
}

Now imagine we want to add WhatsApp.

We have to modify the existing function:

else if (type === "whatsapp") {
    console.log("Sending WhatsApp:", message);
}

If we continue adding notification types, the function keeps growing.

This makes the code harder to maintain.

19. Open/Closed Principle: Better Design

We can separate each notification implementation.

class EmailNotification {
    send(message) {
        console.log("Email:", message);
    }
}

class SMSNotification {
    send(message) {
        console.log("SMS:", message);
    }
}

class PushNotification {
    send(message) {
        console.log("Push:", message);
    }
}

Then use a factory to create the required notification:

function createNotification(type) {

    const notifications = {
        email: EmailNotification,
        sms: SMSNotification,
        push: PushNotification
    };

    const Notification = notifications[type];

    if (!Notification) {
        throw new Error("Unknown notification type");
    }

    return new Notification();
}

Usage:

const notification = createNotification("email");

notification.send("Hello!");

Now the system is easier to extend because each notification type has its own implementation.

This demonstrates how design patterns and design principles can work together.

20. How These Concepts Connect

All of these topics are related to writing better software.

                 JavaScript Application
                         |
        ┌────────────────┼────────────────┐
        ↓                ↓                ↓
     Modules        Design Patterns     Memory
        |                |                |
    ┌───┴───┐       ┌────┼────┐      ┌───┼────┐
    ↓       ↓       ↓    ↓    ↓      ↓   ↓    ↓
CommonJS  ESM   Singleton Factory Observer GC Closures
                              |
                           Pub/Sub
                              |
                         Module Pattern

The relationships can be understood like this:

Modules

Help us organize and separate code.

Design Patterns

Help us solve recurring design problems.

Closures

Help us maintain state and create private data.

Garbage Collection

Helps JavaScript automatically reclaim unreachable memory.

Memory Leak Awareness

Helps developers avoid unnecessarily retaining memory.

Open/Closed Principle

Helps us design software that can grow without constantly modifying existing code.

21. Real-World Example

Consider an e-commerce application.

We could use different concepts together:

Modules

Separate the application:

users.js
products.js
payments.js
notifications.js

Factory

Create different payment methods:

Payment Factory
      |
 ┌────┼────┐
 ↓    ↓    ↓
UPI Card Wallet

Singleton

Maintain shared application configuration.

Observer/Pub/Sub

Notify different parts of the application when an order is placed:

Order Created
      |
      ↓
  Event Bus
   /   |   \
  ↓    ↓    ↓
Email Inventory Analytics

Module Pattern

Keep sensitive internal state private.

Closures

Maintain state inside functions.

Garbage Collection

Reclaim memory when objects are no longer reachable.

Open/Closed Principle

Allow new payment methods or notification types to be added without heavily modifying existing logic.

This is where these concepts become useful in real applications.

22. Key Takeaways

After studying these concepts, the main lessons are:

CommonJS and ESM provide ways to organize and share JavaScript code.
Design patterns are reusable approaches to recurring software design problems.
Singleton provides one shared instance.
Factory centralizes object creation.
Observer allows objects to react to changes.
Pub/Sub provides loosely coupled event communication.
Module Pattern provides encapsulation and private state.
Closures allow functions to retain access to their surrounding variables.
Garbage Collection automatically reclaims unreachable memory.
Memory leaks happen when unnecessary objects remain reachable.
Open/Closed Principle encourages extending functionality without unnecessarily modifying existing code.
Good software design is about choosing the right solution for the problem rather than using patterns everywhere.

Conclusion

Week 06 helped me understand that JavaScript development is not only about writing functions and getting the correct output. As applications become larger, code organization, reusability, maintainability, and memory management become increasingly important.

Modules such as CommonJS and ESM help organize code. Design patterns such as Singleton, Factory, Observer, Pub/Sub, and Module provide reusable approaches to common problems. Closures explain how JavaScript can preserve state, while garbage collection and memory-leak concepts help us understand how memory is managed.

Finally, the Open/Closed Principle introduced an important design mindset: build software that can be extended without constantly changing stable existing code.

Understanding these concepts provides a strong foundation for building larger and more maintainable JavaScript and Node.js applications.

JavaScript Design Patterns: Singleton and Factory Explained with Real Examples

Sai Swaroop Bijinapalli — Fri, 14 Aug 2026 06:55:33 +0000

JavaScript Design Patterns: Singleton and Factory Explained with Real Examples

When developing software, we often face the same types of problems repeatedly.

For example:

How should we create objects?
Should every part of the application create its own object?
How can multiple parts of an application share the same object?
How can we add new types of objects without changing existing code?

Instead of solving these problems from scratch every time, software engineering provides design patterns.

This blog focuses on understanding design patterns conceptually and then implementing two important patterns in JavaScript:

Singleton Pattern
Factory Pattern

What Is a Design Pattern?

A design pattern is a reusable solution or approach to a commonly occurring software design problem.

It is important to understand that a design pattern is not a library or a ready-made piece of code.

It is more like a blueprint.

For example, an architect may have a standard approach for designing a particular type of building. The actual building can be different, but the underlying design idea can be reused.

Similarly, a design pattern gives us a proven way to structure software.

Why Do We Need Design Patterns?

Imagine an application where every developer solves object creation differently.

One developer writes:

```js id="cxk6wq"
const user = {
name: "Sai"
};




Another creates a class:



```js id="f3yykp"
class User {
    constructor(name) {
        this.name = name;
    }
}

Another creates a factory function:

```js id="i6gtdj"
function createUser(name) {
return {
name
};
}




All of these can work, but as applications become larger, we need consistent and maintainable approaches.

Design patterns provide commonly understood structures.

---

# Categories of Design Patterns

Design patterns are commonly grouped into categories.

### Creational Patterns

These deal with **object creation**.

Examples:

* Singleton
* Factory
* Builder

### Structural Patterns

These deal with how objects and classes are combined.

Examples:

* Adapter
* Decorator
* Facade

### Behavioral Patterns

These deal with communication and behavior between objects.

Examples:

* Observer
* Strategy
* Command

For this part of Week-06, the main focus is on **creational patterns**, particularly Singleton and Factory.

---

# Singleton Pattern

Let's start with the Singleton Pattern.

The easiest way to understand Singleton is:

> **One object should exist, and everyone who needs it should use that same object.**

This is the key idea.

---

# Why Would We Need Only One Object?

Consider application configuration.

Suppose our application has:



```text id="d8pjk6"
Application Name
Environment
Port
API URL
Database Configuration

You could create a configuration object in every module:

```text id="gqaf3a"
user.js → Configuration A
payment.js → Configuration B
server.js → Configuration C
database.js → Configuration D




Now we have multiple configuration objects.

That can cause inconsistency.

Instead, we may want:



```text id="6ctf3b"
                  Configuration
                       ↑
          ┌────────────┼────────────┐
          │            │            │
       user.js     payment.js    server.js

Every module accesses the same configuration instance.

This is where Singleton becomes useful.

Singleton in Simple Terms

Think about a Singleton like a single shared resource.

The rule is:

```text id="z4j0wb"
First request
↓
Create object

Second request
↓
Return existing object

Third request
↓
Return existing object




The object is created only once.

---

# Singleton Example

Let's create a configuration manager.



```js id="jv4o4s"
class ConfigManager {

    constructor() {

        if (ConfigManager.instance) {
            return ConfigManager.instance;
        }

        this.config = {
            appName: "My Application",
            environment: "development",
            port: 3000
        };

        ConfigManager.instance = this;
    }

    get(key) {
        return this.config[key];
    }

    set(key, value) {
        this.config[key] = value;
    }
}

Now:

```js id="l8o5m0"
const config1 = new ConfigManager();
const config2 = new ConfigManager();

console.log(config1 === config2);




Output:



```text id="5l5xwi"
true

Why?

Because the second call doesn't create a new object.

It returns the already existing instance.

Understanding the Singleton Step by Step

Initially:

```text id="90s1k3"
ConfigManager.instance
↓
undefined




First:



```js id="8k0xkb"
const config1 = new ConfigManager();

There is no existing instance, so the constructor creates one.

```text id="7xkwcg"
ConfigManager.instance
↓
Object A




Now:



```js id="a0a52k"
const config2 = new ConfigManager();

The constructor checks:

```js id="5z0zsk"
if (ConfigManager.instance) {
return ConfigManager.instance;
}




An instance already exists.

Therefore:



```text id="o2i90s"
config1 ─────┐
             ↓
          Object A
             ↑
config2 ─────┘

Both variables reference the same object.

Singleton and Shared State

This is another important concept.

Suppose:

```js id="vym9qz"
config1.set("port", 5000);




Now:



```js id="8a3rwh"
console.log(config2.get("port"));

Output:

```text id="3vpt8x"
5000




Why?

Because `config1` and `config2` are not two independent objects.

They reference the same object.

This means changes made through one reference are visible through the other.

---

# When Can Singleton Be Useful?

Common examples include:

### Configuration Manager

One application configuration.

### Logger

A centralized logging system.

### Database Connection Manager

A shared connection-management object.

### Cache Manager

One shared cache.

However, Singleton should not automatically be used everywhere.

Creating global shared state can also make applications harder to test and reason about.

The important principle is:

> Use Singleton when having exactly one shared instance is actually part of the application's requirements.

---

# Factory Pattern

Now let's look at the Factory Pattern.

The Factory Pattern solves a different problem.

Singleton asks:

> **"How can I make sure there is only one object?"**

Factory asks:

> **"How can I centralize the creation of different objects?"**

---

# Factory in Simple Terms

Imagine a factory in the real world.

You tell the factory:



```text id="78shm2"
"Build me a car"

The factory handles the details of producing the car.

You don't need to know every internal step.

Similarly, a JavaScript Factory can receive information and create the appropriate object.

Simple Factory Function

Consider:

```js id="n9b4ex"
function createEmployee(name, role) {

return {
    name,
    role
};

}




Now:



```js id="s3pqg0"
const employee1 = createEmployee("Sai", "Developer");
const employee2 = createEmployee("Rahul", "Tester");

The factory function creates objects for us.

The important idea is:

```text id="2x0uyg"
Input
↓
Factory
↓
Object




---

# Why Use a Factory?

Imagine an application that supports different notification types:



```text id="g5th0w"
Email
SMS
Push

Without a Factory, different parts of the application might directly create these objects:

```js id="d5xv7y"
new EmailNotification();
new SMSNotification();
new PushNotification();




Now object creation logic is spread throughout the application.

Instead, we can centralize it:



```js id="m4e6km"
NotificationFactory.create("email");
NotificationFactory.create("sms");
NotificationFactory.create("push");

The Factory decides which object needs to be created.

Notification Factory Example

```js id="8h6wkw"
class EmailNotification {

send(message) {
    console.log(`Email: ${message}`);
}

}

class SMSNotification {

send(message) {
    console.log(`SMS: ${message}`);
}

}

class PushNotification {

send(message) {
    console.log(`Push: ${message}`);
}

}




Now create the Factory:



```js id="7s2k3p"
class NotificationFactory {

    static create(type) {

        switch (type) {

            case "email":
                return new EmailNotification();

            case "sms":
                return new SMSNotification();

            case "push":
                return new PushNotification();

            default:
                throw new Error("Unsupported notification type");
        }

    }

}

Now the application can simply say:

```js id="x1k9jf"
const notification =
NotificationFactory.create("email");

notification.send("Welcome!");




Output:



```text id="e47g4k"
Email: Welcome!

The application doesn't need to know the details of how the EmailNotification object was created.

Understanding the Factory Flow

For Email:

```text id="7unxob"
NotificationFactory
|
| "email"
↓
EmailNotification
|
↓
send()




For SMS:



```text id="iz0lqf"
NotificationFactory
        |
        | "sms"
        ↓
SMSNotification
        |
        ↓
send()

For Push:

```text id="4dd20p"
NotificationFactory
|
| "push"
↓
PushNotification
|
↓
send()




The Factory hides the object creation details.

---

# Factory vs Singleton

This is one of the most important differences to understand.

| Singleton                             | Factory                                 |
| ------------------------------------- | --------------------------------------- |
| Controls the number of instances      | Controls object creation                |
| Usually provides one shared instance  | Can create many objects                 |
| Focuses on reuse of the same instance | Focuses on selecting/creating an object |
| Example: Config Manager               | Example: Notification Factory           |

### Singleton



```text id="f5y22a"
getInstance()
     ↓
Same Object
     ↓
Same Object
     ↓
Same Object

Factory

```text id="p5j1vh"
create("email")
↓
Email Object

create("sms")
↓
SMS Object

create("push")
↓
Push Object




This difference is extremely important.

---

# Connecting Factory with Open/Closed Thinking

Now we can connect this topic to the **Open/Closed Principle**.

The Open/Closed Principle states:

> **Software should be open for extension but closed for modification.**

Suppose our application initially supports:



```text id="m2p5p4"
Email
SMS
Push

Later, we want to add:

```text id="d5d0fj"
WhatsApp




The Factory-based design gives us a clear place to extend the system.

We can introduce:



```js id="b0fkli"
class WhatsAppNotification {

    send(message) {
        console.log(`WhatsApp: ${message}`);
    }

}

Then extend the creation logic to support it.

The larger architectural idea is:

```text id="v7j6tq"
Existing functionality
↓
stays stable

New functionality
↓
added




This is the kind of thinking the Open/Closed Principle encourages.

---

# Important Difference: Pattern vs Principle

These concepts are related but not the same.

### Design Pattern

A reusable design approach.

Example:



```text id="0exzfk"
Singleton
Factory
Observer

Design Principle

A guideline for designing maintainable software.

Example:

```text id="c0zq1p"
Open/Closed Principle




So:



```text id="r5iyj8"
Design Pattern
     ↓
Reusable solution

Design Principle
     ↓
Guideline for better design

Real-World Example

Imagine an e-commerce application.

Singleton

The application has one configuration manager:

```text id="bqu3hw"
Application
↓
Config Manager
↓
One Instance




### Factory

The application supports different notifications:



```text id="4xevq5"
Notification Factory
      |
      ├── Email
      ├── SMS
      └── Push

Observer

When an order is placed:

```text id="8u0q67"
Order Placed
↓
Event

↓

| | |
Email SMS Analytics




Each pattern solves a different problem.

---

# The Three Patterns at a Glance

### Singleton

**Problem:**

> I need exactly one shared instance.

**Solution:**

> Create it once and return the same instance.

---

### Factory

**Problem:**

> I have different object types and don't want object creation logic scattered throughout my application.

**Solution:**

> Centralize object creation in a Factory.

---

### Observer

**Problem:**

> Multiple parts of the application need to react when something happens.

**Solution:**

> Allow listeners/observers to subscribe and notify them when an event occurs.

---

# Final Mental Model

The easiest way to remember these patterns is:



```text id="f9e2ul"
                 DESIGN PATTERNS
                       |
        --------------------------------
        |              |               |
    Singleton        Factory        Observer
        |              |               |
   ONE object      CREATE objects    NOTIFY objects
        |              |               |
   Config         Email/SMS/Push      Events

The patterns are not just code tricks. They are ways of thinking about software design.

Singleton helps control instance creation.

Factory helps control object creation.

Observer helps control communication between objects.

Together with principles such as the Open/Closed Principle, these ideas help us build JavaScript applications that are easier to understand, extend, test, and maintain.

Week-06 Day 1: CommonJS vs ESM and Modules in JavaScript

Sai Swaroop Bijinapalli — Fri, 14 Aug 2026 06:24:31 +0000

JavaScript Modules: CommonJS vs ESM and Why Modules Matter

When a JavaScript application is small, it is possible to keep everything inside a single file. But as an application grows, putting all the code in one file becomes difficult to understand and maintain.

For example, imagine an application containing:

User authentication
Database operations
Payment processing
Notification services
Utility functions
API routes

If all of this code is placed in one JavaScript file, the file can quickly become difficult to manage.

This is where JavaScript modules become important.

What is a Module?

A module is a separate, self-contained piece of JavaScript code that handles a particular responsibility.

For example, instead of having one large file:

app.js

we can organize the application as:

project/
│
├── app.js
├── user.js
├── database.js
├── payment.js
└── utils.js

Each file becomes responsible for a particular part of the application.

The important idea is:

A module allows us to organize code into separate units and share only the functionality that other parts of the application need.

Why Do We Need Modules?

Modules solve several problems.

1. Code Organization

Instead of putting everything into one file, related functionality can be grouped together.

For example:

user.js

can contain user-related functionality, while:

database.js

contains database-related functionality.

2. Reusability

Suppose we create an add() function.

Instead of rewriting it in multiple files, we can export it from one module and reuse it.

3. Avoiding Global Variables

Without modules, variables can accidentally become globally accessible.

Modules provide a controlled scope for variables and functions.

4. Maintainability

When functionality is separated into modules, changing one part of the application becomes easier.

For example, if database logic is inside:

database.js

we don't need to search through the entire application to find database-related code.

CommonJS

CommonJS is a module system traditionally associated with Node.js.

It uses:

require()

for importing modules and:

module.exports

for exporting functionality.

Creating a CommonJS Module

Suppose we have:

math.js

Inside it:

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

function subtract(a, b) {
    return a - b;
}

module.exports = {
    add,
    subtract
};

Here we are exporting both functions.

Now another file can use them.

const math = require("./math");

console.log(math.add(10, 5));
console.log(math.subtract(10, 5));

Output:

15
5

The important flow is:

math.js
   |
   | module.exports
   ↓
Exports functions
   |
   ↓
app.js
   |
   | require()
   ↓
Uses functions

ESM — ECMAScript Modules

ESM stands for ECMAScript Modules.

It is the standardized JavaScript module system and uses:

export

and:

import

Creating an ESM Module

math.js:

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

export function subtract(a, b) {
    return a - b;
}

Then:

import { add, subtract } from "./math.js";

console.log(add(10, 5));
console.log(subtract(10, 5));

Output:

15
5

The concept is the same as CommonJS:

One file
   ↓
exports functionality
   ↓
Another file
   ↓
imports functionality

Only the syntax and module system are different.

Named Exports

With ESM, we can export multiple named values.

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

export function multiply(a, b) {
    return a * b;
}

Import them using their names:

import { add, multiply } from "./math.js";

The names need to match the exported names unless aliases are used.

Default Export

ESM also supports a default export.

export default function greet(name) {
    return `Hello ${name}`;
}

Then:

import greet from "./greet.js";

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

With a default export, the importing code can choose the local name.

CommonJS vs ESM

The main difference can be understood from the syntax.

CommonJS

Export:

module.exports = {
    add
};

Import:

const { add } = require("./math");

ESM

Export:

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

Import:

import { add } from "./math.js";

Comparison

Feature	CommonJS	ESM
Import	`require()`	`import`
Export	`module.exports`	`export`
Standard	Node.js module system	JavaScript standard
Common usage	Traditional Node.js projects	Modern JavaScript
Default syntax	`require("./file")`	`import x from "./file.js"`

The important thing is not to memorize the table.

Remember:

CommonJS → require + module.exports

ESM → import + export

Why This Matters in Node.js

Modern Node.js applications commonly use ESM, but CommonJS is still widely used in existing Node.js projects.

For example, a project may have:

const express = require("express");

which indicates CommonJS.

Another project may have:

import express from "express";

which indicates ESM.

Both approaches allow modules to be created and reused.

The important thing when working on a project is to understand which module system the project is configured to use.

Modules and Separation of Responsibility

One of the biggest benefits of modules is separation of responsibility.

Imagine an employee-management application.

Instead of:

server.js
   |
   ├── Database code
   ├── Employee code
   ├── Authentication code
   ├── Validation code
   └── Utility code

we can organize it:

server.js
   |
   ├── database.js
   ├── employee.js
   ├── auth.js
   ├── validation.js
   └── utils.js

Now each module has a clear responsibility.

This idea becomes extremely important when we start learning design patterns.

Connection to Design Patterns

Modules and design patterns solve different problems.

Modules answer:

"How should I organize and share my code?"

Design patterns answer:

"How should I structure my code to solve a recurring design problem?"

For example:

Modules
   ↓
Organize code

Design Patterns
   ↓
Structure solutions

Open/Closed Principle
   ↓
Make code easier to extend

These concepts work together when building larger applications.

A Simple Real-World Example

Imagine an online shopping application.

We might have:

shop/
│
├── user.js
├── product.js
├── cart.js
├── payment.js
└── notification.js

notification.js might export notification functionality.

Later, we might use a Factory Pattern inside that module to create:

Email Notification
SMS Notification
Push Notification

So modules give us the structure, while design patterns help us solve specific design problems inside that structure.

Key Takeaways

From this topic, the most important concepts are:

Modules divide an application into smaller, manageable pieces.
Modules improve organization, reuse, and maintainability.
CommonJS uses require() and module.exports.
ESM uses import and export.
ESM is the standardized JavaScript module system.
Modules help separate responsibilities.
Modules and design patterns are different concepts, but they work together to create maintainable applications.

The most important mental model is:

Large Application
       ↓
   Divide into
     Modules
       ↓
Organize responsibilities
       ↓
Use Design Patterns
       ↓
Solve recurring design problems
       ↓
Maintainable Application

This understanding of modules provides the foundation for the next part of Week-06: design patterns such as Singleton, Factory, and Observer.

Asynchronous JavaScript II: Promise Combinators & Concurrency Control

Sai Swaroop Bijinapalli — Wed, 12 Aug 2026 11:27:20 +0000

Week-05 Task 02 — Asynchronous JavaScript II

The main topics are:

1. async / await
2. Error handling with try/catch
3. Promise.all()
4. Promise.allSettled()
5. Promise.race()
6. Promise.any()
7. Generators
8. Iterators
9. Async iterators
10. Fail-fast vs fail-soft
11. Concurrency limiting

1. First: What is asynchronous JavaScript?

JavaScript normally executes code sequentially.

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

Output:

Start
Middle
End

But some operations take time, such as:

API requests
Database requests
File operations
Timers
Network requests

For example:

console.log("Start");

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

console.log("End");

Output:

Start
End
Data received

Why?

Because setTimeout() is asynchronous. JavaScript doesn't wait for the timer before continuing.

2. Why do we use Promises?

When an asynchronous operation finishes, we need a way to handle its result.

A Promise represents the future result of an asynchronous operation.

const promise = new Promise((resolve, reject) => {

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

});

The Promise starts as:

pending

After 2 seconds:

pending
   ↓
fulfilled

with:

value = "Data received"

3. `async/await`

async/await provides a cleaner way to work with Promises.

`async`

When we write:

async function getData() {

}

the function automatically returns a Promise.

Example:

async function hello() {
    return "Hello";
}

Although we return a string:

return "Hello";

the function actually returns a Promise.

hello().then((value) => {
    console.log(value);
});

Output:

Hello

Remember

An async function always returns a Promise.

4. `await`

await is used to get the result of a Promise.

function getData() {

    return new Promise((resolve) => {

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

    });
}

Now:

async function main() {

    const data = await getData();

    console.log(data);
}

main();

Output after 2 seconds:

Data received

What happens?

main()
 ↓
getData()
 ↓
Promise pending
 ↓
await
 ↓
wait for Promise
 ↓
resolve("Data received")
 ↓
data = "Data received"
 ↓
console.log(data)

Important

await doesn't create the value.

The value is provided by:

resolve("Data received");

Then:

const data = await getData();

receives that value.

So:

resolve() → provides value
await → receives value
data → stores value

5. Why use async/await?

Without async/await:

getData()
    .then((data) => {
        console.log(data);
    });

With async/await:

async function main() {

    const data = await getData();

    console.log(data);
}

Both work with Promises.

async/await makes asynchronous code easier to read.

6. Error handling with `try/catch`

Promises can either:

fulfill

or:

reject

Example:

function getData() {

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

        setTimeout(() => {
            reject("Server error");
        }, 2000);

    });
}

Using async/await:

async function main() {

    try {

        const data = await getData();

        console.log(data);

    } catch (error) {

        console.log("Error:", error);
    }
}

main();

Output:

Error: Server error

Flow

await getData()
       ↓
Promise rejects
       ↓
error thrown
       ↓
catch(error)
       ↓
handle error

Mentor answer

"try/catch allows us to handle rejected Promises when using async/await. If an awaited Promise rejects, the rejection is thrown as an error and the catch block handles it."

7. Promise Combinators

Suppose you have multiple asynchronous operations:

const user = getUser();
const profile = getProfile();
const posts = getPosts();

You may want to handle them together.

That's where Promise combinators are useful.

The four important combinators are:

Promise.all()
Promise.allSettled()
Promise.race()
Promise.any()

8. `Promise.all()`

Promise.all() waits for all Promises to fulfill.

Example:

const p1 = Promise.resolve("User");
const p2 = Promise.resolve("Profile");
const p3 = Promise.resolve("Posts");

Promise.all([p1, p2, p3])
    .then((results) => {

        console.log(results);

    });

Output:

[
    "User",
    "Profile",
    "Posts"
]

Important

The result order follows the input order.

Promise.all([
    p1,
    p2,
    p3
]);

Result:

[p1 result, p2 result, p3 result]

even if p3 finishes first.

9. What happens when one fails?

const p1 = Promise.resolve("User");

const p2 = Promise.reject("Profile failed");

const p3 = Promise.resolve("Posts");

Promise.all([p1, p2, p3])
    .then((results) => {

        console.log(results);

    })
    .catch((error) => {

        console.log(error);

    });

Output:

Profile failed

Promise.all() rejects when one Promise rejects.

This is called:

Fail-fast

Promise 1 → success
Promise 2 → failure
               ↓
          Promise.all()
               ↓
             reject

When should you use it?

Use Promise.all() when all operations are required.

Example:

Load user
Load permissions
Load account settings

If one required operation fails, you don't want to continue.

10. `Promise.allSettled()`

Promise.allSettled() waits for every Promise to finish, whether it succeeds or fails.

Example:

const p1 = Promise.resolve("User");

const p2 = Promise.reject("Profile failed");

const p3 = Promise.resolve("Posts");

Promise.allSettled([p1, p2, p3])
    .then((results) => {

        console.log(results);

    });

Result:

[
    {
        status: "fulfilled",
        value: "User"
    },
    {
        status: "rejected",
        reason: "Profile failed"
    },
    {
        status: "fulfilled",
        value: "Posts"
    }
]

It doesn't stop because p2 failed.

This is called:

Fail-soft

Promise 1 → success ─┐
Promise 2 → failure ─┤
Promise 3 → success ─┤
                     ↓
              allSettled()
                     ↓
              collect everything

When should you use it?

When each operation is independent.

For example:

Send email to User 1 → success
Send email to User 2 → failure
Send email to User 3 → success

You still want to know the result for every user.

11. `Promise.race()`

Promise.race() returns the result of the first Promise to settle.

Example:

const p1 = new Promise((resolve) => {

    setTimeout(() => {
        resolve("First");
    }, 1000);

});

const p2 = new Promise((resolve) => {

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

});

Promise.race([p1, p2])
    .then((result) => {

        console.log(result);

    });

Output:

First

because p1 finished first.

Important

race() cares about settling, not just success.

If the first Promise rejects:

p1 → reject after 1 second
p2 → resolve after 2 seconds

then:

Promise.race()
      ↓
reject

So:

race() = first settled Promise wins.

12. `Promise.any()`

Promise.any() waits for the first fulfilled Promise.

Example:

const p1 = Promise.reject("Server 1 failed");

const p2 = new Promise((resolve) => {

    setTimeout(() => {
        resolve("Server 2");
    }, 1000);

});

const p3 = new Promise((resolve) => {

    setTimeout(() => {
        resolve("Server 3");
    }, 2000);

});

Promise.any([p1, p2, p3])
    .then((result) => {

        console.log(result);

    });

Output:

Server 2

p1 failed, but Promise.any() ignores that rejection and waits for a successful Promise.

13. `race()` vs `any()`

This is important for interviews.

`Promise.race()`

First to settle
     ↓
success OR failure

`Promise.any()`

First to fulfill
     ↓
success only

Example:

P1 → reject in 1 sec
P2 → fulfill in 2 sec

race():

P1 rejects first
↓
race rejects

any():

P1 rejects → ignored
↓
P2 fulfills
↓
any returns P2

14. All four combinators together

Remember this:

Method	Meaning
`Promise.all()`	All must succeed
`Promise.allSettled()`	Everyone must finish
`Promise.race()`	First to settle wins
`Promise.any()`	First success wins

Easy memory trick:

ALL
↓
Everyone succeeds

ALLSETTLED
↓
Everyone finishes

RACE
↓
First result

ANY
↓
First success

15. Generators

Now another concept: Generators.

A generator is a special function that can pause and resume execution.

We declare one using:

function*

Example:

function* numbers() {

    yield 1;
    yield 2;
    yield 3;

}

Create the generator:

const generator = numbers();

Then:

console.log(generator.next());
console.log(generator.next());
console.log(generator.next());
console.log(generator.next());

Output:

{ value: 1, done: false }
{ value: 2, done: false }
{ value: 3, done: false }
{ value: undefined, done: true }

16. What does `yield` do?

yield pauses the generator.

function* numbers() {

    yield 1;

    yield 2;

    yield 3;
}

Flow:

next()
 ↓
yield 1
 ↓
pause

next()
 ↓
yield 2
 ↓
pause

next()
 ↓
yield 3
 ↓
pause

next()
 ↓
done

So:

yield produces a value and pauses execution.

17. Iterators

An iterator is an object that provides a next() method.

next() returns:

{
    value: ...,
    done: ...
}

For example:

const generator = numbers();

console.log(generator.next());

gives:

{
    value: 1,
    done: false
}

Generators automatically provide iterator behavior.

18. `for...of`

Instead of manually calling:

generator.next();

we can use:

function* numbers() {

    yield 10;
    yield 20;
    yield 30;

}

for (const number of numbers()) {

    console.log(number);

}

Output:

10
20
30

19. Async Iterators

An async iterator is useful when values become available asynchronously.

We create an async generator using:

async function*

Example:

async function* getData() {

    yield "User";

    await new Promise(resolve => {
        setTimeout(resolve, 1000);
    });

    yield "Profile";

    await new Promise(resolve => {
        setTimeout(resolve, 1000);
    });

    yield "Posts";
}

We consume it using:

async function main() {

    for await (const data of getData()) {

        console.log(data);

    }
}

main();

Output:

User
Profile
Posts

The values are produced asynchronously.

20. `for...of` vs `for await...of`

Normal iterator

for (const value of iterable) {
    console.log(value);
}

Used for synchronous values.

Async iterator

for await (const value of asyncIterable) {
    console.log(value);
}

Used when values may arrive asynchronously.

Remember:

for...of
    ↓
synchronous iteration

for await...of
    ↓
asynchronous iteration

21. Concurrency

Now connect everything to your implementation task.

Suppose you have 10 API calls:

API 1
API 2
API 3
...
API 10

If you run all 10 at once, you have:

10 concurrent operations

Sometimes you want a limit:

Maximum = 3

So only:

API 1
API 2
API 3

run initially.

When one finishes:

API 4

starts.

This is called concurrency limiting.

22. Simple concurrency example

async function runTask(id, time) {

    console.log(`Task ${id} started`);

    await new Promise(resolve => {
        setTimeout(resolve, time);
    });

    console.log(`Task ${id} finished`);
}

If we start everything directly:

runTask(1, 2000);
runTask(2, 1000);
runTask(3, 1500);
runTask(4, 1000);

all four can run concurrently.

A concurrency limiter controls that.

Limit = 2

Task 1 ───────────
Task 2 ─────

Task 3 starts after Task 2 finishes
Task 4 starts when another slot is free

This is exactly what your concurrency-limiter.js task is designed to implement.

23. Complete Week-05 Task 02 picture

Asynchronous JavaScript II
│
├── async/await
│   ├── async
│   └── await
│
├── Error Handling
│   └── try/catch
│
├── Promise Combinators
│   ├── Promise.all()
│   ├── Promise.allSettled()
│   ├── Promise.race()
│   └── Promise.any()
│
├── Fail Strategies
│   ├── all() → fail-fast
│   └── allSettled() → fail-soft
│
├── Generators
│   ├── function*
│   └── yield
│
├── Iterators
│   └── next()
│
├── Async Iterators
│   ├── async function*
│   └── for await...of
│
└── Concurrency
    └── limit simultaneous async tasks

⭐ Most important things to remember

If your mentor asks you quickly:

What is async/await?

"async/await is syntax built on Promises that makes asynchronous code easier to read. async makes a function return a Promise, and await gets the resolved value of a Promise."

What is Promise.all()?

"It waits for all Promises to fulfill and fails fast if one rejects."

What is Promise.allSettled()?

"It waits for all Promises to settle and gives the result of every Promise, whether fulfilled or rejected."

Difference between race() and any()?

"race() returns the first settled Promise, while any() returns the first fulfilled Promise."

What is a generator?

"A generator is a function that can pause with yield and resume with next()."

What is an async iterator?

"An async iterator produces values asynchronously and can be consumed using for await...of."

What is concurrency limiting?

"Concurrency limiting controls how many asynchronous operations can run at the same time, such as allowing only three API calls concurrently."

Custom Promise in JS

Sai Swaroop Bijinapalli — Mon, 10 Aug 2026 11:19:16 +0000

Implementing a Custom Promise from Scratch in JavaScript

Promises are one of the most important features of modern JavaScript. We normally use the built-in Promise object for asynchronous operations, but understanding how a Promise works internally gives us a much deeper understanding of asynchronous JavaScript.

In this project, I implemented a simplified custom Promise class from scratch based on the core ideas of the Promises/A+ specification.

The implementation supports:

Promise states
resolve()
reject()
.then()
.catch()
.finally()
Promise chaining
Error propagation
Thenable resolution
Asynchronous .then() execution
Multiple .then() handlers

I also created a test suite that compares the behavior of the custom Promise with JavaScript's native Promise.

1. Why Build a Promise From Scratch?

Usually, we simply write:

const promise = new Promise((resolve, reject) => {

    resolve("Success");

});

The JavaScript engine handles all the internal Promise behavior for us.

But implementing one ourselves helps us understand:

How Promise states are stored
How resolve() changes the state
How reject() works
How .then() callbacks are stored
How Promise chaining works
How errors propagate
Why .then() executes asynchronously
How returned Promises are adopted
How .catch() and .finally() are implemented

Instead of treating Promise as a black box, we can understand its internal mechanism.

2. Project Structure

I created a simple project:

custom-promise/
│
├── my-promise.js
└── test.js

The responsibilities are:

my-promise.js
    ↓
Promise implementation

test.js
    ↓
Compare custom Promise with native Promise

3. Promise States

The first thing the implementation needs is Promise state management.

A Promise has three states:

              Pending
             /       \
            /         \
      Fulfilled      Rejected

A Promise starts as:

this.state = "pending";

Then it can transition to:

pending → fulfilled

or:

pending → rejected

Once settled, the Promise cannot change its state again.

For example:

resolve("Success");
reject("Failed");

The first settlement wins.

4. Creating the Custom Promise Class

The basic structure is:

class MyPromise {

    constructor(executor) {

        this.state = "pending";
        this.value = undefined;
        this.reason = undefined;

    }

}

We store three important pieces of information:

this.state
this.value
this.reason

For example, after:

resolve("Hello");

the Promise contains:

state = fulfilled
value = "Hello"

After:

reject("Error");

it contains:

state = rejected
reason = "Error"

5. Implementing `resolve()` and `reject()`

The executor function receives:

(resolve, reject)

So we implement these functions ourselves.

const resolve = (value) => {
    fulfill(value);
};

const reject = (reason) => {
    rejectInternal(reason);
};

The fulfillment function:

const fulfill = (value) => {

    if (this.state !== "pending") {
        return;
    }

    this.state = "fulfilled";
    this.value = value;

};

The rejection function:

const rejectInternal = (reason) => {

    if (this.state !== "pending") {
        return;
    }

    this.state = "rejected";
    this.reason = reason;

};

The check:

if (this.state !== "pending") {
    return;
}

ensures that a Promise settles only once.

6. Storing `.then()` Callbacks

Consider:

const promise = new MyPromise((resolve) => {

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

});

promise.then(value => {
    console.log(value);
});

The Promise is initially pending.

The .then() callback needs to wait until the Promise is fulfilled.

Therefore, we store callbacks in arrays:

this.onFulfilledCallbacks = [];
this.onRejectedCallbacks = [];

When .then() is called while the Promise is pending:

Pending

onFulfilledCallbacks
        ↓
   [callback]

When resolve() is eventually called, the stored callback can be executed.

7. Making `.then()` Asynchronous

Native Promise callbacks don't execute immediately.

For example:

const promise = MyPromise.resolve("Hello");

console.log("A");

promise.then(() => {
    console.log("B");
});

console.log("C");

The expected output is:

A
C
B

Therefore, the implementation uses:

queueMicrotask(callback);

Instead of executing the callback immediately, it schedules it as a microtask.

This makes the custom Promise behave more like a native Promise.

8. Implementing `.then()`

The most important method is .then().

Its basic structure is:

then(onFulfilled, onRejected) {

    const child = new MyPromise((resolve, reject) => {

        // handle parent Promise

    });

    return child;
}

The important part is:

return child;

Why?

Because every .then() creates a new Promise.

For example:

promise
    .then(...)
    .then(...)
    .then(...);

Conceptually:

Promise A
    ↓
  .then()
    ↓
Promise B
    ↓
  .then()
    ↓
Promise C

This is what makes Promise chaining possible.

9. Handling Fulfilled Promises

When the parent Promise is fulfilled:

const handleFulfilled = () => {

    try {

        const result = onFulfilled(parent.value);

        resolve(result);

    } catch (error) {

        reject(error);

    }
};

The resolved value is passed to the callback:

onFulfilled(parent.value)

For example:

MyPromise.resolve(10)
    .then(value => {
        return value * 2;
    });

The callback receives:

value = 10

It returns:

The child Promise is then resolved with 20.

10. Handling Rejected Promises

If the parent Promise is rejected:

const handleRejected = () => {

    try {

        if (typeof onRejected !== "function") {

            reject(parent.reason);
            return;

        }

        const result = onRejected(parent.reason);

        resolve(result);

    } catch (error) {

        reject(error);

    }
};

This allows:

MyPromise.reject("Network error")
    .catch(error => {
        console.log(error);
    });

to handle the rejection.

11. Promise Chaining

Promise chaining depends on .then() returning a new Promise.

Consider:

MyPromise.resolve(10)

    .then(value => {

        return value * 2;

    })

    .then(value => {

        return value + 5;

    })

    .then(value => {

        console.log(value);

    });

The flow is:

The important rule is:

The value returned from one .then() becomes the input to the next .then().

Internally:

const result = onFulfilled(parent.value);

resolve(result);

The returned value resolves the child Promise.

12. Handling Returned Promises

Consider a more complicated example:

MyPromise.resolve(10)

    .then(value => {

        return new MyPromise(resolve => {

            setTimeout(() => {
                resolve(value * 2);
            }, 1000);

        });

    })

    .then(value => {

        console.log(value);

    });

The first .then() returns another Promise.

Therefore, our custom Promise must understand when a resolved value is itself a Promise or Promise-like object.

This is called Promise resolution or thenable assimilation.

13. Thenables

A thenable is an object containing a .then() method.

Example:

const thenable = {

    then(resolve) {
        resolve("Hello");
    }

};

Our Promise needs to recognize this:

if (
    value !== null &&
    (typeof value === "object" ||
     typeof value === "function")
) {

Then we check:

const then = value.then;

If it is a function, we call it and adopt its result.

This allows:

MyPromise.resolve(thenable)
    .then(value => {
        console.log(value);
    });

to produce:

Hello

14. Self-Resolution Protection

A Promise should not resolve with itself.

For example:

let promise;

promise = new MyPromise(resolve => {

    resolve(promise);

});

This would create a circular situation.

Therefore, the implementation checks:

if (value === this) {

    rejectInternal(
        new TypeError("Promise cannot resolve itself")
    );

    return;
}

This prevents infinite resolution.

15. Protecting Against Multiple Resolution

A thenable could theoretically call both callbacks:

const badThenable = {

    then(resolve, reject) {

        resolve("First");

        reject("Second");

        resolve("Third");

    }

};

A Promise must settle only once.

So we use:

let called = false;

Then:

if (called) {
    return;
}

called = true;

The result becomes:

First → accepted
Second → ignored
Third → ignored

This follows the Promise settlement rule.

16. Error Propagation

Errors inside .then() must reject the next Promise.

Example:

MyPromise.resolve(10)

    .then(() => {

        throw new Error("Something went wrong");

    })

    .then(() => {

        console.log("This will not execute");

    })

    .catch(error => {

        console.log(error.message);

    });

Output:

Something went wrong

Internally, .then() uses try...catch:

try {

    const result = onFulfilled(parent.value);

    resolve(result);

} catch (error) {

    reject(error);

}

So the flow becomes:

throw Error
     ↓
catch(error)
     ↓
reject(error)
     ↓
next .then() skipped
     ↓
.catch()

This is called error propagation.

17. Implementing `.catch()`

.catch() can be implemented using .then():

catch(onRejected) {

    return this.then(undefined, onRejected);

}

This works because .then() already accepts two callbacks:

then(onFulfilled, onRejected)

Therefore:

promise.catch(handler);

is essentially:

promise.then(undefined, handler);

18. Implementing `.finally()`

.finally() should run regardless of whether the Promise succeeds or fails.

The implementation:

finally(onFinally) {

    return this.then(

        (value) => {

            return MyPromise.resolve(onFinally())
                .then(() => value);

        },

        (reason) => {

            return MyPromise.resolve(onFinally())
                .then(() => {
                    throw reason;
                });

        }

    );
}

The important behavior is:

Success
   ↓
finally()
   ↓
original value continues


Failure
   ↓
finally()
   ↓
original error continues

For example:

MyPromise.resolve("Success")
    .finally(() => {
        console.log("Cleanup");
    })
    .then(value => {
        console.log(value);
    });

Output:

Cleanup
Success

19. Static `resolve()` and `reject()`

To make the custom class easier to use, I also implemented:

MyPromise.resolve()
MyPromise.reject()

`resolve()`

static resolve(value) {

    if (value instanceof MyPromise) {
        return value;
    }

    return new MyPromise((resolve) => {
        resolve(value);
    });
}

Usage:

MyPromise.resolve("Hello");

`reject()`

static reject(reason) {

    return new MyPromise((resolve, reject) => {
        reject(reason);
    });
}

Usage:

MyPromise.reject("Failed");

20. Testing Against Native Promise

Implementing a custom Promise isn't enough. We need to verify its behavior.

I created a test suite that executes the same scenarios using:

MyPromise

and:

Promise

Then their results are compared.

For example:

MyPromise.resolve(10)
    .then(value => value * 2);

is compared with:

Promise.resolve(10)
    .then(value => value * 2);

Both should produce:

21. Basic Resolve Test

compare(
    "Basic resolve",

    MyPromise.resolve("Hello"),

    Promise.resolve("Hello")
);

Expected:

✅ Basic resolve

22. Rejection Test

compare(
    "Basic rejection",

    MyPromise.reject("Error")
        .catch(error => error),

    Promise.reject("Error")
        .catch(error => error)
);

Both should produce:

Error

23. Chaining Test

compare(
    "then chaining",

    MyPromise.resolve(10)
        .then(value => value * 2)
        .then(value => value + 5),

    Promise.resolve(10)
        .then(value => value * 2)
        .then(value => value + 5)
);

Expected:

24. Error Propagation Test

compare(
    "Error propagation",

    MyPromise.resolve(10)
        .then(() => {
            throw new Error("Boom");
        })
        .catch(error => error.message),

    Promise.resolve(10)
        .then(() => {
            throw new Error("Boom");
        })
        .catch(error => error.message)
);

Both should produce:

Boom

25. Thenable Test

compare(
    "Thenable resolution",

    MyPromise.resolve({
        then(resolve) {
            resolve("Thenable");
        }
    }),

    Promise.resolve({
        then(resolve) {
            resolve("Thenable");
        }
    })
);

Expected:

Thenable

26. Async Behavior Test

Native Promise .then() callbacks execute asynchronously.

Therefore, the custom implementation should behave the same way.

const order = [];

MyPromise.resolve("Done")
    .then(() => {
        order.push("then");
    });

order.push("sync");

The expected order is:

sync
then

not:

then
sync

This verifies that queueMicrotask() is being used correctly.

27. Final Test Results

After running:

node test.js

the test suite should report results similar to:

✅ Basic resolve
✅ Basic rejection
✅ then chaining
✅ Error propagation
✅ finally
✅ Returned Promise
✅ Thenable resolution

This shows that the custom implementation behaves similarly to native Promises for the scenarios covered by the test suite.

28. What I Learned From This Implementation

Implementing a Promise from scratch helped me understand that a Promise is more than just an object containing a value.

The implementation needs to manage:

Promise State
     ↓
Callbacks
     ↓
Resolution
     ↓
Chaining
     ↓
Error Propagation
     ↓
Asynchronous Execution

The most important concepts I learned were:

Promise state management

pending → fulfilled
pending → rejected

Resolution

resolve(value)

doesn't simply assign a value. It may need to handle another Promise or thenable.

Chaining

.then()
   ↓
new Promise
   ↓
.then()

Error propagation

throw
 ↓
reject
 ↓
.catch()

Asynchronous execution

.then()
 ↓
Microtask Queue
 ↓
Callback execution

Conclusion

Building a custom Promise from scratch is a useful exercise for understanding asynchronous JavaScript at a deeper level.

The final implementation supports the core Promise behavior required for this project:

              MyPromise
                  |
        ┌─────────┼─────────┐
        ↓         ↓         ↓
     Pending   Fulfilled  Rejected
        |         |          |
        |       .then()    .catch()
        |         |
        |      chaining
        |         |
        └─────────┼─────────┘
                  ↓
              .finally()

The biggest takeaway is that Promise chaining works because each .then() creates and returns a new Promise, while the resolution procedure determines whether that new Promise should fulfill with a normal value or adopt the state of another Promise/thenable.

Comparing the implementation with native Promise also provides a practical way to verify whether the custom implementation behaves correctly.

This project transformed Promises from something I simply used into something I could understand and implement at a fundamental level.

About Promises in JS

Sai Swaroop Bijinapalli — Mon, 10 Aug 2026 10:38:55 +0000

Perfect. Here is a ready-to-publish beginner-friendly blog that starts from Promises and gradually covers all the concepts you studied.

Asynchronous JavaScript: Understanding Promises, Chaining, Error Handling, and Separation of Concerns

JavaScript is often described as a single-threaded programming language. This means JavaScript executes one piece of code at a time. But modern applications constantly perform operations that take time, such as API requests, database operations, file handling, and timers.

If JavaScript waited for every operation to finish before continuing, applications would become slow and unresponsive.

This is where asynchronous JavaScript comes into the picture.

One of the most important tools for handling asynchronous operations is the Promise.

In this blog, we will understand Promises from the basics and gradually explore:

What a Promise is
resolve() and reject()
Promise states
.then()
.catch()
.finally()
Promise chaining
Error propagation
Callback Hell
Separation of concerns
Async orchestration vs business logic

1. What Is a Promise?

A Promise is an object that represents the eventual result of an asynchronous operation.

The result may be:

Successful
Failed
Still in progress

For example, imagine ordering food online.

Initially:

Order placed
     ↓
   Waiting

Eventually, one of two things happens:

Order placed
     ↓
   Waiting
    /    \
   /      \
Delivered  Cancelled

A Promise works similarly.

              Promise
                 |
              Pending
             /       \
            /         \
     Fulfilled       Rejected

A Promise doesn't immediately give you the final result. Instead, it gives you a way to handle the result when it becomes available.

2. Creating a Promise

A Promise is created using the Promise constructor.

const promise = new Promise((resolve, reject) => {

    // asynchronous operation

});

The Promise constructor receives a function with two parameters:

(resolve, reject) => {

}

These two functions are provided by JavaScript.

resolve() → tells the Promise that the operation succeeded.
reject() → tells the Promise that the operation failed.

3. Why Do We Use `resolve()`?

resolve() is used when an asynchronous operation completes successfully.

const promise = new Promise((resolve, reject) => {

    resolve("Operation successful");

});

When resolve() is called:

Pending
   ↓
Fulfilled

The value passed to resolve() becomes the result of the Promise.

Here:

resolve("Operation successful");

means:

"The operation was successful, and this is the result."

4. Why Do We Use `reject()`?

reject() is used when the asynchronous operation fails.

const promise = new Promise((resolve, reject) => {

    reject("Operation failed");

});

The Promise changes from:

Pending
   ↓
Rejected

The value passed to reject() represents the reason for the failure.

5. Promise States

A Promise has three states.

Pending

The operation is still in progress.

const promise = new Promise((resolve, reject) => {

    // still running

});

State:

Pending

Fulfilled

The operation completed successfully.

const promise = new Promise((resolve, reject) => {

    resolve("Success");

});

State transition:

Pending → Fulfilled

Rejected

The operation failed.

const promise = new Promise((resolve, reject) => {

    reject("Failed");

});

State transition:

Pending → Rejected

A Promise can settle only once.

For example:

const promise = new Promise((resolve, reject) => {

    resolve("Success");
    reject("Failed");

});

The first settlement wins.

The Promise becomes fulfilled with:

Success

The later reject() has no effect.

6. Using `.then()`

Once a Promise is fulfilled, we can use .then() to handle the successful result.

const promise = new Promise((resolve, reject) => {

    resolve("Login successful");

});

promise.then((result) => {

    console.log(result);

});

Output:

Login successful

The important connection is:

resolve("Login successful");

passes the value to:

.then((result) => {
    console.log(result);
});

So:

resolve("Login successful")
              ↓
       result = "Login successful"
              ↓
            .then()

7. Promise with `setTimeout()`

Let's make the operation asynchronous.

const promise = new Promise((resolve, reject) => {

    setTimeout(() => {

        resolve("Data received");

    }, 2000);

});

promise.then((data) => {

    console.log(data);

});

What happens?

Step 1

The Promise starts in the pending state.

Pending

Step 2

setTimeout() starts a two-second timer.

The Promise is still pending.

Step 3

.then() waits for the Promise to become fulfilled.

Step 4

After two seconds:

resolve("Data received");

runs.

The state changes:

Pending → Fulfilled

Step 5

The .then() callback executes.

Output:

Data received

This is why we often see resolve() inside a setTimeout() when learning Promises.

setTimeout() provides the delay, while resolve() tells the Promise:

"The asynchronous operation has now completed successfully."

8. Using `.catch()`

.catch() is used to handle a rejected Promise.

const promise = new Promise((resolve, reject) => {

    reject("Login failed");

});

promise.catch((error) => {

    console.log(error);

});

Output:

Login failed

The flow is:

reject()
   ↓
Rejected
   ↓
.catch()

A common pattern is:

promise
    .then((result) => {
        console.log(result);
    })
    .catch((error) => {
        console.log(error);
    });

Here:

.then() handles success.
.catch() handles failure.

9. Using `.finally()`

Sometimes we need some code to run regardless of whether the Promise succeeds or fails.

That's where .finally() is useful.

Promise.resolve("Success")

    .then((result) => {

        console.log(result);

    })

    .finally(() => {

        console.log("Operation finished");

    });

Output:

Success
Operation finished

If the Promise is rejected:

Promise.reject("Failed")

    .catch((error) => {

        console.log(error);

    })

    .finally(() => {

        console.log("Operation finished");

    });

Output:

Failed
Operation finished

A common use case is a loading indicator:

showLoading();

fetchData()

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

    .catch((error) => {
        console.log(error);
    })

    .finally(() => {
        hideLoading();
    });

Whether the request succeeds or fails, the loading indicator should disappear.

10. Promise Chaining

One of the biggest advantages of Promises is chaining.

Suppose we need to perform these operations:

Get User
   ↓
Get Profile
   ↓
Get Posts
   ↓
Display Posts

With Promises:

getUser()

    .then((user) => {

        return getProfile(user.id);

    })

    .then((profile) => {

        return getPosts(profile.id);

    })

    .then((posts) => {

        console.log(posts);

    })

    .catch((error) => {

        console.log(error);

    });

This is called Promise chaining.

11. How Does Promise Chaining Work?

Consider this example:

Promise.resolve(10)

    .then((value) => {

        console.log(value);

        return value * 2;

    })

    .then((value) => {

        console.log(value);

        return value + 5;

    })

    .then((value) => {

        console.log(value);

    });

Output:

10
20
25

Why?

The first Promise contains:

The first .then() receives:

value = 10

It returns:

return value * 2;

which produces:

The next .then() receives 20.

It returns:

The final .then() receives 25.

Therefore:

The important rule is:

The value returned from one .then() becomes the value received by the next .then().

12. Callback Hell

Before Promises became widely used, asynchronous operations were commonly handled using callbacks.

Suppose we need:

Login
 ↓
Get User
 ↓
Get Posts
 ↓
Get Comments

Using callbacks:

loginUser(function(user) {

    getUser(user.id, function(userData) {

        getPosts(userData.id, function(posts) {

            getComments(posts[0].id, function(comments) {

                console.log(comments);

            });

        });

    });

});

Notice how the functions become deeply nested.

This is commonly called Callback Hell.

The structure starts looking like:

loginUser
   └── getUser
        └── getPosts
             └── getComments

As the application grows, this can become difficult to:

Read
Debug
Maintain
Handle errors in

Promises provide a flatter structure:

loginUser()

    .then(getUser)
    .then(getPosts)
    .then(getComments)

    .then((comments) => {
        console.log(comments);
    })

    .catch((error) => {
        console.log(error);
    });

13. Error Propagation

Another important Promise feature is error propagation.

Consider:

Promise.resolve(10)

    .then((value) => {

        console.log(value);

        throw new Error("Something went wrong");

    })

    .then(() => {

        console.log("This will not execute");

    })

    .catch((error) => {

        console.log(error.message);

    });

Output:

10
Something went wrong

What happened?

The first .then() executed:

console.log(value);

So we get:

Then an error was thrown:

throw new Error("Something went wrong");

The Promise chain now becomes rejected.

The next .then() is skipped:

.then(() => {
    console.log("This will not execute");
})

The error moves to .catch():

.catch((error) => {
    console.log(error.message);
});

So the flow is:

.then()
   ↓
Error occurs
   ↓
Promise becomes rejected
   ↓
Skip remaining .then()
   ↓
.catch()

This movement of an error through the Promise chain is called error propagation.

14. Errors Can Happen Anywhere in the Chain

Promise.resolve("Start")

    .then((value) => {

        console.log(value);

        return "Step 1";

    })

    .then((value) => {

        console.log(value);

        throw new Error("Step 2 failed");

    })

    .then((value) => {

        console.log("Step 3");

    })

    .catch((error) => {

        console.log("Error:", error.message);

    });

Output:

Start
Step 1
Error: Step 2 failed

Step 3 isn't executed because the previous .then() produced an error.

The error automatically propagates to .catch().

15. Separation of Concerns

As applications become larger, another important concept becomes necessary:

Separation of Concerns.

The basic idea is:

Each function should have a clear responsibility.

When working with asynchronous JavaScript, it is useful to separate:

Async orchestration
Business logic

16. What Is Async Orchestration?

Async orchestration is about controlling when and in what order asynchronous operations happen.

For example:

Get User
   ↓
Get Orders
   ↓
Calculate Total
   ↓
Return Result

The orchestration controls this sequence.

Example:

async function getUserTotal() {

    const user = await getUser();

    const orders = await getOrders(user.id);

    const total = calculateTotal(orders);

    return total;
}

Here:

const user = await getUser();

and:

const orders = await getOrders(user.id);

are part of async orchestration.

They determine the order of asynchronous operations.

17. What Is Business Logic?

Business logic contains the actual rules of the application.

For example:

function calculateTotal(orders) {

    let total = 0;

    for (const order of orders) {

        if (order.status === "completed") {
            total += order.price;
        }

    }

    if (total > 10000) {
        total = total * 0.9;
    }

    return total;
}

This function doesn't care about:

Promises
APIs
fetch()
setTimeout()
async/await

It only knows:

"Given a list of orders, calculate the total according to the application's rules."

That's business logic.

18. Separating Async Orchestration and Business Logic

Instead of mixing everything:

function getUserTotal() {

    return fetch("/user")
        .then(response => response.json())
        .then(user => {

            return fetch("/orders/" + user.id);

        })
        .then(response => response.json())
        .then(orders => {

            let total = 0;

            for (const order of orders) {

                if (order.status === "completed") {
                    total += order.price;
                }

            }

            return total;

        });
}

We can separate the responsibilities.

Data retrieval

function getUser() {

    return fetch("/user")
        .then(response => response.json());

}

Data retrieval

function getOrders(userId) {

    return fetch("/orders/" + userId)
        .then(response => response.json());

}

Business logic

function calculateTotal(orders) {

    let total = 0;

    for (const order of orders) {

        if (order.status === "completed") {
            total += order.price;
        }

    }

    if (total > 10000) {
        total *= 0.9;
    }

    return total;
}

Async orchestration

async function getUserTotal() {

    const user = await getUser();

    const orders = await getOrders(user.id);

    return calculateTotal(orders);

}

Now each function has a clear responsibility.

19. Why Is This Separation Useful?

Easier Testing

We can test the business logic independently.

const orders = [
    { status: "completed", price: 5000 },
    { status: "completed", price: 7000 },
    { status: "cancelled", price: 3000 }
];

console.log(calculateTotal(orders));

No API request is required.

Easier Maintenance

Suppose the discount changes from 10% to 20%.

You only modify:

if (total > 10000) {
    total *= 0.8;
}

The API/orchestration code doesn't need to change.

Better Reusability

The calculateTotal() function can be used by:

Customer website
Admin dashboard
Reports
Mobile application

because it doesn't depend on a particular API or UI.

20. Async Orchestration vs Business Logic

A simple way to remember the difference is:

Async Orchestration asks:

When should this operation happen?

Example:

const user = await getUser();
const orders = await getOrders(user.id);
const total = calculateTotal(orders);

It controls the sequence.

Business Logic asks:

What should we do with the data?

Example:

function calculateTotal(orders) {

    // application rules

}

It contains the rules.

21. Complete Flow

Putting everything together:

                USER REQUEST
                     |
                     ↓
            Async Orchestration
                     |
                     ↓
                getUser()
                     |
                     ↓
              getOrders()
                     |
                     ↓
              Business Logic
                     |
                     ↓
            calculateTotal()
                     |
                     ↓
                  Result

The responsibilities are separated.

22. Promises: The Complete Picture

All the concepts we discussed are connected:

                       Promise
                          |
                       Pending
                      /       \
                     /         \
              resolve()       reject()
                  ↓               ↓
             Fulfilled         Rejected
                  |               |
                  ↓               ↓
               .then()         .catch()
                  |
            return value
                  |
                  ↓
             next .then()
                  |
               error
                  |
                  ↓
               .catch()
                  |
                  ↓
             .finally()

And Promise chaining helps avoid deeply nested Callback Hell.

23. Quick Summary

Concept	Meaning
Promise	Represents the future result of an asynchronous operation
Pending	Operation is still in progress
Fulfilled	Operation completed successfully
Rejected	Operation failed
`resolve()`	Marks the Promise as fulfilled
`reject()`	Marks the Promise as rejected
`.then()`	Handles successful results
`.catch()`	Handles errors/rejections
`.finally()`	Runs regardless of success or failure
Promise chaining	Passes results from one `.then()` to the next
Error propagation	Errors move through the chain until handled by `.catch()`
Callback Hell	Deeply nested asynchronous callbacks
Async orchestration	Controls the order of asynchronous operations
Business logic	Contains the actual rules of the application

Conclusion

Promises provide a structured way to work with asynchronous operations in JavaScript.

Instead of deeply nested callbacks, we can use Promise chains:

getUser()
    .then(getOrders)
    .then(calculateTotal)
    .catch(handleError)
    .finally(cleanup);

The most important concepts to remember are:

resolve()  → Success → Fulfilled → .then()

reject()   → Failure → Rejected → .catch()

return     → Next .then()

throw      → Error → .catch()

finally    → Runs regardless of outcome

And as applications grow, Separation of Concerns becomes equally important:

Async orchestration → controls the sequence

Business logic → contains the application rules

JS Functional Programming Concepts

Sai Swaroop Bijinapalli — Tue, 04 Aug 2026 05:01:53 +0000

For your Week-04 Task-2, your mentor expects you to understand the Functional Programming concepts first and then implement the utility library (curry(), compose(), pipe(), deepFreeze()). Below are the concepts with clear definitions and examples.

Week-04 Task-2: Functional Programming Concepts

1. Functional Programming (FP)

Definition

Functional Programming is a programming paradigm where programs are built using functions. It focuses on pure functions, immutable data, avoiding side effects, and using functions as values.

Example

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

console.log(add(10, 20)); // 30

Here, the program is built around functions.

2. Pure Function

Definition

A pure function always returns the same output for the same input and does not modify external data or produce side effects.

Example

function multiply(a, b) {
    return a * b;
}

console.log(multiply(2, 5)); // 10
console.log(multiply(2, 5)); // 10

The output is always the same.

Not a Pure Function

let count = 0;

function increment() {
    count++;
    return count;
}

Output:

1
2
3

The output changes because it depends on external state.

3. Immutability

Definition

Immutability means data should not be modified after it is created. Instead of changing existing data, create a new copy with the changes.

Mutable Example

let user = {
    name: "Sai"
};

user.name = "Rahul";

console.log(user);

Output

{ name: "Rahul" }

The original object was changed.

Immutable Example

let user = {
    name: "Sai"
};

let updatedUser = {
    ...user,
    name: "Rahul"
};

console.log(user);
console.log(updatedUser);

Output

{ name: "Sai" }

{ name: "Rahul" }

The original object is unchanged.

4. Higher-Order Function (HOF)

Definition

A Higher-Order Function is a function that takes another function as an argument or returns another function.

Example

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

function process(fn, value) {
    console.log(fn(value));
}

process(greet, "Sai");

Output

Hello Sai

process() receives another function (greet) as an argument.

Built-in Higher-Order Functions

map()
filter()
reduce()
forEach()

5. map()

Definition

map() creates a new array by applying a function to every element of the original array.

Example

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

const squares = numbers.map(num => num * num);

console.log(squares);

Output

[1, 4, 9, 16]

The original array is not changed.

6. filter()

Definition

filter() creates a new array containing only the elements that satisfy a condition.

Example

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

const even = numbers.filter(num => num % 2 === 0);

console.log(even);

Output

[2, 4, 6]

7. reduce()

Definition

reduce() reduces an array into a single value by repeatedly combining elements.

Example

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

const sum = numbers.reduce((acc, curr) => acc + curr, 0);

console.log(sum);

Output

Explanation:

8. Currying

Definition

Currying is the process of converting a function that takes multiple arguments into a sequence of functions that each take one argument.

Normal Function

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

console.log(add(10, 20, 30));

Output

Curried Function

function add(a) {
    return function (b) {
        return function (c) {
            return a + b + c;
        };
    };
}

console.log(add(10)(20)(30));

Output

9. Composition

Definition

Function composition combines multiple functions into a single function, where the output of one function becomes the input of the next.

Example

function double(x) {
    return x * 2;
}

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

console.log(square(double(5)));

Output

10. compose()

Definition

compose() executes functions from right to left.

Example

const compose = (f, g) => x => f(g(x));

const double = x => x * 2;
const square = x => x * x;

console.log(compose(square, double)(5));

Execution

double(5)

↓

10

↓

square(10)

↓

100

11. pipe()

Definition

pipe() executes functions from left to right.

Example

const pipe = (f, g) => x => g(f(x));

const double = x => x * 2;
const square = x => x * x;

console.log(pipe(double, square)(5));

Execution

double(5)

↓

10

↓

square(10)

↓

100

Difference Between compose() and pipe()

compose()	pipe()
Right → Left	Left → Right
`compose(square, double)(5)`	`pipe(double, square)(5)`
`square(double(5))`	`square(double(5))`

Both produce the same result if the functions are arranged appropriately, but the direction of execution is different.

12. Referential Transparency

Definition

An expression is referentially transparent if it can be replaced by its value without changing the program's behavior.

Example

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

console.log(add(2, 3));

You can replace:

add(2, 3)

with:

and the program behaves the same.

13. Side Effects

Definition

A side effect is any operation that changes something outside the function, such as modifying a variable, updating the DOM, making an API call, writing to a file, or printing to the console.

Example

let total = 0;

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

The function changes external state (total), so it has a side effect.

14. Side-Effect Isolation

Definition

Side-effect isolation means keeping impure operations separate from pure business logic.

Example

function calculateTotal(price, tax) {
    return price + tax;
}

const total = calculateTotal(100, 18);
console.log(total);

calculateTotal() is pure.
console.log() is the side effect.

Keeping them separate makes the code easier to test and maintain.

15. deepFreeze()

Definition

deepFreeze() recursively freezes an object and all of its nested objects, making them immutable.

Example

const user = {
    name: "Sai",
    address: {
        city: "Bangalore"
    }
};

deepFreeze(user);

// These changes will fail (or throw in strict mode)
user.name = "Rahul";
user.address.city = "Hyderabad";

The object remains unchanged.

Summary

Concept	One-Line Definition
Functional Programming	Programming using functions, pure logic, and immutable data.
Pure Function	Same input → Same output, no side effects.
Immutability	Never modify existing data; create new data instead.
Higher-Order Function	Takes or returns another function.
`map()`	Transforms every element into a new array.
`filter()`	Returns only elements matching a condition.
`reduce()`	Combines an array into a single value.
Currying	Converts a multi-argument function into a chain of single-argument functions.
Composition	Combines multiple functions together.
`compose()`	Executes functions from right to left.
`pipe()`	Executes functions from left to right.
Referential Transparency	Replace an expression with its value without changing behavior.
Side Effect	Any change outside the function.
Side-Effect Isolation	Keep pure logic separate from side effects.
`deepFreeze()`	Recursively freezes an object to make it immutable.

About Prototype-Chain

Sai Swaroop Bijinapalli — Thu, 30 Jul 2026 10:18:42 +0000

Object-Oriented JavaScript (OOP): A Complete Guide with Examples

Introduction

Object-Oriented Programming (OOP) is one of the most popular programming paradigms used to organize code into objects. An object contains data (properties) and behavior (methods).

JavaScript is a prototype-based object-oriented language. Unlike Java or C++, which use class-based inheritance, JavaScript uses prototypes to inherit properties and methods. However, since ES6, JavaScript introduced the class syntax, making OOP easier to read and write.

Learning OOP in JavaScript helps you write code that is:

Reusable
Modular
Easy to maintain
Easy to extend
Easier to understand in large applications

What is Object-Oriented Programming (OOP)?

Object-Oriented Programming is a programming style where we represent real-world entities as objects.

An object contains:

Properties (State) → Information about the object
Methods (Behavior) → Actions the object can perform

For example, consider a Car.

Car

Properties
-----------
Brand
Color
Speed

Methods
-----------
Start()
Stop()
Accelerate()
Brake()

In JavaScript, we can represent it like this:

```javascript id="lmn421"
const car = {
brand: "Tesla",
color: "Black",
speed: 0,

start() {
    console.log("Car Started");
},

accelerate() {
    this.speed += 20;
    console.log(this.speed);
}

};

car.start();
car.accelerate();




Output



```id="n2sk7h"
Car Started
20

Here:

brand, color, and speed are properties.
start() and accelerate() are methods.

Why Do We Need OOP?

Imagine creating 100 students.

Without OOP:

```javascript id="5t0nqk"
const student1 = {
name: "Sai",
age: 20
};

const student2 = {
name: "Ram",
age: 21
};

const student3 = {
name: "John",
age: 22
};




You would repeat the same structure many times.

Instead, OOP allows you to create a blueprint.

---

# Constructor Function

Before ES6 classes, JavaScript used constructor functions.



```javascript id="z73mbe"
function Student(name, age) {
    this.name = name;
    this.age = age;
}

const s1 = new Student("Sai", 20);
const s2 = new Student("Ram", 21);

console.log(s1);
console.log(s2);

Output

Student { name: "Sai", age: 20 }

Student { name: "Ram", age: 21 }

The constructor acts as a blueprint for creating multiple objects.

ES6 Classes

JavaScript introduced classes in ES6.

```javascript id="9k2m8c"
class Student {

constructor(name, age) {
    this.name = name;
    this.age = age;
}

study() {
    console.log(this.name + " is studying");
}

}

const s1 = new Student("Sai", 20);

s1.study();




Output



```id="gl6x5y"
Sai is studying

Although this looks like Java or C++, classes internally use JavaScript's prototype system.

Four Pillars of OOP

Object-Oriented Programming is based on four major principles:

Object-Oriented Programming

        │

 ┌──────┼────────┐
 │      │        │
 ▼      ▼        ▼
Encapsulation
Inheritance
Polymorphism
Abstraction

Let's understand each one.

1. Encapsulation

What is Encapsulation?

Encapsulation means keeping data and the methods that operate on that data together inside one object, while also controlling access to that data.

Think of a bank account.

Bank Account

Balance

Deposit()

Withdraw()

GetBalance()

Users should not directly change the balance.

Instead, they should use methods like deposit() or withdraw().

Example Using Private Fields

```javascript id="9wv9d8"
class BankAccount {

#balance = 0;

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

withdraw(amount) {
    this.#balance -= amount;
}

getBalance() {
    return this.#balance;
}

}

const account = new BankAccount();

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

console.log(account.getBalance());




Output



```id="z3pygk"
800

Trying this:

```javascript id="dn3x1x"
console.log(account.#balance);




Results in an error because `#balance` is private.

Benefits:

* Protects data
* Prevents accidental modification
* Improves security

---

# 2. Inheritance

## What is Inheritance?

Inheritance allows one class to acquire the properties and methods of another class.

Real-life example:



```id="elz6vy"
Animal

eat()

sleep()

      ▲

      │

Dog

bark()

The Dog class automatically gets the methods of Animal.

Example

```javascript id="l5v0qo"
class Animal {

eat() {
    console.log("Eating");
}

}

class Dog extends Animal {

bark() {
    console.log("Barking");
}

}

const dog = new Dog();

dog.eat();
dog.bark();




Output



```id="v7h7ew"
Eating

Barking

Inheritance avoids code duplication.

Using super()

The super keyword calls the parent class constructor.

```javascript id="klyp92"
class Animal {

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

}

class Dog extends Animal {

constructor(name, breed) {
    super(name);
    this.breed = breed;
}

}

const dog = new Dog("Tom", "Labrador");

console.log(dog);




Output



```id="tht91x"
Dog {

name: "Tom",

breed: "Labrador"

}

3. Polymorphism

What is Polymorphism?

Polymorphism means one interface, many forms.

Different objects can implement the same method differently.

Example

```javascript id="e8iqcx"
class Animal {

speak() {
    console.log("Animal Sound");
}

}

class Dog extends Animal {

speak() {
    console.log("Bark");
}

}

class Cat extends Animal {

speak() {
    console.log("Meow");
}

}

const dog = new Dog();
const cat = new Cat();

dog.speak();
cat.speak();




Output



```id="t9hvo8"
Bark

Meow

Both classes have a speak() method, but each behaves differently.

This is method overriding, one of the most common forms of polymorphism.

4. Abstraction

What is Abstraction?

Abstraction means showing only essential features while hiding internal implementation details.

Example:

When driving a car, you use the steering wheel, accelerator, and brake. You don't need to know how the engine or transmission works internally.

Example

```javascript id="b9u74f"
class CoffeeMachine {

makeCoffee() {
    this.#boilWater();
    console.log("Coffee Ready");
}

#boilWater() {
    console.log("Boiling Water...");
}

}

const machine = new CoffeeMachine();

machine.makeCoffee();




Output



```id="yb3poh"
Boiling Water...

Coffee Ready

Users only call makeCoffee(). The internal boiling process is hidden.

Prototype-Based OOP

Even though JavaScript has classes, everything is still based on prototypes.

```javascript id="fxz6eh"
class Person {

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

greet() {
    console.log("Hello");
}

}




Internally, JavaScript creates:



```javascript id="sx6uyj"
function Person(name) {
    this.name = name;
}

Person.prototype.greet = function () {
    console.log("Hello");
};

This is why JavaScript is called a prototype-based language.

Object Relationships

Student Object

name

age

study()

        │

        ▼

Student.prototype

study()

        │

        ▼

Object.prototype

toString()

hasOwnProperty()

valueOf()

        │

        ▼

null

Class Example

```javascript id="z93vrl"
class Employee {

constructor(name, salary) {
    this.name = name;
    this.salary = salary;
}

display() {
    console.log(this.name, this.salary);
}

}

const emp1 = new Employee("Sai", 50000);
const emp2 = new Employee("Ram", 70000);

emp1.display();
emp2.display();




Output



```id="qg64t9"
Sai 50000

Ram 70000

Advantages of OOP

Promotes code reusability through inheritance.
Improves maintainability by organizing related data and behavior.
Enhances security with encapsulation.
Simplifies large projects by dividing functionality into objects.
Makes applications easier to extend and scale.

OOP vs Procedural Programming

Procedural Programming	Object-Oriented Programming
Focuses on functions	Focuses on objects
Data and functions are separate	Data and methods are grouped together
Less reusable	Highly reusable
Difficult to maintain in large projects	Easier to maintain and scale
No inheritance	Supports inheritance

Interview Questions

What is OOP?

Object-Oriented Programming is a programming paradigm that organizes code into objects containing properties and methods.

What are the four pillars of OOP?

Encapsulation
Inheritance
Polymorphism
Abstraction

Is JavaScript object-oriented?

Yes. JavaScript is an object-oriented language that uses prototype-based inheritance. ES6 introduced class syntax, but it still works on top of prototypes.

What is the difference between a class and an object?

A class is a blueprint for creating objects.

An object is an instance of a class.

What is inheritance?

Inheritance allows one class to acquire the properties and methods of another class, reducing code duplication.

What is encapsulation?

Encapsulation groups data and methods together while controlling access to internal data, often using private fields.

What is polymorphism?

Polymorphism allows the same method name to have different implementations in different classes.

What is abstraction?

Abstraction hides internal implementation details and exposes only the necessary functionality.

Conclusion

Object-Oriented Programming is a powerful approach for building scalable and maintainable applications. JavaScript supports OOP through its prototype system and provides a cleaner class syntax to make development easier.

Understanding objects, classes, prototypes, and the four OOP pillars—Encapsulation, Inheritance, Polymorphism, and Abstraction—will help you write cleaner code, build reusable components, and confidently tackle real-world JavaScript projects. While the syntax may resemble other object-oriented languages, remember that JavaScript's true foundation is prototype-based inheritance, making it both flexible and unique.

4 Pillars in JS

Sai Swaroop Bijinapalli — Thu, 30 Jul 2026 09:53:31 +0000

Object-Oriented JavaScript (OOP): A Complete Guide with Examples

Introduction

Object-Oriented Programming (OOP) is one of the most popular programming paradigms used to organize code into objects. An object contains data (properties) and behavior (methods).

Learning OOP in JavaScript helps you write code that is:

Reusable
Modular
Easy to maintain
Easy to extend
Easier to understand in large applications

What is Object-Oriented Programming (OOP)?

Object-Oriented Programming is a programming style where we represent real-world entities as objects.

An object contains:

Properties (State) → Information about the object
Methods (Behavior) → Actions the object can perform

For example, consider a Car.

Car

Properties
-----------
Brand
Color
Speed

Methods
-----------
Start()
Stop()
Accelerate()
Brake()

In JavaScript, we can represent it like this:

```javascript id="lmn421"
const car = {
brand: "Tesla",
color: "Black",
speed: 0,

start() {
    console.log("Car Started");
},

accelerate() {
    this.speed += 20;
    console.log(this.speed);
}

};

car.start();
car.accelerate();




Output



```id="n2sk7h"
Car Started
20

Here:

brand, color, and speed are properties.
start() and accelerate() are methods.

Why Do We Need OOP?

Imagine creating 100 students.

Without OOP:

```javascript id="5t0nqk"
const student1 = {
name: "Sai",
age: 20
};

const student2 = {
name: "Ram",
age: 21
};

const student3 = {
name: "John",
age: 22
};




You would repeat the same structure many times.

Instead, OOP allows you to create a blueprint.

---

# Constructor Function

Before ES6 classes, JavaScript used constructor functions.



```javascript id="z73mbe"
function Student(name, age) {
    this.name = name;
    this.age = age;
}

const s1 = new Student("Sai", 20);
const s2 = new Student("Ram", 21);

console.log(s1);
console.log(s2);

Output

Student { name: "Sai", age: 20 }

Student { name: "Ram", age: 21 }

The constructor acts as a blueprint for creating multiple objects.

ES6 Classes

JavaScript introduced classes in ES6.

```javascript id="9k2m8c"
class Student {

constructor(name, age) {
    this.name = name;
    this.age = age;
}

study() {
    console.log(this.name + " is studying");
}

}

const s1 = new Student("Sai", 20);

s1.study();




Output



```id="gl6x5y"
Sai is studying

Although this looks like Java or C++, classes internally use JavaScript's prototype system.

Four Pillars of OOP

Object-Oriented Programming is based on four major principles:

Object-Oriented Programming

        │

 ┌──────┼────────┐
 │      │        │
 ▼      ▼        ▼
Encapsulation
Inheritance
Polymorphism
Abstraction

Let's understand each one.

1. Encapsulation

What is Encapsulation?

Encapsulation means keeping data and the methods that operate on that data together inside one object, while also controlling access to that data.

Think of a bank account.

Bank Account

Balance

Deposit()

Withdraw()

GetBalance()

Users should not directly change the balance.

Instead, they should use methods like deposit() or withdraw().

Example Using Private Fields

```javascript id="9wv9d8"
class BankAccount {

#balance = 0;

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

withdraw(amount) {
    this.#balance -= amount;
}

getBalance() {
    return this.#balance;
}

}

const account = new BankAccount();

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

console.log(account.getBalance());




Output



```id="z3pygk"
800

Trying this:

```javascript id="dn3x1x"
console.log(account.#balance);




Results in an error because `#balance` is private.

Benefits:

* Protects data
* Prevents accidental modification
* Improves security

---

# 2. Inheritance

## What is Inheritance?

Inheritance allows one class to acquire the properties and methods of another class.

Real-life example:



```id="elz6vy"
Animal

eat()

sleep()

      ▲

      │

Dog

bark()

The Dog class automatically gets the methods of Animal.

Example

```javascript id="l5v0qo"
class Animal {

eat() {
    console.log("Eating");
}

}

class Dog extends Animal {

bark() {
    console.log("Barking");
}

}

const dog = new Dog();

dog.eat();
dog.bark();




Output



```id="v7h7ew"
Eating

Barking

Inheritance avoids code duplication.

Using super()

The super keyword calls the parent class constructor.

```javascript id="klyp92"
class Animal {

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

}

class Dog extends Animal {

constructor(name, breed) {
    super(name);
    this.breed = breed;
}

}

const dog = new Dog("Tom", "Labrador");

console.log(dog);




Output



```id="tht91x"
Dog {

name: "Tom",

breed: "Labrador"

}

3. Polymorphism

What is Polymorphism?

Polymorphism means one interface, many forms.

Different objects can implement the same method differently.

Example

```javascript id="e8iqcx"
class Animal {

speak() {
    console.log("Animal Sound");
}

}

class Dog extends Animal {

speak() {
    console.log("Bark");
}

}

class Cat extends Animal {

speak() {
    console.log("Meow");
}

}

const dog = new Dog();
const cat = new Cat();

dog.speak();
cat.speak();




Output



```id="t9hvo8"
Bark

Meow

Both classes have a speak() method, but each behaves differently.

This is method overriding, one of the most common forms of polymorphism.

4. Abstraction

What is Abstraction?

Abstraction means showing only essential features while hiding internal implementation details.

Example:

When driving a car, you use the steering wheel, accelerator, and brake. You don't need to know how the engine or transmission works internally.

Example

```javascript id="b9u74f"
class CoffeeMachine {

makeCoffee() {
    this.#boilWater();
    console.log("Coffee Ready");
}

#boilWater() {
    console.log("Boiling Water...");
}

}

const machine = new CoffeeMachine();

machine.makeCoffee();




Output



```id="yb3poh"
Boiling Water...

Coffee Ready

Users only call makeCoffee(). The internal boiling process is hidden.

Prototype-Based OOP

Even though JavaScript has classes, everything is still based on prototypes.

```javascript id="fxz6eh"
class Person {

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

greet() {
    console.log("Hello");
}

}




Internally, JavaScript creates:



```javascript id="sx6uyj"
function Person(name) {
    this.name = name;
}

Person.prototype.greet = function () {
    console.log("Hello");
};

This is why JavaScript is called a prototype-based language.

Object Relationships

Student Object

name

age

study()

        │

        ▼

Student.prototype

study()

        │

        ▼

Object.prototype

toString()

hasOwnProperty()

valueOf()

        │

        ▼

null

Class Example

```javascript id="z93vrl"
class Employee {

constructor(name, salary) {
    this.name = name;
    this.salary = salary;
}

display() {
    console.log(this.name, this.salary);
}

}

const emp1 = new Employee("Sai", 50000);
const emp2 = new Employee("Ram", 70000);

emp1.display();
emp2.display();




Output



```id="qg64t9"
Sai 50000

Ram 70000

Advantages of OOP

Promotes code reusability through inheritance.
Improves maintainability by organizing related data and behavior.
Enhances security with encapsulation.
Simplifies large projects by dividing functionality into objects.
Makes applications easier to extend and scale.

OOP vs Procedural Programming

Procedural Programming	Object-Oriented Programming
Focuses on functions	Focuses on objects
Data and functions are separate	Data and methods are grouped together
Less reusable	Highly reusable
Difficult to maintain in large projects	Easier to maintain and scale
No inheritance	Supports inheritance

Interview Questions

What is OOP?

Object-Oriented Programming is a programming paradigm that organizes code into objects containing properties and methods.

What are the four pillars of OOP?

Encapsulation
Inheritance
Polymorphism
Abstraction

Is JavaScript object-oriented?

Yes. JavaScript is an object-oriented language that uses prototype-based inheritance. ES6 introduced class syntax, but it still works on top of prototypes.

What is the difference between a class and an object?

A class is a blueprint for creating objects.

An object is an instance of a class.

What is inheritance?

Inheritance allows one class to acquire the properties and methods of another class, reducing code duplication.

What is encapsulation?

Encapsulation groups data and methods together while controlling access to internal data, often using private fields.

What is polymorphism?

Polymorphism allows the same method name to have different implementations in different classes.

What is abstraction?

Abstraction hides internal implementation details and exposes only the necessary functionality.

DEV Community: Sai Swaroop Bijinapalli

Node.js Fundamentals: Runtime, Architecture, Core Modules, Streams, Buffers & Non-Blocking I/O

Node.js Fundamentals: Runtime, Architecture, Core Modules, Streams, Buffers & Non-Blocking I/O

1. What is Node.js?

2. Node.js Runtime

V8

libuv

3. Node.js Architecture

4. What is the Event Loop?

5. Event Loop Phases

Timers

Pending Callbacks

Poll

Check

Close Callbacks

6. Node.js Core Modules

7. The fs Module

8. The path Module

9. The os Module

10. The events Module

11. What Are Streams?

12. Types of Streams

Readable Stream

Writable Stream

Duplex Stream

Transform Stream

13. Buffers

14. The process Object

Command-line arguments

Environment variables

Exiting the process

15. What Does Non-Blocking I/O Mean?

16. Why Is Non-Blocking I/O Useful?

17. How Everything Connects

Conclusion

Deep Git Workflows: Rebasing, Conflict Resolution and Branching Strategies

Deep Git Workflows: Rebasing, Conflict Resolution and Branching Strategies

1. Merge vs Rebase

Git Merge

Advantages of Merge

Disadvantage

2. Git Rebase

Advantages of Rebase

Disadvantage

3. Merge vs Rebase

4. Interactive Rebase

5. Squashing Commits

6. Reordering Commits

7. Editing Commits

8. Resolving Merge Conflicts

9. Git Stash

10. Git Cherry-Pick

11. Git Revert

12. Git Reset

Soft Reset

Mixed Reset

Hard Reset

13. Revert vs Reset

14. Git Tags

15. Branching Strategies

16. Git Flow

Advantages

Disadvantages

17. GitHub Flow

18. Trunk-Based Development

19. Comparing Branching Strategies

20. Clean Git History as Documentation

21. A Practical Workflow

22. The Golden Rules of Advanced Git

Rule 1 — Rebase your own local work

Rule 2 — Be careful rebasing shared history

Rule 3 — Use stash for unfinished work

Rule 4 — Use cherry-pick for a specific commit

Rule 5 — Use revert for safely undoing published changes

Rule 6 — Use reset carefully

Rule 7 — Use tags for releases

Conclusion

TypeScript Concepts

TypeScript: A Beginner-Friendly Guide

What is TypeScript?

7. The `fs` Module

8. The `path` Module

9. The `os` Module

10. The `events` Module

14. The `process` Object