DEV Community: koushikmaya

# NestJS Fundamentals: Modules, Controllers, Services, Dependency Injection & Request Lifecycle

koushikmaya — Fri, 09 Oct 2026 06:56:54 +0000

When I first started learning NestJS, I kept seeing decorators like @Module(), @Controller(), and @Injectable() everywhere.

Then there were modules, providers, services, dependency injection, and the request lifecycle.

At first, they looked like lots of separate concepts to memorize. But they make much more sense when I think of NestJS as a well-organized team: each part has a responsibility, and the framework connects those parts together.

In this blog, I'll walk through the main concepts using a small example: a simple API that manages users.

1. What Is NestJS?

NestJS is a framework for building server-side applications with Node.js. It uses TypeScript by default and builds on HTTP platforms such as Express or Fastify.

You can build APIs using plain Node.js, but as an application grows, you need a consistent way to organize code.

NestJS gives us a structure for that:

Application
   |
   ├── Modules      → organize related features
   ├── Controllers  → handle incoming requests
   ├── Providers    → contain reusable logic and dependencies
   └── DI Container → connects classes and their dependencies

Instead of putting every feature into one giant file, we split the application into clear pieces.

2. Imagine a Restaurant

A restaurant is a useful analogy for understanding NestJS.

Imagine a customer orders a meal.

The waiter receives the customer's request.
The kitchen team prepares the meal.
The restaurant manager organizes the staff and their responsibilities.
The restaurant's staffing system makes sure the right people are available to do their jobs.

In a NestJS application:

Restaurant	NestJS
Waiter receiving an order	Controller
Kitchen preparing the meal	Service/provider
Department organizing related work	Module
System connecting staff and dependencies	Dependency Injection (DI) container
Rules for how a request is handled	Request lifecycle

This analogy isn't exact, but it helps explain why these parts exist.

3. Controllers: Receiving Requests

A controller handles incoming requests and sends responses.

For example, a user visits:

GET /users

A controller can handle that route.

Create users.controller.ts:

import { Controller, Get } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

Let's understand what's happening.

`@Controller('users')`

This tells NestJS that the class is a controller and its routes start with /users.

`@Get()`

This maps a GET request to the controller's base route.

Together, these decorators map to:

GET /users

`findAll()`

This method handles the request. It delegates the actual user-related work to UsersService.

Why not put all the logic in the controller?

Controllers should generally focus on HTTP-related work: receiving input, calling the appropriate logic, and returning a response.

Keeping business logic in a service makes the code easier to test and maintain.

4. Providers and Services: Doing the Work

A provider is a class or value that NestJS can manage and inject into other parts of the application.

A service is a common kind of provider.

For example, UsersService can contain the logic for retrieving users.

Create users.service.ts:

import { Injectable } from '@nestjs/common';

@Injectable()
export class UsersService {
  private readonly users = [
    { id: 1, name: 'Koushik' },
    { id: 2, name: 'Alex' },
  ];

  findAll() {
    return this.users;
  }

  findOne(id: number) {
    return this.users.find((user) => user.id === id);
  }
}

This service stores some sample users in memory. In a real application, the service might query PostgreSQL, MongoDB, or another data source.

What does `@Injectable()` mean?

It marks the class as available for NestJS's dependency injection system.

It does not automatically register the service in every module. The provider generally still needs to be registered in a module.

5. Modules: Organizing the Application

A module groups related parts of an application.

For example, all user-related code can belong to a UsersModule.

Create users.module.ts:

import { Module } from '@nestjs/common';
import { UsersController } from './users.controller';
import { UsersService } from './users.service';

@Module({
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

Let's break it down.

`@Module()`

This decorator gives NestJS metadata describing how the module is organized.

`controllers`

controllers: [UsersController]

These are the controllers that belong to this module.

`providers`

providers: [UsersService]

These are the providers NestJS should manage in this module's dependency injection context.

The module connects the controller and service so NestJS can instantiate them and provide the service to the controller.

6. How the Pieces Connect

Our feature has three files:

src/
└── users/
    ├── users.controller.ts
    ├── users.service.ts
    └── users.module.ts

Their responsibilities are different:

UsersModule
   |
   ├── registers UsersController
   |
   └── registers UsersService
                ↑
                |
UsersController ┘

The controller depends on the service. The module registers both with NestJS.

But who creates the service instance and supplies it to the controller?

That's where dependency injection comes in.

7. Dependency Injection (DI)

Dependency Injection sounds complicated, but the basic idea is simple:

A class declares what it needs, and another system supplies that dependency.

Consider the controller:

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}
}

The controller needs a UsersService.

Instead of creating the service manually like this:

const usersService = new UsersService();

NestJS creates and manages the provider, then supplies it to the controller.

The controller declares its dependency through its constructor. NestJS's DI system resolves that dependency using the provider registrations in the module.

8. What Is the DI Container?

The dependency injection container is the part of NestJS that manages registered providers and their dependencies.

A simplified view:

             UsersModule
                  |
          ┌───────┴────────┐
          |                |
    UsersController    UsersService
          |
          | needs
          v
     DI Container
          |
          └── supplies UsersService

The container helps NestJS:

create class instances
resolve constructor dependencies
manage provider lifetimes
reuse providers according to their scope
make code easier to test by replacing dependencies

By default, many NestJS providers are singleton-scoped within their module/application context. The same instance is generally reused rather than creating a new instance for every request. Request-scoped and transient providers are also available when needed.

9. Why Is DI Better Than Creating Classes Manually?

Imagine a controller creates its service directly:

export class UsersController {
  private readonly usersService = new UsersService();
}

This may work for a tiny example, but it tightly couples the controller to that concrete class.

Later, you might want a mock service for tests or a different implementation.

With dependency injection:

constructor(private readonly usersService: UsersService) {}

NestJS manages the dependency. In tests, you can provide a mock instead of the real service.

The key benefit: DI reduces manual object creation and makes dependencies easier to replace and test.

10. How Does NestJS Know What to Inject?

In the usual NestJS TypeScript pattern, the constructor declares the dependency:

constructor(private readonly usersService: UsersService) {}

NestJS uses metadata and its module provider registrations to resolve UsersService.

For this to work, the provider must be registered in the appropriate module or made available through an imported module.

If the provider isn't registered or accessible, NestJS generally reports a dependency resolution error during startup.

11. The Main Application Module

NestJS applications usually have a root module, often called AppModule. It brings the application's feature modules together.

For example, app.module.ts:

import { Module } from '@nestjs/common';
import { UsersModule } from './users/users.module';

@Module({
  imports: [UsersModule],
})
export class AppModule {}

The imports array means that AppModule imports UsersModule.

It does not mean that every provider inside UsersModule automatically becomes available everywhere. Modules control provider visibility, and providers that need to be shared are commonly exported by one module and imported by another.

The root module is loaded when the application starts.

12. Understanding the Three Main Decorators

`@Module()`

Used on a module class.

@Module({
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

It describes which controllers and providers belong to the module, and which other modules it imports or exports.

`@Controller()`

Used on a controller class.

@Controller('users')
export class UsersController {}

It identifies the class as a controller and can define a route prefix.

`@Injectable()`

Used on a class that participates in dependency injection.

@Injectable()
export class UsersService {}

It marks the class as injectable so NestJS can manage and inject it when registered appropriately.

Remember:

Decorators attach metadata. NestJS uses that metadata to organize and run the application.

13. The Request Lifecycle

Now let's connect everything.

Imagine the client sends:

GET /users

A simplified request flow looks like this:

Client Request
      |
      v
Middleware
      |
      v
Guards
      |
      v
Interceptors (before)
      |
      v
Pipes
      |
      v
Controller
      |
      v
Service / Provider
      |
      v
Database or other work
      |
      v
Controller result
      |
      v
Interceptors (after)
      |
      v
HTTP Response

Exception filters handle errors along the way. The exact flow depends on where an error occurs and which features are configured.

Let's understand the main pieces.

14. Middleware

Middleware runs early in the request pipeline, before the route handler.

It can inspect or modify the request and response objects, end the request, or pass control onward.

Common uses include:

request logging
adding a request ID
basic request processing

For example, middleware might log:

GET /users
Request ID: abc-123

If middleware ends the response, the request may not proceed to the controller.

15. Guards

Guards decide whether a request is allowed to continue to a route handler.

For example:

Request
   |
   v
Is the user authenticated?
   |
   ├── Yes → Continue
   |
   └── No  → Reject request

Guards are commonly used for authentication and authorization decisions.

A guard is not the same as a service: a guard decides whether the request may proceed, while a service typically performs application work.

16. Interceptors

Interceptors can run logic before and after the route handler's execution.

They are useful for things like:

logging execution time
transforming response data
working with RxJS observables
implementing caching patterns

Conceptually:

Request
   |
   v
Interceptor: before
   |
   v
Controller + Service
   |
   v
Interceptor: after
   |
   v
Response

The "after" part usually wraps the result returned by the handler.

17. Pipes

Pipes are commonly used to transform or validate incoming values.

For example, a route parameter arrives as text:

/users/123

But the service may need the ID as a number.

A pipe such as ParseIntPipe can convert and validate it.

import { Controller, Get, Param, ParseIntPipe } from '@nestjs/common';

@Controller('users')
export class UsersController {
  @Get(':id')
  findOne(@Param('id', ParseIntPipe) id: number) {
    return { id };
  }
}

Now NestJS parses the id route parameter as an integer. If the value isn't a valid integer, the pipe throws an HTTP exception instead of allowing the invalid value through.

Pipes are also frequently used with DTO validation to validate request bodies.

18. Exception Filters

Something can go wrong at many points in a request.

For example:

the requested user doesn't exist
the user is not allowed to access a resource
a database operation fails
input validation fails

Exception filters control how exceptions are translated into HTTP responses.

NestJS includes built-in exception handling, and you can also create custom exception filters.

For example, a not-found exception can produce a response such as:

{
  "statusCode": 404,
  "message": "User not found",
  "error": "Not Found"
}

The exact response shape depends on the exception and any custom filters.

19. A Small End-to-End Example

Let's imagine a client requests:

GET /users/2

Our controller:

import { Controller, Get, Param, ParseIntPipe } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get(':id')
  findOne(@Param('id', ParseIntPipe) id: number) {
    return this.usersService.findOne(id);
  }
}

Our service:

import { Injectable } from '@nestjs/common';

@Injectable()
export class UsersService {
  private readonly users = [
    { id: 1, name: 'Koushik' },
    { id: 2, name: 'Alex' },
  ];

  findOne(id: number) {
    return this.users.find((user) => user.id === id);
  }
}

Our module:

import { Module } from '@nestjs/common';
import { UsersController } from './users.controller';
import { UsersService } from './users.service';

@Module({
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

And our root module:

import { Module } from '@nestjs/common';
import { UsersModule } from './users/users.module';

@Module({
  imports: [UsersModule],
})
export class AppModule {}

When the request arrives, the main steps are:

NestJS matches GET /users/2 to UsersController.findOne().
ParseIntPipe validates and converts "2" to the number 2.
The controller calls usersService.findOne(2).
NestJS has already resolved the service dependency through DI.
The service finds the user.
NestJS serializes the returned object as the HTTP response.

Because this example uses an in-memory array, the data resets when the application restarts. A real service might query a database instead.

20. A Note About Provider Scope

By default, providers are usually singleton-scoped. NestJS generally creates one instance and reuses it in the relevant application context.

Other scopes include:

Singleton (default): instance is shared in the module/application context.
Request-scoped: a new instance is created for each request context.
Transient: a new instance is created for each consumer that injects it.

Don't use request scope everywhere just because requests are coming in. It can increase object creation and affect performance. Use it when you genuinely need per-request state.

21. Common Beginner Mistakes

Mistake 1: Forgetting to register a service

Adding @Injectable() alone isn't enough. The provider generally needs to be registered in a module's providers array or supplied through another valid provider configuration.

Mistake 2: Putting all business logic in the controller

Controllers become harder to maintain if they contain database queries, validation rules, and complex business logic.

Keep controllers focused on handling HTTP and delegate the work to services/providers.

Mistake 3: Thinking modules automatically share every provider

A provider is not automatically available across all modules.

To share a provider, you typically export it from its module and import that module where it is needed.

Mistake 4: Confusing authentication and validation

Guards commonly decide whether the request is allowed.
Pipes commonly validate or transform incoming values.
Services perform business operations.

Each has a different responsibility.

Mistake 5: Thinking a service must always connect to a database

A service can do many kinds of work. It may calculate values, call another API, coordinate business rules, or interact with a database.

22. The Big Picture

Here's how the concepts fit together:

                 AppModule
                    |
                    v
                UsersModule
                    |
          ┌─────────┴─────────┐
          |                   |
   UsersController       UsersService
          |                   |
          | needs             | performs
          |                   | business logic
          v                   v
       DI Container       Data source
          |
          └── injects UsersService
              into UsersController

And the request pipeline:

HTTP Request
     |
 Middleware
     |
   Guards
     |
Interceptors (before)
     |
    Pipes
     |
 Controller
     |
   Service
     |
 Data source
     |
Interceptors (after)
     |
HTTP Response

Exception filters handle errors along the way.

23. Quick Revision Cheat Sheet

Concept	Simple Meaning
Module	Groups related controllers and providers
Controller	Handles incoming requests and route mapping
Provider	A dependency managed by NestJS
Service	A common provider for application/business logic
DI	A class declares dependencies; the framework supplies them
DI container	Resolves and manages registered providers
`@Module()`	Describes module structure
`@Controller()`	Declares a controller and optional route prefix
`@Injectable()`	Marks a class as usable with dependency injection
Middleware	Runs early and can process requests before routing logic
Guard	Decides whether a request may proceed
Interceptor	Wraps handler execution before and after
Pipe	Validates or transforms input
Exception filter	Controls exception handling and error responses
Provider scope	Controls how provider instances are created and reused

24. Final Takeaway

The main thing I want to remember is that NestJS isn't just a collection of decorators.

Each concept has a job:

Modules organize features.
Controllers receive HTTP requests.
Services/providers perform reusable application work.
The DI container connects classes and manages dependencies.
Decorators provide metadata that NestJS uses to understand the application.
The request lifecycle defines how a request moves through the application and becomes a response.

Once this structure makes sense, NestJS code becomes much easier to read.

Instead of asking, "Why are there so many files?", I can ask:

"What responsibility does each file have, and how does NestJS connect them?"

That is a much more useful way to learn the framework.

week-07 Task-3 # package.json, SemVer, npm Scripts, Configuration & Monorepos: Understanding the Node.js Project Setup

koushikmaya — Thu, 08 Oct 2026 05:09:28 +0000

When I first created a Node.js project, I mostly thought:

npm init

creates a package.json, and then I install packages with:

npm install express

Done.

But package.json is actually much more important than that.

It describes the project, manages dependencies, defines commands, and can even control how the application is started.

Then there are terms like:

SemVer
dependencies
devDependencies
npm scripts
environment variables
dotenv
configuration management
monorepos

At first, these felt like separate topics.

But they are all part of one bigger question:

How do we keep a Node.js project organized, reproducible, and configurable as it grows?

1. What Is `package.json`?

package.json is basically the identity card and configuration file of a Node.js project.

A simple example:

{
  "name": "my-node-app",
  "version": "1.0.0",
  "description": "A simple Node.js application",
  "main": "src/index.js",
  "scripts": {
    "start": "node src/index.js"
  },
  "dependencies": {
    "express": "^5.0.0"
  }
}

It tells npm things like:

What is this project called?
What version is it?
What packages does it need?
What commands can I run?
What is the entry point?
What kind of project is this?

2. Why Does `package.json` Matter?

Imagine giving your project to another developer.

You don't want to say:

"Install Express, install Jest, install this package, then run this command..."

Instead, they should be able to clone the project and run:

npm install

npm reads:

package.json

and knows what packages the project needs.

Then they can run:

npm start

or:

npm test

depending on the scripts defined by the project.

So package.json helps make a project repeatable.

3. Creating `package.json`

The usual command is:

npm init

npm asks questions such as:

package name
version
description
entry point
test command
git repository
keywords
author
license

You can also skip the interactive questions:

npm init -y

This creates a default package.json.

4. Understanding the Main Fields

A common package.json might look like:

{
  "name": "node-api",
  "version": "1.0.0",
  "description": "A Node.js REST API",
  "main": "src/index.js",
  "scripts": {
    "start": "node src/index.js",
    "test": "node --test"
  },
  "dependencies": {
    "express": "^5.0.0"
  },
  "devDependencies": {
    "eslint": "^9.0.0"
  }
}

Let's break this down.

5. `name`

"name": "node-api"

This is the name of the package/project.

For a publishable npm package, naming rules matter.

For a normal application, it mainly identifies the project.

6. `version`

"version": "1.0.0"

This represents the current version of the project/package.

This leads us to an important concept:

Semantic Versioning

or simply:

SemVer

7. SemVer: Semantic Versioning

Semantic Versioning usually looks like:

MAJOR.MINOR.PATCH

For example:

2.4.7

means:

MAJOR = 2
MINOR = 4
PATCH = 7

The basic idea is:

2.4.7
│ │ │
│ │ └── PATCH
│ └──── MINOR
└────── MAJOR

8. MAJOR Version

The major version generally changes when there are breaking changes.

For example:

1.5.2

becomes:

2.0.0

Imagine a library had:

getUser(id)

and in version 2 it changes to:

getUser({ id })

Existing code may stop working.

That's the kind of change that can justify a major version increase.

Think:

MAJOR = "Something may break."

9. MINOR Version

A minor version generally adds functionality while maintaining backward compatibility.

For example:

1.5.2

becomes:

1.6.0

Maybe a new feature is added:

getUser()
getUsers()
searchUsers()

Existing code should continue working.

Think:

MINOR = "New functionality, but existing usage should continue working."

10. PATCH Version

A patch version is generally for backward-compatible fixes.

For example:

1.5.2

becomes:

1.5.3

Maybe a bug is fixed.

Think:

PATCH = "Bug fix."

11. The Easy SemVer Memory Trick

Remember:

MAJOR → Breaking changes
MINOR → New features
PATCH → Bug fixes

So:

1.4.2

can become:

2.0.0   → breaking change
1.5.0   → new feature
1.4.3   → bug fix

This is the basic idea behind SemVer.

12. What Does `^` Mean?

You may have seen this:

"express": "^5.0.0"

The ^ is a version range operator.

It tells npm that compatible updates within the allowed SemVer range can be installed.

For a dependency already using:

^5.0.0

the range generally allows versions:

>=5.0.0 <6.0.0

So npm can install a newer compatible release such as:

5.1.0

or:

5.2.3

but not:

6.0.0

because that crosses the major version boundary.

13. What Does `~` Mean?

You may also see:

"express": "~5.0.0"

The ~ is usually more restrictive.

It generally allows patch-level updates within the same minor version:

>=5.0.0 <5.1.0

So versions such as:

5.0.1
5.0.2
5.0.9

can fit the range, while:

5.1.0

does not.

14. Exact Versions

You can also specify:

"express": "5.0.0"

This requests exactly that version.

No SemVer range is being specified.

In practice, the lockfile also plays an important role in ensuring reproducible installations.

15. `dependencies` vs `devDependencies`

This is one of the most common Node.js questions.

What's the difference between:

"dependencies": {}

and:

"devDependencies": {}

The simple answer is:

dependencies are needed by the application.

devDependencies are mainly needed while developing, testing, building, or maintaining the application.

16. Example of a Dependency

Suppose we're building an Express API.

We write:

const express = require("express");

Our application needs Express to actually run.

So:

npm install express

will put Express under:

"dependencies"

For example:

"dependencies": {
  "express": "^5.0.0"
}

17. Example of a Dev Dependency

Suppose we use ESLint:

npm install --save-dev eslint

ESLint helps us check our code.

But our production API doesn't need ESLint running to process:

GET /users

It's a development tool.

So it belongs in:

"devDependencies"

Example:

"devDependencies": {
  "eslint": "^9.0.0"
}

18. More Examples

Usually dependencies

express
nestjs
mongoose
pg
drizzle-orm
jsonwebtoken

These are packages your application may need while running.

Usually devDependencies

jest
eslint
prettier
typescript
nodemon
testing tools
build tools

These are usually tools used during development, testing, or building.

The exact classification can depend on the project's architecture.

19. A Simple Question to Decide

When you're unsure where a package belongs, ask:

"Does my application need this package to actually run in its target environment?"

If yes:

dependencies

If it's primarily there to help you develop, test, lint, format, or build:

devDependencies

20. What Is `package-lock.json`?

When you install packages, npm usually creates:

package-lock.json

This file records the exact dependency tree that npm resolved.

For example, package.json might say:

"express": "^5.0.0"

That allows a range of versions.

But the lockfile records the specific versions selected during installation, along with their dependency information.

This helps different developers and CI environments install a consistent dependency tree.

So a useful mental model is:

package.json
→ What versions/ranges does the project allow?

package-lock.json
→ What exact dependency tree was resolved?

For npm projects, the lockfile is normally committed to Git.

21. npm Scripts

Now let's talk about another extremely useful part of package.json:

"scripts": {}

Scripts are shortcuts for commands we repeatedly run.

For example:

"scripts": {
  "start": "node src/index.js",
  "test": "node --test"
}

Now instead of typing:

node src/index.js

we can type:

npm start

And:

npm test

runs the test command.

22. Why Are npm Scripts Useful?

Imagine a project has these commands:

node src/index.js
npm run lint
npm test
npm run build

Instead of asking every developer to memorize them, we put them in:

"scripts"

Then the project becomes self-documenting.

For example:

"scripts": {
  "dev": "node --watch src/index.js",
  "start": "node src/index.js",
  "test": "node --test",
  "lint": "eslint ."
}

Now I know:

npm run dev
npm start
npm test
npm run lint

23. `npm run`

For most custom scripts, use:

npm run <script>

For example:

npm run dev

npm run lint

npm run build

Some scripts have special npm shortcuts.

For example:

npm start
npm test

are commonly used directly.

24. A Realistic `scripts` Section

A Node.js project might have:

"scripts": {
  "dev": "node --watch src/index.js",
  "start": "node src/index.js",
  "test": "node --test",
  "lint": "eslint .",
  "format": "prettier --write ."
}

This gives the project a predictable interface.

As a developer, I don't need to remember exactly how every command works internally.

I just run the project's scripts.

25. Configuration Management

Now let's imagine our application needs:

PORT
DATABASE_URL
JWT_SECRET
API_KEY
NODE_ENV

We could hard-code them:

const port = 3000;
const databaseUrl = "postgres://...";

But this is a bad idea for many real applications.

Why?

Because different environments need different values.

For example:

Development
PORT=3000

Testing
PORT=4000

Production
PORT=8080

The same code should ideally work in all three environments.

Only the configuration should change.

26. Environment Variables

Environment variables let us keep configuration outside the source code.

For example:

PORT=3000
NODE_ENV=development
DATABASE_URL=postgres://localhost/mydb

Then Node.js can access them using:

process.env.PORT

For example:

const port = Number(process.env.PORT || 3000);

This means:

Use the PORT environment variable if it exists; otherwise use 3000.

27. Why Not Put Secrets in Git?

Imagine this:

const JWT_SECRET = "super-secret-password";

and then we push the code to GitHub.

Now the secret may be exposed.

Instead, we can use:

JWT_SECRET=some-secret-value

and read it through:

process.env.JWT_SECRET

The actual secret should be provided through the deployment environment or a secret-management system.

28. What Is dotenv?

Node.js can read environment variables supplied by the operating system through:

process.env

But during local development, it is convenient to store variables in a .env file.

For example:

PORT=3000
NODE_ENV=development
DATABASE_URL=postgres://localhost/social_feed_dev

A popular package called dotenv can load these values into process.env.

Install it:

npm install dotenv

Then:

require("dotenv").config();

Now:

console.log(process.env.PORT);

can access the value from .env.

29. `dotenv/config`

There is also a convenient way to load dotenv automatically.

For CommonJS:

require("dotenv").config();

For some Node.js setups, you may see:

node -r dotenv/config src/index.js

The idea is:

Load the .env configuration before the application starts.

The exact approach depends on how the project is structured.

30. `.env` Should Usually Not Be Committed

A typical project might have:

.env
.env.example

.env contains actual local values:

DATABASE_URL=real-local-value
JWT_SECRET=real-secret

.env.example contains the expected variable names without real secrets:

PORT=
NODE_ENV=
DATABASE_URL=
JWT_SECRET=

Then .gitignore should normally contain:

.env

This gives other developers a template without exposing your secrets.

31. Configuration Should Be Centralized

Instead of scattering:

process.env.PORT
process.env.DATABASE_URL
process.env.JWT_SECRET

throughout the application, we can create a configuration layer.

For example:

const config = {
  port: Number(process.env.PORT || 3000),
  databaseUrl: process.env.DATABASE_URL,
  jwtSecret: process.env.JWT_SECRET
};

module.exports = config;

Then other parts of the application can use:

config.port

instead of directly reading environment variables everywhere.

This creates a clean boundary:

Environment
     ↓
Configuration
     ↓
Application

32. Configuration Validation

There's another important improvement.

Suppose:

DATABASE_URL

is missing.

Our application might start and fail much later with a confusing database error.

Instead, we can validate configuration at startup.

Conceptually:

Application starts
       ↓
Load configuration
       ↓
Validate required values
       ↓
Invalid?
  ├── Yes → Fail fast
  └── No  → Start application

For example:

if (!process.env.DATABASE_URL) {
  throw new Error("DATABASE_URL is required");
}

In larger applications, configuration libraries can make this cleaner.

33. Development vs Production Configuration

The same application may run in:

Development
Testing
Staging
Production

For example:

NODE_ENV=development

or:

NODE_ENV=production

Configuration may differ between these environments.

But the application code should ideally remain the same.

Think:

Same application
       +
Different configuration
       =
Different environment

34. What Is a Monorepo?

Now let's move to a bigger project concept.

A monorepo means keeping multiple related projects/packages in one Git repository.

For example:

company-project/
│
├── apps/
│   ├── web/
│   ├── api/
│   └── admin/
│
├── packages/
│   ├── ui/
│   ├── config/
│   └── shared/
│
└── package.json

Instead of having:

frontend-repo
backend-repo
shared-repo

we keep them together.

35. Why Use a Monorepo?

Imagine a company has:

React Web App
Node API
Admin Dashboard
Shared UI Components
Shared TypeScript Types

These projects may depend on each other.

A monorepo makes it easier to manage them together.

For example:

apps/web
      ↓
packages/ui

apps/api
      ↓
packages/types

The shared packages live in the same repository.

36. Monorepo vs Polyrepo

Polyrepo

Separate repositories:

frontend-repo
backend-repo
mobile-repo
shared-types-repo

Monorepo

One repository:

company-repo
├── apps
│   ├── frontend
│   ├── backend
│   └── mobile
└── packages
    └── shared

Neither approach is automatically better.

The right choice depends on the team's needs, deployment strategy, tooling, and project structure.

37. npm Workspaces

npm itself supports a basic monorepo mechanism called workspaces.

A root package.json might contain:

{
  "name": "my-monorepo",
  "private": true,
  "workspaces": [
    "apps/*",
    "packages/*"
  ]
}

Then the repository can contain:

apps/
  api/
  web/

packages/
  shared/
  ui/

Each workspace can have its own:

package.json

while npm manages the overall workspace.

38. Why `private: true`?

You will often see:

"private": true

in the root package of a monorepo.

It tells npm that this package is not intended to be published as a normal npm package.

The root is mainly being used to manage the workspace.

39. Monorepo Mental Model

Think of a monorepo as a company building.

              Company Building
                    |
       ┌────────────┼────────────┐
       |            |            |
     Web App      API        Admin App
       |            |            |
       └────────────┼────────────┘
                    |
              Shared Packages

Everything is in one repository, but each application/package can still have its own responsibility.

40. Do I Need a Monorepo as a Beginner?

Probably not.

If you're building:

one Node.js API

a normal repository is perfectly fine:

my-api/
├── src/
├── test/
├── package.json
├── package-lock.json
└── .env.example

Don't introduce monorepo tooling just because it sounds advanced.

First understand:

npm
package.json
dependencies
scripts
configuration
Git
testing
application structure

Then learn monorepos when your project actually has multiple related applications/packages.

41. Putting Everything Together

A realistic Node.js project might look like:

my-api/
│
├── src/
│   ├── config/
│   │   └── index.js
│   ├── routes/
│   ├── services/
│   └── index.js
│
├── test/
│
├── .env
├── .env.example
├── .gitignore
├── package.json
├── package-lock.json
└── README.md

The package.json might look like:

{
  "name": "my-api",
  "version": "1.0.0",
  "scripts": {
    "dev": "node --watch src/index.js",
    "start": "node src/index.js",
    "test": "node --test"
  },
  "dependencies": {
    "dotenv": "^17.0.0",
    "express": "^5.0.0"
  },
  "devDependencies": {
    "eslint": "^9.0.0"
  }
}

And .env.example:

PORT=3000
NODE_ENV=development
DATABASE_URL=
JWT_SECRET=

Now the project has:

package.json
    ↓
Project metadata + dependencies + scripts

package-lock.json
    ↓
Resolved dependency tree

.env
    ↓
Local configuration

dotenv
    ↓
Loads local environment variables

npm scripts
    ↓
Standard project commands

42. A Simple Mental Model

If I had to remember the whole topic in one diagram:

                    Node.js Project
                          |
            ┌─────────────┼─────────────┐
            |             |             |
       package.json     .env        package-lock
            |             |             |
       ┌────┴────┐        |        Exact dependency
       |         |        |           tree
 dependencies  scripts    |
       |         |        |
   Runtime    Commands   Configuration
   packages              |
                          ↓
                    process.env

And when the project becomes large:

                 Monorepo
                    |
          ┌─────────┴─────────┐
          |                   |
        apps/              packages/
          |                   |
      web / api          shared / ui

43. Quick Revision Cheat Sheet

Concept	Simple Meaning
`package.json`	Project metadata, dependencies, scripts, and configuration
`version`	Current package/project version
SemVer	Versioning convention: MAJOR.MINOR.PATCH
MAJOR	Breaking changes
MINOR	Backward-compatible features
PATCH	Backward-compatible fixes
`^`	Allows compatible updates within a major version
`~`	Usually allows patch updates within a minor version
`dependencies`	Packages needed by the application
`devDependencies`	Packages mainly needed for development/testing/building
`package-lock.json`	Records the resolved dependency tree
npm scripts	Named commands defined in `package.json`
Environment variable	Configuration supplied outside the code
`process.env`	Accesses environment variables in Node.js
dotenv	Loads variables from `.env` into `process.env`
`.env`	Local configuration/secrets; normally not committed
`.env.example`	Template showing required variables
Configuration layer	Central place for application configuration
Monorepo	Multiple related projects/packages in one repository
npm workspaces	npm's built-in workspace/monorepo mechanism

44. Final Takeaway

The biggest lesson for me is that a Node.js project isn't just:

JavaScript files

There is an entire ecosystem around the application.

package.json
     ↓
Defines the project
     ↓
Dependencies + scripts
     ↓
Application runs
     ↓
Configuration comes from environment
     ↓
dotenv can load local .env values
     ↓
package-lock keeps installations reproducible

And when the project grows:

One project
    ↓
Multiple applications/packages
    ↓
Monorepo

The important thing isn't memorizing every npm command.

It's understanding why these files and concepts exist.

Once that is clear, commands like:

npm install
npm install --save-dev eslint
npm run dev
npm test
npm start

stop feeling like random commands.

They become tools for managing a real software project.

And that's the point where Node.js development starts feeling much more organized.

week-7 Task-2 # HTTP & REST APIs: Understanding How the Web Actually Talks

koushikmaya — Thu, 08 Oct 2026 04:58:38 +0000

When I started backend development, I kept seeing terms like:

HTTP methods
GET, POST, PUT, PATCH, DELETE
status codes
headers
REST
statelessness
idempotency
resources

At first, they felt like a bunch of rules I just had to memorize.

But once I understood what actually happens when a browser or frontend talks to a backend, these concepts started fitting together.

This blog is my attempt to understand HTTP and REST as a conversation between a client and a server.

1. The Basic Idea: Client Talks to Server

Whenever we use an application, there is usually some communication happening between a client and a server.

For example, imagine a Twitter-like application.

I open my profile.

The frontend might send:

GET /users/123

The server processes the request and sends something back:

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

{
  "id": 123,
  "name": "Koushik"
}

That's HTTP communication.

The basic pattern is:

Client
  |
  | HTTP Request
  v
Server
  |
  | HTTP Response
  v
Client

This is the foundation of most web APIs.

2. What Is HTTP?

HTTP stands for:

HyperText Transfer Protocol

It is a protocol that defines how clients and servers communicate.

A client could be:

browser
React application
mobile app
Postman
another backend service

A server could be:

Node.js server
Express application
NestJS application
Java/Spring application
Python/Django application
Go server

The important thing is that both sides understand the HTTP rules.

3. The Request/Response Cycle

This is one of the most important concepts to understand.

Let's say I open:

GET /users/123

The process roughly looks like this:

1. Client creates request
          ↓
2. Request travels to server
          ↓
3. Server receives request
          ↓
4. Server finds the route
          ↓
5. Server runs application logic
          ↓
6. Server may query a database
          ↓
7. Server creates response
          ↓
8. Response travels back
          ↓
9. Client receives response

Let's go through it.

4. Step 1: The Client Creates a Request

Suppose my frontend wants to get a user.

It might send:

GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer token

This request contains information telling the server what the client wants.

5. Step 2: The Request Travels to the Server

The request travels over the network.

The client needs to know where the server is.

For example:

https://api.example.com/users/123

The browser or HTTP client handles things like:

DNS lookup
establishing a network connection
TLS encryption for HTTPS
sending the HTTP request

We don't usually think about all of these steps when writing backend code, but they happen underneath.

6. Step 3: The Server Receives the Request

Our Node.js application receives the HTTP request.

For example:

const http = require("node:http");

const server = http.createServer((req, res) => {
  console.log(req.method);
  console.log(req.url);
});

server.listen(3000);

If the client sends:

GET /users/123

we can access:

req.method

which gives:

GET

and:

req.url

which gives:

/users/123

7. Step 4: Routing

The server needs to figure out:

"What code should handle this request?"

For example:

GET /users
GET /users/123
POST /users
PATCH /users/123
DELETE /users/123

Each route can perform a different operation.

In a framework like Express or NestJS, routing becomes much easier to organize.

8. Step 5: Business Logic

Once the correct route is found, the application performs its work.

For example:

GET /users/123
        ↓
Find user 123
        ↓
Check permissions
        ↓
Fetch user from database
        ↓
Create response

The server might interact with:

PostgreSQL
MongoDB
Redis
another API
file storage

9. Step 6: The Server Sends a Response

The server eventually sends something back.

For example:

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

{
  "id": 123,
  "name": "Koushik"
}

The response tells the client:

"Here is the result of your request."

10. The Complete Story

So the entire process looks like:

Frontend
   |
   | GET /users/123
   ↓
HTTP Server
   |
   ↓
Router
   |
   ↓
Controller
   |
   ↓
Service
   |
   ↓
Database
   |
   ↓
Service
   |
   ↓
Controller
   |
   ↓
HTTP Response
   |
   ↓
Frontend

This pattern becomes very familiar when working with Node.js and NestJS.

11. HTTP Methods

HTTP methods describe what the client wants to do.

The most common methods are:

GET
POST
PUT
PATCH
DELETE

Instead of inventing URLs like:

/createUser
/getUser
/updateUser
/deleteUser

REST APIs generally use the resource name and let the HTTP method describe the action.

For example:

GET    /users
POST   /users
GET    /users/123
PATCH  /users/123
DELETE /users/123

The URL identifies the resource.

The method tells us what we want to do with it.

12. GET

GET means:

"Give me this resource."

Example:

GET /users/123

The server might respond:

{
  "id": 123,
  "name": "Koushik"
}

Another example:

GET /users

could return a list of users.

GET should generally be safe

A GET request should not change the server's state.

For example:

GET /users/123

shouldn't delete the user or change their name.

13. POST

POST is commonly used to create a new resource.

For example:

POST /users
Content-Type: application/json

{
  "name": "Koushik",
  "email": "koushik@example.com"
}

The server may create:

User ID = 124

and respond:

201 Created

with the new resource.

14. PUT

PUT is commonly used to replace a resource with a new representation.

For example:

PUT /users/123

{
  "name": "Koushik",
  "email": "new@example.com"
}

Conceptually:

Old User
   ↓
Replace with
   ↓
New User representation

PUT can also be used for an upsert-style operation depending on the API design, but the exact behavior should be documented.

The important idea is:

PUT represents replacing the target resource with the supplied representation.

15. PATCH

PATCH is generally used for a partial update.

Suppose the user currently has:

{
  "id": 123,
  "name": "Koushik",
  "email": "old@example.com",
  "age": 20
}

We only want to change the name.

We can send:

PATCH /users/123

{
  "name": "Koushik Maya"
}

Only the specified field needs to change.

So:

PUT
→ replace/update the complete representation

PATCH
→ partially modify the resource

In real APIs, the exact semantics of PATCH depend on the patch format and API design.

16. DELETE

DELETE means:

"Remove this resource."

Example:

DELETE /users/123

The server may respond:

204 No Content

There is no need to return the deleted user.

17. Quick HTTP Method Table

Method	Typical Purpose	Example
GET	Read	`GET /users/123`
POST	Create/process	`POST /users`
PUT	Replace	`PUT /users/123`
PATCH	Partial update	`PATCH /users/123`
DELETE	Delete	`DELETE /users/123`

18. What Is Idempotency?

This word sounds complicated, but the idea is simple.

A request is idempotent if making the same request multiple times has the same intended effect on the server's state as making it once.

For example:

PUT /users/123

with:

{
  "name": "Koushik"
}

If I send it once:

User name = Koushik

If I send it five times:

User name = Koushik

The final intended state is still the same.

That's idempotency.

19. GET Is Idempotent

Suppose:

GET /users/123

I send it:

1 time → get user
10 times → get user
100 times → get user

The server's resource state should not change.

GET is therefore considered idempotent and safe.

20. PUT Is Idempotent

Suppose:

PUT /users/123

{
  "name": "Koushik"
}

Sending it repeatedly should leave the resource in the same intended state.

Therefore, PUT is idempotent.

21. DELETE Is Idempotent

Suppose:

DELETE /users/123

First request:

User exists
       ↓
Delete user

Second request:

User already deleted

The response may be different, such as 404 Not Found, but the intended final state is still:

User does not exist

Therefore DELETE is considered idempotent.

This is an important distinction:

Idempotent does not mean every response must be identical.

It means repeated requests have the same intended effect on the resource state.

22. POST Is Generally Not Idempotent

Suppose:

POST /orders

{
  "productId": 10,
  "quantity": 1
}

If I send it once:

Order #1001 created

If I send it again:

Order #1002 created

Now I have two orders.

So POST is generally not idempotent.

This is one reason duplicate POST requests can be dangerous for operations like:

payments
order creation
account creation

Some APIs solve this with an idempotency key.

23. What About PATCH?

PATCH is more nuanced.

PATCH is not automatically idempotent.

It depends on what the patch operation actually does.

For example, imagine:

PATCH /users/123

{
  "name": "Koushik"
}

Repeatedly applying that update may result in the same state.

But imagine a patch operation meaning:

increase balance by ₹100

Repeating it could produce:

₹100
₹200
₹300

So PATCH can be idempotent or non-idempotent depending on its semantics.

24. HTTP Status Codes

When a server responds, it sends a status code.

For example:

200 OK

The first digit tells us the broad category.

1xx → Informational
2xx → Success
3xx → Redirection
4xx → Client Error
5xx → Server Error

The categories are more important to memorize than every individual status code.

25. 1xx — Informational

These indicate that the request has been received and the process is continuing.

You won't use these directly very often in typical REST API development.

26. 2xx — Success

This means:

"The request was successfully handled."

Common examples:

200 OK

General successful response.

GET /users/123
→ 200 OK

201 Created

A resource was successfully created.

POST /users
→ 201 Created

204 No Content

Successful request with no response body.

DELETE /users/123
→ 204 No Content

27. 3xx — Redirection

These indicate that the client may need to take another action or use another location.

A familiar example is:

301 Moved Permanently

This tells clients that a resource has permanently moved.

Another is:

304 Not Modified

which is commonly involved with caching.

28. 4xx — Client Errors

These generally mean:

"There is something wrong with the request from the client."

Common examples:

400 Bad Request

The request is invalid.

POST /users

with malformed or invalid input might result in:

400 Bad Request

401 Unauthorized

Authentication is required or the provided authentication is invalid.

A useful way to remember it:

"I don't know who you are."

403 Forbidden

The server understood who you are, but you don't have permission.

Think:

"I know who you are, but you're not allowed to do this."

404 Not Found

The requested resource doesn't exist.

GET /users/999999
→ 404 Not Found

409 Conflict

The request conflicts with the current state.

For example, trying to create a username that must be unique.

422 Unprocessable Content

The server understands the request format, but the submitted data fails validation or semantic rules.

29. 5xx — Server Errors

These generally mean:

"The server failed while trying to handle a valid request."

For example:

500 Internal Server Error

Maybe our application crashed while processing the request.

Other examples include:

502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

These are especially important when dealing with distributed systems and reverse proxies.

30. Status Code Mental Model

I find this easier to remember:

2xx
"Everything worked."

3xx
"Go somewhere else / use cached information."

4xx
"Your request has a problem."

5xx
"Something went wrong on the server."

31. HTTP Headers

Headers are metadata attached to HTTP requests and responses.

Think of them like labels attached to a package.

The package contains the actual content.

The labels tell us things about it.

For example:

Content-Type: application/json
Authorization: Bearer abc123
Cache-Control: no-cache

32. Content-Type

Content-Type tells the receiver what format the message body uses.

For example:

Content-Type: application/json

means:

"The body contains JSON."

A request might look like:

POST /users
Content-Type: application/json

{
  "name": "Koushik"
}

Other examples include:

text/plain
text/html
multipart/form-data
application/xml

This becomes particularly important when uploading files.

33. Accept Header

Although not in the original list, Accept is worth knowing alongside Content-Type.

Content-Type describes:

"What I am sending."

Accept describes:

"What I would like to receive."

For example:

Content-Type: application/json
Accept: application/json

This distinction is very useful when working with APIs.

34. Authorization

The Authorization header is commonly used to send authentication credentials.

For example:

Authorization: Bearer eyJhbGciOi...

The server can use the token to determine:

who the user is
whether the token is valid
what the user is allowed to do

A common pattern is:

Client
  |
  | Authorization: Bearer token
  ↓
Server
  |
  ↓
Validate token
  |
  ↓
Identify user

Important:

Authentication answers "Who are you?"

Authorization answers "Are you allowed to do this?"

35. Cache-Control

Cache-Control tells clients and intermediate caches how a response may be cached.

For example:

Cache-Control: max-age=3600

This can indicate that the response can be considered fresh for a certain period.

Another example:

Cache-Control: no-store

means the response should not be stored by a cache.

Caching can dramatically reduce unnecessary requests and improve performance.

36. Headers + Body

An HTTP message can be thought of like this:

HTTP Request
├── Method
├── URL
├── Headers
└── Body

Example:

POST /users HTTP/1.1
Content-Type: application/json
Authorization: Bearer token

{
  "name": "Koushik"
}

And the response:

HTTP Response
├── Status Code
├── Headers
└── Body

Example:

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

{
  "id": 123,
  "name": "Koushik"
}

37. What Does Stateless Mean?

REST APIs are commonly described as stateless.

At first this sounds like:

"The server doesn't remember anything."

That's not quite right.

Stateless means:

Each request should contain the information necessary for the server to understand and process that request.

The server shouldn't have to rely on hidden conversational state from a previous request.

38. Example of Stateless Authentication

Suppose I make:

GET /profile
Authorization: Bearer abc123

The server validates the token and identifies me.

Then I make another request:

GET /orders
Authorization: Bearer abc123

The second request contains the authentication information it needs.

The server doesn't need to think:

"This must be the same person who called /profile five seconds ago."

Each request carries the required context.

39. Why Statelessness Is Useful

Imagine you have three backend servers:

             Load Balancer
             /     |     \
            /      |      \
        Server A Server B Server C

A user makes one request:

Request 1 → Server A

Another request might go:

Request 2 → Server C

If the request contains the necessary authentication/context, any server can process it.

This makes horizontal scaling easier.

40. Stateless Does NOT Mean No Database

This is an important distinction.

A stateless API can absolutely use a database.

For example:

Request
   ↓
API Server
   ↓
Database
   ↓
Response

The database stores persistent application data.

Statelessness is about request-to-request application state, not about whether the application has storage.

41. REST

REST stands for:

Representational State Transfer

The name sounds intimidating, but the practical idea is much easier.

REST encourages us to model our API around resources.

Examples of resources:

users
posts
comments
orders
products

Instead of thinking:

"What function should this URL call?"

think:

"What resource am I working with?"

42. Resource Naming

A good REST API usually uses nouns rather than verbs.

Prefer:

GET /users

instead of:

GET /getUsers

Prefer:

POST /users

instead of:

POST /createUser

The HTTP method already tells us the action.

43. Resource Naming Examples

Good:

/users
/users/123
/posts
/posts/123
/comments
/comments/456

Less REST-like:

/getUsers
/createUser
/updateUser
/deleteUser
/getAllPosts

The idea is:

HTTP Method + Resource URL

together describe the operation.

44. Collections vs Individual Resources

A collection represents multiple resources:

/users

A specific resource:

/users/123

So:

GET /users

means:

"Give me users."

While:

GET /users/123

means:

"Give me user 123."

This distinction becomes extremely useful when designing APIs.

45. Nested Resources

Sometimes a resource belongs naturally to another resource.

For example:

/users/123/posts

could mean:

Posts belonging to user 123.

Or:

/posts/456/comments

could mean:

Comments belonging to post 456.

But nesting should not become unnecessarily deep.

Avoid things like:

/users/123/posts/456/comments/789/likes/10

if a simpler resource structure communicates the relationship.

46. Plural Resource Names

A common convention is to use plural nouns:

/users
/posts
/orders
/products

This makes collection endpoints intuitive.

For example:

GET /products
POST /products
GET /products/10
PATCH /products/10
DELETE /products/10

47. URLs Should Identify Resources

One of the biggest ideas in REST is:

The URL should identify the resource, while the HTTP method describes the operation.

For example:

GET    /users/123
POST   /users
PATCH  /users/123
DELETE /users/123

We don't need five completely different URLs.

The resource is:

/users/123

The method changes what we want to do with it.

48. Query Parameters

Query parameters are useful for filtering, sorting, searching, and pagination.

For example:

GET /users?role=admin

or:

GET /posts?limit=20&cursor=abc123

The path identifies the resource:

/posts

The query parameters describe how we want the collection represented.

49. A Real Example: Social Media API

Let's imagine we're building a Twitter-like application.

Get posts

GET /posts

Get one post

GET /posts/123

Create a post

POST /posts

{
  "content": "Learning Node.js!"
}

Update a post

PATCH /posts/123

{
  "content": "Learning Node.js and NestJS!"
}

Delete a post

DELETE /posts/123

This is much easier to understand than creating action-based URLs for everything.

50. Putting the Whole Concept Together

Imagine I click:

"Create Post"

The frontend sends:

POST /posts
Content-Type: application/json
Authorization: Bearer token

{
  "content": "Learning Node.js!"
}

The server receives the request.

Request
   ↓
Routing
   ↓
Authentication
   ↓
Validation
   ↓
Business Logic
   ↓
Database
   ↓
Response

The server might respond:

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-cache

{
  "id": 501,
  "content": "Learning Node.js!",
  "authorId": 123
}

Now almost every concept from this blog has appeared:

HTTP
request/response cycle
POST
headers
Content-Type
Authorization
status code
REST resource
database
response body

51. A Simple Mental Model

If I had to remember everything with one diagram:

                 HTTP
                  |
        ┌─────────┴─────────┐
        |                   |
     REQUEST             RESPONSE
        |                   |
   ┌────┴────┐         ┌────┴────┐
   |         |         |         |
 Method    Headers   Status    Headers
   |         |         |         |
  URL       Body      Body      Body
   |
   ├── GET
   ├── POST
   ├── PUT
   ├── PATCH
   └── DELETE

And REST gives us a way to organize the URLs around resources:

/users
/users/123
/posts
/posts/123
/orders
/orders/123

52. Quick Revision Cheat Sheet

Topic	Simple Meaning
HTTP	Rules for client-server communication
Request	Message sent by client
Response	Message sent by server
GET	Read a resource
POST	Create/process something
PUT	Replace a resource representation
PATCH	Partially modify a resource
DELETE	Remove a resource
Idempotent	Repeating the request has the same intended state effect
2xx	Success
3xx	Redirection
4xx	Client-side/request problem
5xx	Server-side problem
Content-Type	Format of the message body
Authorization	Credentials used to authenticate/authorize a request
Cache-Control	Caching instructions
Stateless	Each request carries the context needed to process it
REST	Resource-oriented API design style
Resource	Something represented by the API
Query parameter	Filtering/sorting/pagination/search information

53. Final Takeaway

The biggest thing I learned is that HTTP isn't just:

"GET gets data and POST sends data."

There is a much bigger picture.

A client sends a request.

The request has:

Method
URL
Headers
Body

The server processes it and sends a response containing:

Status Code
Headers
Body

HTTP methods communicate intent:

GET     → read
POST    → create/process
PUT     → replace
PATCH   → partially modify
DELETE  → remove

Status codes communicate the result:

2xx → success
3xx → redirection
4xx → client/request problem
5xx → server problem

Headers provide metadata:

Content-Type
Authorization
Cache-Control

And REST gives us a clean way to organize the API around resources:

/users
/posts
/orders
/products

Once this mental model is clear, frameworks like Express.js and NestJS become much easier to understand.

They aren't replacing HTTP.

They're giving us better tools for building applications that communicate using HTTP.

And that's the real foundation of backend development.

week -7 Task-1 : Node.js Under the Hood: Architecture, Modules, Streams, Buffers & Process

koushikmaya — Thu, 08 Oct 2026 04:45:39 +0000

When I first started learning Node.js, I mostly thought of it as:

"JavaScript running outside the browser."

That is technically true, but it doesn't really explain why Node.js is so useful, especially for backend development.

As I went deeper, I came across things like libuv, the event loop, streams, buffers, the process object, and core modules. At first, these sounded like separate complicated topics.

But they actually fit together pretty well.

This blog is my attempt to understand Node.js as a story rather than a list of definitions.

1. What Actually Happens Inside Node.js?

Let's start with the big picture.

When we run:

node app.js

Node.js doesn't simply take our JavaScript code and execute everything one line at a time.

There are several important pieces working together:

JavaScript Code
      |
      v
   V8 Engine
      |
      v
 Node.js APIs
      |
      v
    libuv
      |
      v
Operating System

The important players are:

V8 → executes JavaScript
Node.js APIs → provide things like fs, http, events, etc.
libuv → handles asynchronous operations and the event loop
Operating System → actually performs many low-level operations

So Node.js is more than just V8.

2. V8: The JavaScript Engine

V8 is the JavaScript engine originally created by Google for Chrome.

Node.js uses V8 to execute JavaScript.

For example:

const name = "Koushik";

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

V8 is responsible for understanding and executing this JavaScript.

But there is a problem.

JavaScript itself doesn't know how to:

read files from your computer
create HTTP servers
communicate with the operating system
work with sockets
access environment variables

That's where Node.js comes in.

Node.js provides additional APIs around V8.

3. So What Is libuv?

This was one of the concepts that confused me initially.

libuv is a library used by Node.js to provide asynchronous I/O and the event loop.

In simple words:

libuv helps Node.js deal with things that may take time without blocking JavaScript execution.

For example:

const fs = require("node:fs");

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

console.log("Finished starting the read");

You might expect:

Read file
Print file
Print "Finished..."

But Node.js can behave more like:

Start reading file
Print "Finished starting the read"
File finishes reading
Print file contents

Why?

Because reading a file can take time.

Instead of making JavaScript sit there doing nothing, Node.js can continue doing other work.

libuv plays a major role in making this possible.

4. The Event Loop

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

A simple way to think about it is:

The event loop keeps checking whether there is work that is ready to be handled.

Imagine a restaurant.

There is one main waiter.

The waiter doesn't stand next to the kitchen waiting for one order to finish.

Instead:

Take an order.
Give it to the kitchen.
Move to another customer.
Come back when the food is ready.
Serve it.

That's roughly the idea behind asynchronous Node.js.

5. Event Loop Phases

The Node.js event loop goes through several phases.

A simplified view looks like this:

┌─────────────────────┐
│       timers        │
├─────────────────────┤
│       pending       │
│       callbacks     │
├─────────────────────┤
│        poll         │
├─────────────────────┤
│        check        │
├─────────────────────┤
│       close         │
│       callbacks     │
└─────────────────────┘
          ↑
          └── repeats

Let's understand them without getting lost in implementation details.

5.1 Timers

This phase handles callbacks from timers such as:

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

and:

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

Important:

setTimeout(..., 1000) does not mean:

"Run this exactly after 1000 milliseconds."

It means approximately:

"Don't run this before the timer is ready, and run it when the event loop gets the opportunity."

5.2 Pending Callbacks

Some callbacks from certain system-level operations can be handled here.

For everyday Node.js development, you usually don't need to manually control this phase.

The important thing is simply knowing that it exists as part of the event loop.

5.3 Poll Phase

The poll phase is where Node.js spends a lot of its time.

It handles I/O-related work such as:

file system operations
network operations
incoming connections
data from sockets

For example, when data arrives from a network connection, Node.js needs a place where that event can be processed.

The poll phase is an important part of that process.

5.4 Check Phase

The check phase is where callbacks scheduled with:

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

are executed.

setImmediate() is specifically associated with the check phase.

5.5 Close Callbacks

When something is closed, Node.js may execute its close callback here.

For example:

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

6. Is Node.js Single-Threaded?

This question causes a lot of confusion.

People often say:

"Node.js is single-threaded."

That's an oversimplification.

Your JavaScript execution normally happens on a main thread.

But Node.js and libuv can use other mechanisms, including a thread pool, for certain operations.

A simplified picture:

             Node.js
                |
       ┌────────┴────────┐
       |                 |
 JavaScript           libuv
 main thread             |
                    ┌────┴────┐
                    | Thread  |
                    |  Pool   |
                    └─────────┘

So the useful takeaway is:

Node.js runs JavaScript primarily on a single main thread, while the runtime can use other threads/system facilities to handle certain operations.

This is one reason Node.js can handle many concurrent I/O operations efficiently.

7. Node.js Core Modules

Node.js comes with many built-in modules.

You don't need to install them using npm.

For example:

const fs = require("node:fs");
const path = require("node:path");
const os = require("node:os");
const events = require("node:events");

Or with modern ESM syntax:

import fs from "node:fs";

The node: prefix clearly tells Node.js that this is a built-in module.

Let's look at some important ones.

8. The `fs` Module

fs stands for File System.

It lets Node.js interact with files and directories.

For example:

const fs = require("node:fs");

const data = fs.readFileSync("data.txt", "utf8");

console.log(data);

Here Node.js reads the file and returns its contents.

You can also use the asynchronous version:

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

  console.log(data);
});

The asynchronous version allows Node.js to continue working while the file operation is being handled.

Common `fs` operations

You will frequently see:

readFile
writeFile
appendFile
mkdir
readdir
rename
unlink
stat

For backend development, fs is useful for things like:

reading configuration files
processing uploaded files
writing logs
reading templates
working with local files

9. The `path` Module

Working with file paths manually can become messy.

For example:

C:\Users\Koushik\project\data.txt

and:

/home/koushik/project/data.txt

Different operating systems use different path conventions.

The path module helps us handle this safely.

Example:

const path = require("node:path");

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

console.log(filePath);

Instead of manually writing:

"data/users/users.json"

we let Node.js construct the path appropriately.

Useful methods include:

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

For example:

path.extname("photo.jpg");

returns:

.jpg

10. The `os` Module

The os module gives information about the operating system.

Example:

const os = require("node:os");

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

This can tell us things such as:

operating system
CPU architecture
CPU information
total memory
available memory

It is especially useful when building system utilities or debugging environments.

11. The `events` Module

Node.js heavily uses an event-driven architecture.

The events module allows us to create and work with event emitters.

Example:

const EventEmitter = require("node:events");

const emitter = new EventEmitter();

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

emitter.emit("login", "Koushik");

Here:

emitter.on(...)

means:

"When this event happens, run this function."

And:

emitter.emit(...)

means:

"This event happened."

This pattern appears throughout Node.js.

12. Streams: Why Do We Need Them?

Now we reach one of my favorite Node.js concepts: streams.

Imagine you have a 5 GB video file.

One approach would be:

Read entire 5 GB
       ↓
Put it into memory
       ↓
Send it somewhere

That's obviously expensive.

A stream takes a different approach:

File
 ↓
Small chunk
 ↓
Small chunk
 ↓
Small chunk
 ↓
Small chunk
 ↓
Destination

Instead of loading everything into memory at once, we process data gradually.

That's the basic idea of a stream.

13. Readable Streams

A Readable stream produces data.

Example:

const fs = require("node:fs");

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

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

The file is read in chunks.

This is useful for:

large files
video streaming
HTTP responses
network data
processing large datasets

14. Writable Streams

A Writable stream receives data.

Example:

const fs = require("node:fs");

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

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

stream.end();

Here we're writing data into the stream.

Think:

Readable → produces
Writable → receives

15. Duplex Streams

A Duplex stream can both read and write.

In simple terms:

       read
        ↑
      Stream
        ↓
       write

A network socket is a common example.

You can receive data from a socket and also send data through the same connection.

16. Transform Streams

A Transform stream takes data, changes it, and passes the result forward.

Think of it like a machine:

Input
  ↓
[ Transform ]
  ↓
Changed Output

For example:

"hello"
   ↓
uppercase transform
   ↓
"HELLO"

Node.js provides Transform streams for this kind of processing.

Transform streams are useful for:

compression
encryption
modifying data
parsing
formatting

17. Piping Streams Together

One of the nicest things about streams is that they can be connected.

For example:

readStream.pipe(writeStream);

Conceptually:

Large File
    ↓
Readable Stream
    ↓
Writable Stream
    ↓
Another File

This lets data flow through the system without requiring the entire file to be loaded into memory.

18. Backpressure

Streams introduce another important concept: backpressure.

Imagine:

Producer
   ↓
████████████████
   ↓
Consumer

What happens if the producer produces data faster than the consumer can process it?

The data can start piling up.

That's backpressure.

A good streaming system needs to slow down the producer when the consumer cannot keep up.

Node.js streams provide mechanisms to handle this.

This becomes especially important when working with:

large files
network connections
uploads/downloads
data processing pipelines

19. Buffers

Now you might wonder:

"If streams process chunks of data, what exactly is a chunk?"

Often, that data is represented using a Buffer.

A Buffer is a Node.js object used to work with raw binary data.

For example:

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

console.log(buffer);

You may see something like:

<Buffer 48 65 6c 6c 6f>

Those values represent the bytes of the string.

20. Why Do We Need Buffers?

JavaScript strings are great for text.

But computers also deal with:

images
videos
audio
PDFs
compressed files
network packets

These aren't simply JavaScript strings.

They are binary data.

Buffers give Node.js a way to work with that binary data efficiently.

For example:

const buffer = Buffer.from([72, 101, 108, 108, 111]);

console.log(buffer.toString());

Output:

Hello

So:

Bytes → Buffer → Text

21. Streams + Buffers

Now the earlier concepts start connecting.

When reading a large file as a stream:

const stream = fs.createReadStream("large-file.mp4");

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

The chunk is commonly a Buffer.

So we can think:

Large File
    ↓
Readable Stream
    ↓
Buffer chunk
    ↓
Buffer chunk
    ↓
Buffer chunk
    ↓
Destination

This is why understanding streams and buffers together is useful.

22. The `process` Object

Another important Node.js concept is the global process object.

It gives us information and control over the currently running Node.js process.

For example:

console.log(process.version);

This tells us the Node.js version.

23. Environment Variables

One of the most common uses of process is environment variables.

For example:

console.log(process.env.PORT);

If we start the application with:

PORT=5000 node app.js

then:

process.env.PORT

contains:

In Windows PowerShell, you may commonly set it like:

$env:PORT=5000
node app.js

Environment variables are commonly used for:

ports
database URLs
API keys
application environment
feature flags

We generally don't want sensitive configuration hard-coded into our source code.

24. Command-Line Arguments

The process object also gives us command-line arguments.

console.log(process.argv);

If we run:

node app.js hello

Node.js gives us information about the command and the argument.

This can be useful when building CLI applications.

25. Exiting the Process

We can also terminate a Node.js process.

For example:

process.exit(1);

The number is an exit code.

Generally:

0 → success
non-zero → something went wrong

You don't normally want to call process.exit() casually in a web server, because abruptly terminating the process can prevent cleanup work from happening.

26. Putting Everything Together

At this point, these concepts might seem like separate topics.

But they actually connect.

Imagine a user uploads a large video to your Node.js application.

The flow could look roughly like this:

             HTTP Request
                  |
                  v
           Node.js Server
                  |
                  v
          Readable Stream
                  |
                  v
              Buffers
                  |
                  v
        Transform / Processing
                  |
                  v
          Writable Stream
                  |
                  v
             File / Storage

Meanwhile:

Node.js
   |
   ├── V8
   |     └── executes JavaScript
   |
   ├── Node APIs
   |     ├── fs
   |     ├── path
   |     ├── os
   |     └── events
   |
   └── libuv
         └── asynchronous I/O + event loop

And the running application can be controlled or configured through:

process
   ├── process.env
   ├── process.argv
   ├── process.version
   └── process.exit()

Suddenly, the pieces start making sense.

27. A Simple Mental Model

If I had to remember everything from this blog using just a few sentences, I'd remember it like this:

V8

Executes my JavaScript.

Node.js APIs

Give JavaScript access to things outside the browser.

libuv

Helps Node.js handle asynchronous I/O and the event loop.

Event Loop

Keeps checking for work that is ready to be handled.

`fs`

Lets me work with files.

`path`

Helps me safely work with file paths.

`os`

Gives me information about the operating system.

`events`

Lets me work with event-driven patterns.

Streams

Let me process data gradually instead of loading everything at once.

Buffers

Let me work with raw binary data.

`process`

Gives me information and control over the running Node.js process.

28. What I Actually Need to Remember as a Backend Developer

I don't need to memorize every event-loop implementation detail.

What matters more is understanding the reasoning behind the architecture.

For example, if I'm building an API and I need to process a 2 GB file, I should immediately think:

"I probably shouldn't load the entire file into memory."

Then streams come to mind.

If I'm handling binary data:

"This isn't just normal text. I probably need Buffers."

If I'm wondering why Node.js can handle many requests without creating a new JavaScript thread for every request:

"The event-driven architecture and asynchronous I/O are important here."

If I need a database URL or port:

"That belongs in configuration/environment variables, accessible through process.env."

That's much more useful than simply memorizing definitions.

29. Final Takeaway

Node.js becomes much easier to understand when you stop seeing its features as isolated topics.

The bigger picture looks like this:

                 Node.js
                    |
        ┌───────────┴───────────┐
        |                       |
       V8                     APIs
        |                       |
 JavaScript             fs / path / os /
 execution                 events / etc.
                                |
                              libuv
                                |
                         ┌──────┴──────┐
                         |             |
                    Event Loop      Async I/O
                         |
                    Callbacks /
                    Promises
                         |
                      Streams
                         |
                      Buffers

The main lesson for me is:

Node.js is not just JavaScript on the server. It's a runtime designed around asynchronous, event-driven I/O.

Once that idea becomes clear, concepts like the event loop, streams, buffers, and core modules stop feeling random.

They are all pieces of the same system.

Quick Revision Cheat Sheet

Concept	Simple Meaning
V8	Executes JavaScript
Node.js	JavaScript runtime outside the browser
libuv	Handles event loop and asynchronous I/O
Event Loop	Coordinates asynchronous work
`fs`	File system operations
`path`	File/directory path handling
`os`	Operating system information
`events`	Event emitter functionality
Readable	Produces data
Writable	Receives data
Duplex	Reads and writes
Transform	Reads, changes, and outputs data
Buffer	Handles binary data
`process`	Information/control for the current Node process
`process.env`	Environment variables
`process.argv`	Command-line arguments

What's Next?

After understanding these Node.js fundamentals, the next step is to connect them to real backend development:

HTTP servers
request/response lifecycle
REST APIs
middleware
Express.js
asynchronous programming
error handling
npm and package management
databases
NestJS

That's where these lower-level Node.js concepts start becoming practical in real applications.

# Week 6 Task 3: Advanced Git Workflows

koushikmaya — Thu, 01 Oct 2026 12:26:16 +0000

Introduction

Git is more than just a tool for saving code. In a team environment, developers need to understand how to manage branches, clean up commit history, move specific changes between branches, temporarily store unfinished work, and safely undo changes.

In this task, I learned:

Merge vs Rebase
Interactive Rebase
Squashing commits
Reordering commits
Editing commits
Resolving Merge Conflicts
Git Stash
Cherry-pick
Git Revert vs Reset

These commands are important when working on feature branches and collaborating through Pull Requests.

1. Merge vs Rebase

Both merge and rebase are used to incorporate changes from one branch into another.

Suppose we have:

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

The feature branch was created from commit B.

Meanwhile, main received commit C.

Now we want the feature branch to contain the latest changes from main.

There are two common approaches:

Merge

or:

Rebase

2. Git Merge

Merge combines two branch histories.

For example:

git switch feature
git merge main

Git may create a merge commit:

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

The merge commit M connects the two histories.

Advantages of Merge

Preserves the original history.
Does not rewrite existing commits.
Safe for branches that are already shared with other developers.
Clearly shows where branches were combined.

Disadvantage

The history can become more complicated, especially when many branches are merged.

3. Git Rebase

Rebase moves your branch's commits so they are based on the latest commit from another branch.

Suppose we start with:

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

Run:

git switch feature
git rebase main

Git effectively replays the feature commits on top of C:

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

The commits are recreated, which is why their commit IDs change.

Why Use Rebase?

Rebase can create a cleaner, more linear history.

Instead of:

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

we get:

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

This can make the project history easier to read.

4. Merge vs Rebase

The main difference is:

Merge	Rebase
Combines histories	Replays commits
Usually creates a merge commit	Usually creates a linear history
Does not rewrite existing commits	Rewrites commit history
Safer for shared branches	Useful for cleaning private branches
Preserves branch structure	Produces cleaner history

A useful rule is:

Do not rebase commits that other developers are already depending on unless the team explicitly agrees.

5. Interactive Rebase

Interactive rebase allows us to modify our recent commit history.

The command is:

git rebase -i HEAD~3

This means:

Open the last three commits for interactive editing.

Git may show something like:

pick abc123 Add login
pick def456 Fix login validation
pick ghi789 Add tests

We can change the commands to modify the history.

Common commands include:

pick    → keep the commit
reword  → change the commit message
edit    → stop and modify the commit
squash  → combine with previous commit
fixup   → combine and discard this commit's message
drop    → remove the commit

6. Squashing Commits

Suppose we have:

A
B Add login
C Fix typo
D Fix another typo
E Add tests

The commits C and D may not be meaningful as separate commits.

We can squash them.

Run:

git rebase -i HEAD~4

Then change:

pick B Add login
pick C Fix typo
pick D Fix another typo
pick E Add tests

to:

pick B Add login
squash C Fix typo
squash D Fix another typo
pick E Add tests

The result is approximately:

A
B Add login
E Add tests

The changes from C and D are combined into B.

Why Squash?

It helps turn messy development history such as:

fix typo
fix again
final fix
actually fix
oops

into meaningful commits such as:

feat: add login
test: add login tests

7. Reordering Commits

Interactive rebase can also reorder commits.

Suppose:

pick A Add feature
pick B Add tests
pick C Fix feature

We can reorder them:

pick A Add feature
pick C Fix feature
pick B Add tests

Git will replay them in that order.

However, changing commit order can cause conflicts if later commits depend on earlier ones.

8. Editing a Commit

Interactive rebase also allows us to stop at a particular commit.

Example:

pick A Add feature
edit B Add configuration
pick C Add tests

Git pauses at commit B.

We can then modify files:

git add .
git commit --amend

After finishing:

git rebase --continue

This is useful when a previous commit needs correction.

9. Important Rebase Commands

During a rebase, useful commands include:

git rebase --continue

Continue after resolving a problem.

git rebase --abort

Cancel the rebase and return to the previous state.

git rebase --skip

Skip the current commit.

10. Resolving Merge Conflicts

A merge conflict happens when Git cannot automatically determine which change should be kept.

For example, two branches modify the same line:

Branch A:

Hello Koushik

Branch B:

Hello Developer

Git doesn't know which version should remain.

It marks the file:

<<<<<<< HEAD
Hello Koushik
=======
Hello Developer
>>>>>>> feature

These markers mean:

<<<<<<< HEAD
Your current branch's version

=======
Other branch's version

>>>>>>> feature

11. How to Resolve a Conflict

First check the conflicted files:

git status

Open the file and decide what the final content should be.

For example, we may choose:

Hello Koushik

Remove the conflict markers.

Then stage the resolved file:

git add filename

If you were doing a merge:

git commit

If you were doing a rebase:

git rebase --continue

12. Abort a Conflict Resolution

If things become confusing, you can cancel the operation.

For a merge:

git merge --abort

For a rebase:

git rebase --abort

This is useful when you want to return to the state before the operation started.

13. Git Stash

Sometimes you have unfinished changes but need to switch branches.

For example:

feature/login

You are currently working on login, but suddenly you need to fix something on another branch.

Your working directory contains:

modified login.ts
modified auth.ts

You don't want to commit incomplete work.

You can use:

git stash

Git temporarily stores the changes and gives you a clean working directory.

14. Applying Stashed Changes

Later, you can restore the changes.

git stash pop

This:

Applies the stashed changes.
Removes the stash from the stash list.

You can see existing stashes using:

git stash list

Example:

stash@{0}: WIP on feature/login
stash@{1}: WIP on feature/profile

15. stash vs stash pop vs stash apply

git stash

Temporarily saves changes:

git stash

git stash apply

Restores the stash but keeps it in the stash list:

git stash apply

git stash pop

Restores the stash and removes it from the stash list:

git stash pop

git stash drop

Deletes a specific stash:

git stash drop stash@{0}

16. Cherry-pick

Cherry-pick is used when we want to take a specific commit from one branch and apply it to another branch.

Suppose:

main:
A---B---C

feature:
A---B---D---E

Suppose commit D contains a useful bug fix.

We can move only D to main:

git switch main
git cherry-pick <commit-id>

The result is:

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

The change from D is copied into a new commit on main.

17. When Cherry-pick Is Useful

Cherry-pick is useful when:

A specific bug fix is needed on another branch.
You don't want to merge the entire feature branch.
You need to move one particular commit.
A fix needs to be applied to a release branch.

Example:

feature branch
     |
     └── fix authentication bug
               ↓
          cherry-pick
               ↓
        release branch

18. Cherry-pick Conflicts

Cherry-picking can also cause conflicts.

If a conflict occurs:

git status

Resolve the conflicting files.

Then:

git add .

Continue:

git cherry-pick --continue

To cancel:

git cherry-pick --abort

19. Git Revert

git revert creates a new commit that reverses the changes introduced by an earlier commit.

Suppose:

A---B---C

Commit C introduced a bug.

Instead of deleting C from history, we can run:

git revert C

Git creates a new commit:

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

C' reverses the changes introduced by C.

Why Revert Is Useful

Revert is particularly useful for shared branches such as main because it preserves the existing history.

20. Git Reset

git reset moves the current branch pointer to another commit.

Suppose:

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

We can run:

git reset --hard B

The branch moves back:

A---B

Commits C and D are no longer part of the current branch history.

This is why reset must be used carefully.

21. Types of Git Reset

There are three important reset modes.

--soft

git reset --soft HEAD~1

Moves the branch pointer but keeps the changes staged.

Useful when you want to redo a commit.

--mixed

git reset --mixed HEAD~1

Moves the branch pointer and unstages the changes, but keeps the files modified.

This is the default reset mode.

--hard

git reset --hard HEAD~1

Moves the branch pointer and discards changes from the working tree and staging area.

This can permanently remove work, so use it carefully.

22. Revert vs Reset

This is one of the most important differences.

Revert	Reset
Creates a new commit	Moves branch pointer
Preserves history	Can remove commits from branch history
Safer for shared branches	Risky on shared branches
Good for undoing published changes	Often used for local history cleanup

Simple rule:

Shared / pushed history
        ↓
      revert

Private / local history
        ↓
       reset

23. Merge vs Rebase vs Cherry-pick

These commands solve different problems.

Merge

Combine two branch histories.

git merge main

Rebase

Replay my commits on top of another branch.

git rebase main

Cherry-pick

Take one specific commit and apply it here.

git cherry-pick <commit-id>

Think of them like this:

Merge
 ↓
Bring the whole branch history together

Rebase
 ↓
Move/replay my branch commits

Cherry-pick
 ↓
Take only a specific commit

24. Practical Example

Imagine working on a login feature.

You create:

git switch -c feature/login

You make several commits:

feat: add login
fix: typo
fix: validation
test: add login tests

Before opening a PR, you decide to clean the history.

You use:

git rebase -i HEAD~4

Then squash the small fix commits.

Your history becomes:

feat: add login
test: add login tests

While rebasing, you encounter a conflict.

You:

git status

Fix the file, then:

git add .
git rebase --continue

Later, you realize another branch contains a useful standalone bug fix.

Instead of merging the entire branch:

git cherry-pick <commit-id>

Finally, if a bad commit has already been pushed to the shared branch, you can safely undo it with:

git revert <commit-id>

This is how these commands work together in a real workflow.

25. Command Cheat Sheet

Task	Command
Merge branch	`git merge branch-name`
Rebase	`git rebase branch-name`
Interactive rebase	`git rebase -i HEAD~N`
Continue rebase	`git rebase --continue`
Abort rebase	`git rebase --abort`
Stash changes	`git stash`
List stashes	`git stash list`
Apply stash	`git stash apply`
Apply and remove stash	`git stash pop`
Cherry-pick commit	`git cherry-pick <commit>`
Revert commit	`git revert <commit>`
Soft reset	`git reset --soft HEAD~1`
Mixed reset	`git reset --mixed HEAD~1`
Hard reset	`git reset --hard HEAD~1`
Check status	`git status`

26. Important Safety Rules

Some Git commands can rewrite history or discard work.

Be especially careful with:

git reset --hard

and:

git rebase

when working with shared branches.

A good general rule is:

Clean up your own private history, but avoid rewriting history that other developers are already using.

If a branch has already been pushed and shared, coordinate with the team before rewriting its history.

27. What I Learned

The main lesson from this task is that Git provides different tools for different situations.

Merge
  ↓
Combine branches

Rebase
  ↓
Create a cleaner linear history

Interactive Rebase
  ↓
Clean and edit commits

Conflict Resolution
  ↓
Manually choose the correct final version

Stash
  ↓
Temporarily save unfinished work

Cherry-pick
  ↓
Move one specific commit

Revert
  ↓
Safely undo a published commit

Reset
  ↓
Move local history backward

Understanding these commands makes it much easier to work confidently with feature branches and Pull Requests.

Conclusion

Advanced Git workflows are important for maintaining a clean and reliable project history.

Merge is useful for combining branch histories, while rebase can create a cleaner linear history. Interactive rebase allows developers to squash, reorder, edit, or remove commits before sharing them.

Merge conflicts are a normal part of collaborative development and can be resolved by manually choosing the correct final version.

Git stash provides a way to temporarily save unfinished work, while cherry-pick allows a specific commit to be applied to another branch.

Finally, understanding the difference between revert and reset is essential. Revert creates a new commit that undoes previous changes, while reset moves the branch pointer and can rewrite local history.

The most important thing is not memorizing every command. It is understanding which Git tool solves which problem and when it is safe to use it.

# Week 6 Task 2: TypeScript, Jest, Git Workflow & Code Review

koushikmaya — Thu, 01 Oct 2026 10:29:37 +0000

Introduction

As JavaScript applications become larger, maintaining type safety, writing reliable tests, and collaborating with other developers becomes increasingly important.

In this task, I learned several practical concepts commonly used in real-world TypeScript projects:

TypeScript basic types
Interfaces
Generics
Jest fundamentals
Mocks
Git feature branches
Pull Requests
Code review etiquette

These concepts work together as part of a professional development workflow.

1. TypeScript Basic Types

TypeScript is a superset of JavaScript that adds static typing.

JavaScript allows a variable to change its type:

let age = 20;
age = "hello";

In TypeScript, we can specify the expected type:

let age: number = 20;

age = "hello"; // Error

The TypeScript compiler catches this problem before the program runs.

Common Types

String

let name: string = "Koushik";

Number

let age: number = 20;
let price: number = 99.99;

Boolean

let isLoggedIn: boolean = true;

Arrays

let names: string[] = ["Koushik", "Rahul", "John"];
let marks: number[] = [80, 90, 75];

Tuple

A tuple represents an array with a fixed structure:

let user: [string, number] = ["Koushik", 20];

The first value must be a string and the second must be a number.

Union Types

A union allows multiple possible types:

let id: string | number;

id = 10;
id = "abc123";

Literal Types

Literal types restrict a value to specific options:

let status: "pending" | "success" | "failed";

Any

any disables most TypeScript type checking:

let data: any = "hello";

data = 100;
data = true;

Using any everywhere defeats much of the purpose of TypeScript.

Unknown

unknown is safer than any:

let data: unknown = "hello";

if (typeof data === "string") {
  console.log(data.toUpperCase());
}

2. Type Inference

TypeScript can automatically determine a variable's type.

let name = "Koushik";

TypeScript understands:

name → string

Therefore, we don't always need to explicitly write the type.

Instead of:

let age: number = 20;

we can often write:

let age = 20;

This is called type inference.

3. Interfaces

An interface defines the expected structure of an object.

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

We can then create:

const user: User = {
  id: 1,
  name: "Koushik",
  email: "koushik@example.com"
};

The interface acts like a contract. Objects using the interface must follow its structure.

Optional Properties

Use ? for optional properties:

interface User {
  id: number;
  name: string;
  email?: string;
}

Now this is valid:

const user: User = {
  id: 1,
  name: "Koushik"
};

Readonly Properties

interface User {
  readonly id: number;
  name: string;
}

Now the name can change, but the ID cannot:

user.name = "Rahul"; // Allowed
user.id = 10;        // Error

4. Generics

Generics allow us to write reusable and type-safe code.

Without generics:

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

function identityNumber(value: number): number {
  return value;
}

This duplicates the same logic.

With generics:

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

T is a type placeholder.

identity<string>("Koushik");
identity<number>(20);

TypeScript can also infer the type:

identity("Koushik");
identity(20);

5. Generic Functions

Generics are useful for reusable functions.

function getFirst<T>(items: T[]): T {
  return items[0];
}

It works with numbers:

const number = getFirst([10, 20, 30]);

And strings:

const name = getFirst(["A", "B", "C"]);

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

6. Generic Interfaces

Generics can also be used with interfaces:

interface ApiResponse<T> {
  data: T;
  success: boolean;
}

For example:

interface User {
  id: number;
  name: string;
}

const response: ApiResponse<User> = {
  data: {
    id: 1,
    name: "Koushik"
  },
  success: true
};

Here:

T = User

The same ApiResponse<T> can be reused with other types.

7. Jest Fundamentals

Jest is a JavaScript and TypeScript testing framework.

Suppose we have:

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

We can test it:

describe("add function", () => {
  it("should add two numbers", () => {
    expect(add(2, 3)).toBe(5);
  });
});

8. describe()

describe() groups related tests.

describe("add function", () => {

});

It means that the tests inside the block are related to the add function.

9. it()

it() defines an individual test:

it("should add two numbers", () => {

});

The first argument describes what the test should verify.

10. expect()

expect() verifies the result:

expect(add(2, 3)).toBe(5);

The test checks whether the actual result matches the expected result.

11. Common Jest Matchers

toBe()

expect(2 + 3).toBe(5);

toEqual()

Useful for objects and arrays:

expect({
  name: "Koushik"
}).toEqual({
  name: "Koushik"
});

toContain()

expect(["A", "B", "C"]).toContain("B");

toThrow()

expect(() => {
  throw new Error("Something went wrong");
}).toThrow();

12. Arrange, Act, Assert

A common structure for tests is:

Arrange
   ↓
Act
   ↓
Assert

Example:

it("should add two numbers", () => {
  // Arrange
  const a = 10;
  const b = 20;

  // Act
  const result = add(a, b);

  // Assert
  expect(result).toBe(30);
});

Arrange — prepare the data.
Act — execute the code.
Assert — verify the result.

13. Jest Mocks

Sometimes code depends on external systems:

Service
   ↓
Repository
   ↓
Database

When unit testing the service, we don't necessarily want a real database.

Instead, we can create a mock:

const repository = {
  findById: jest.fn()
};

jest.fn() creates a mock function.

We can specify its return value:

repository.findById.mockReturnValue({
  id: 1,
  name: "Koushik"
});

We can also verify calls:

expect(repository.findById).toHaveBeenCalled();

Or verify arguments:

expect(repository.findById).toHaveBeenCalledWith(1);

Mocks make unit tests faster, more predictable, and independent of external systems.

14. Git Feature Branches

Git helps developers collaborate safely.

Instead of making every change directly on main, developers create feature branches:

main
 |
 ├── feature/login
 ├── feature/signup
 └── feature/profile

Each feature can be developed independently.

15. Creating a Feature Branch

First update main:

git switch main
git pull origin main

Create a feature branch:

git switch -c feature/login

Now changes can be made without directly modifying main.

16. Committing Changes

Check changed files:

git status

Stage them:

git add .

Create a commit:

git commit -m "feat: add login functionality"

A commit is a logical checkpoint in the project's history.

17. Pushing the Branch

Push the branch to GitHub:

git push -u origin feature/login

Now the branch exists locally and on GitHub.

18. Pull Requests

After completing the feature, create a Pull Request.

A PR means:

"I have completed this change. Please review it before it becomes part of the main codebase."

Typical workflow:

Create branch
      ↓
Write code
      ↓
Run tests
      ↓
Commit
      ↓
Push
      ↓
Create PR
      ↓
Code review
      ↓
Fix feedback
      ↓
Approval
      ↓
Merge

19. Why Pull Requests Matter

PRs provide a checkpoint before code reaches the main branch.

They allow a team to:

Review implementation
Find bugs
Discuss design decisions
Check tests
Improve code quality
Maintain project standards

20. Code Review Etiquette

Code review should be treated as collaboration.

The purpose is not to criticize the developer. The purpose is to improve the code.

Review the Code, Not the Person

Instead of:

"You don't know TypeScript."

A better comment is:

"Could we define an interface here so the expected object structure is explicit?"

Focus on the code, not the person.

Explain Why

Instead of:

"Change this."

Explain the reason:

"Could we extract this logic into a helper? It is repeated in multiple places, so extraction would make future changes easier."

Ask Questions

Instead of:

"Use an interface."

A more collaborative comment is:

"Would an interface make the expected structure clearer here?"

Avoid Unnecessary Nitpicking

Not every difference needs to be a blocking comment.

Reviews should focus on:

Correctness
Security
Architecture
Maintainability
Performance
Tests
Type safety
Project conventions

21. Blocking Issues vs Suggestions

It is useful to distinguish between required fixes and optional improvements.

Blocking comment

"This allows duplicate records. Can we enforce uniqueness at the database level?"

Suggestion

"Optional: this helper could be extracted to make the function easier to read."

This helps the author understand which changes are required before merging.

22. Review Tests Too

Code review should cover tests as well as production code.

A reviewer should ask:

Does the test actually verify the behavior?
Are important edge cases covered?
Are mocks being used correctly?
Is the test unnecessarily dependent on external systems?
Are failure cases tested?

Having many tests doesn't automatically mean the code is well tested. The tests need to verify meaningful behavior.

23. Putting Everything Together

These concepts form one practical development workflow.

Imagine building a notification system.

TypeScript defines the structure:

interface Notification {
  recipient: string;
  message: string;
}

Generics can create reusable components:

function wrap<T>(data: T) {
  return {
    data,
    success: true
  };
}

Jest tests the implementation:

describe("Notification", () => {
  it("should create a notification", () => {
    // test
  });
});

Mocks replace external services:

const emailService = {
  send: jest.fn()
};

Git provides the development workflow:

feature/notification-system
          ↓
        Coding
          ↓
        Testing
          ↓
        Commit
          ↓
         Push
          ↓
          PR
          ↓
     Code Review
          ↓
       Feedback
          ↓
        Merge

24. What I Learned

Professional development isn't only about writing code.

It involves several connected practices:

TypeScript
   ↓
Type-safe code

Interfaces
   ↓
Clear contracts

Generics
   ↓
Reusable type-safe code

Jest
   ↓
Automated testing

Mocks
   ↓
Isolated unit tests

Git branches
   ↓
Safe development

Pull Requests
   ↓
Team collaboration

Code Review
   ↓
Better code quality

Understanding these concepts provides a strong foundation for larger TypeScript and Node.js applications.

Conclusion

TypeScript provides type safety and helps catch many errors before runtime. Interfaces allow developers to define clear contracts, while generics make code reusable without sacrificing type safety.

Jest provides automated testing, and mocks allow individual components to be tested without depending on external systems.

Git feature branches and Pull Requests provide a structured way for developers to collaborate, while code reviews help catch problems and improve maintainability.

Together, these practices form an important part of a professional software development workflow.

The main lesson is that writing code is only one part of software engineering. Writing maintainable code, testing it, collaborating through Git, and reviewing each other's work are equally important.

Command Pattern in JavaScript

koushikmaya — Tue, 29 Sep 2026 07:04:57 +0000

Introduction

In Week 06 Task 01, I continued learning Design Patterns in JavaScript.

For this task, I implemented the Command Pattern by building a simple text editor with support for editing operations and undo functionality.

The main goal was to understand how commands can encapsulate actions as objects and how this makes operations easier to manage, execute, and reverse.

I also wrote tests using Node.js's built-in assert module.

What is the Command Pattern?

The Command Pattern turns a request or action into a separate object.

Instead of directly calling a method to perform an operation, we create a command object that knows:

What action should be performed
How to perform it
How to undo it

A simple structure looks like:

User
  |
  ↓
Invoker
  |
  ↓
Command
  |
  ↓
Receiver

For this task:

EditorInvoker
      |
      ↓
AppendCommand / DeleteCommand
      |
      ↓
TextEditor

The TextEditor performs the actual work, while the command objects describe what operation should happen.

Components of My Implementation

I used four main components:

TextEditor — Receiver
AppendCommand — Command
DeleteCommand — Command
EditorInvoker — Invoker

1. TextEditor — Receiver

The receiver is the object that actually performs the operation.

In my implementation, TextEditor is the receiver.

It manages the text and provides operations such as:

Append text
Delete text
Get current text

A simplified example:

class TextEditor {
  constructor() {
    this.text = "";
  }

  append(value) {
    this.text += value;
  }

  delete(count) {
    this.text = this.text.slice(0, -count);
  }

  getText() {
    return this.text;
  }
}

The important idea is that the receiver does the actual work.

2. AppendCommand

The AppendCommand represents the action of adding text.

It stores the text that needs to be appended and knows how to execute and undo that operation.

class AppendCommand {
  constructor(editor, text) {
    this.editor = editor;
    this.text = text;
  }

  execute() {
    this.editor.append(this.text);
  }

  undo() {
    this.editor.delete(this.text.length);
  }
}

When execute() is called, the text is added.

When undo() is called, the same text is removed.

For example:

Before:
Hello

Append " World"

After:
Hello World

Undo:

Hello

3. DeleteCommand

The DeleteCommand represents a delete operation.

It removes characters from the editor and stores enough information to restore them.

class DeleteCommand {
  constructor(editor, count) {
    this.editor = editor;
    this.count = count;
    this.deletedText = "";
  }

  execute() {
    this.deletedText =
      this.editor.getText().slice(-this.count);

    this.editor.delete(this.count);
  }

  undo() {
    this.editor.append(this.deletedText);
  }
}

The important part is that the command remembers what was deleted.

That information is needed when the command is undone.

4. EditorInvoker

The invoker is responsible for executing commands and keeping track of command history.

class EditorInvoker {
  constructor() {
    this.history = [];
  }

  execute(command) {
    command.execute();
    this.history.push(command);
  }

  undo() {
    const command = this.history.pop();

    if (command) {
      command.undo();
    }
  }
}

The invoker doesn't need to know how each command works.

It simply tells the command:

command.execute();

or:

command.undo();

This keeps the invoker separate from the actual editing logic.

How the Complete Flow Works

Suppose we want to append "Hello".

First, we create the command:

const command =
  new AppendCommand(editor, "Hello");

Then the invoker executes it:

invoker.execute(command);

The flow is:

invoker.execute()
       |
       ↓
AppendCommand.execute()
       |
       ↓
TextEditor.append()
       |
       ↓
"Hello"

The command is then stored in the history.

Undo Flow

When we call:

invoker.undo();

the most recent command is removed from history and its undo() method is called.

invoker.undo()
      |
      ↓
Get last command
      |
      ↓
command.undo()
      |
      ↓
Reverse previous operation

This provides a simple undo system.

Why Keep Command History?

Command history is important because it allows us to reverse operations in reverse order.

For example:

1. Append "Hello"
2. Append " World"
3. Delete 6 characters

History:

[Append, Append, Delete]

If we call undo:

Delete → undone

Then:

Append " World" → undone

Then:

Append "Hello" → undone

This is called Last-In, First-Out (LIFO) behavior.

The most recent command is undone first.

Example

A simple usage could look like:

const editor = new TextEditor();
const invoker = new EditorInvoker();

invoker.execute(
  new AppendCommand(editor, "Hello")
);

invoker.execute(
  new AppendCommand(editor, " World")
);

console.log(editor.getText());

Output:

Hello World

Now undo the last operation:

invoker.undo();

console.log(editor.getText());

Output:

Hello

Testing

I used Node.js's built-in assert module to test the Command Pattern.

The tests covered:

Appending text
Deleting text
Undoing append operations
Undoing delete operations
Multiple commands
Undoing commands in the correct order
Calling undo when there is no command history

Example:

assert.strictEqual(
  editor.getText(),
  "Hello World"
);

invoker.undo();

assert.strictEqual(
  editor.getText(),
  "Hello"
);

These tests helped verify that commands were being executed and reversed correctly.

Real-World Examples

The Command Pattern is commonly useful when actions need to be stored, queued, logged, or undone.

Examples include:

Text Editors

Type → Delete → Undo → Redo

GUI Applications

Click → Execute Command

Transaction Systems

Create → Update → Delete

Task Queues

Command 1
Command 2
Command 3

Commands can be executed later by a worker.

Benefits of the Command Pattern

The Command Pattern provides several advantages:

1. Separation of Responsibilities

The receiver performs the actual work, while commands represent actions.

2. Undo Support

Commands can store the information required to reverse operations.

3. History

Executed commands can be stored and managed.

4. Extensibility

New commands can be added without heavily modifying existing code.

5. Queuing

Commands can be stored and executed later.

What I Learned

This task helped me understand how an operation can be represented as an object.

The most important idea I learned is:

Action → Command Object → Execute
                       → Undo

Instead of directly modifying the editor, I can create commands that describe what should happen.

I also learned how command history can be used to implement undo functionality.

Key Takeaways

The main concepts I learned from this task are:

Command   → Encapsulates an action

Receiver  → Performs the actual operation

Invoker   → Executes and manages commands

History   → Stores executed commands

Undo      → Reverses the most recent command

The Command Pattern is especially useful when operations need to be undoable, queued, logged, or controlled independently.

Conclusion

Week 06 Task 01 gave me practical experience with the Command Pattern in JavaScript.

I built a simple text editor where editing operations were represented as command objects. I also implemented command history and undo functionality.

This task helped me understand how separating the command, invoker, and receiver can make an application more modular and easier to extend.

Overall, Week 06 helped me move beyond simply writing JavaScript code and understand how design patterns can be used to structure real applications.

Strategy and Adapter Patterns in JavaScript

koushikmaya — Tue, 29 Sep 2026 07:01:33 +0000

Introduction

In Week 06 Task 01, I continued learning Design Patterns in JavaScript.

For this task, I implemented two important design patterns:

Strategy Pattern
Adapter Pattern

The goal was to understand how design patterns can help make code more flexible, reusable, and easier to maintain.

I also created tests using Node.js's built-in assert module to verify that the implementations worked correctly.

1. Strategy Pattern

What is the Strategy Pattern?

The Strategy Pattern allows us to define multiple ways of performing an operation and choose between them at runtime.

Instead of putting all the logic inside one large if-else or switch statement, we create separate strategies.

For example, an online shopping application may have different discount rules:

                Checkout
                   |
          Select Discount Strategy
                   |
        ┌──────────┼──────────┐
        ↓          ↓          ↓
   No Discount  Percentage   Flat

Each strategy handles its own discount calculation.

My Implementation

I created three discount strategies:

NoDiscount
PercentageDiscount
FlatDiscount

No Discount

class NoDiscount {
  apply(price) {
    return price;
  }
}

This strategy returns the original price.

Percentage Discount

class PercentageDiscount {
  constructor(percent) {
    this.percent = percent;
  }

  apply(price) {
    return price - (price * this.percent) / 100;
  }
}

For example, a 10% discount on ₹1000 gives:

₹1000 - ₹100 = ₹900

Flat Discount

class FlatDiscount {
  constructor(amount) {
    this.amount = amount;
  }

  apply(price) {
    return Math.max(0, price - this.amount);
  }
}

For example, a ₹200 discount on ₹1000 gives:

₹1000 - ₹200 = ₹800

Checkout Context

I created a Checkout class that uses a discount strategy.

class Checkout {
  constructor(discountStrategy) {
    this.discountStrategy = discountStrategy;
  }

  setDiscountStrategy(strategy) {
    this.discountStrategy = strategy;
  }

  getFinalPrice(price) {
    return this.discountStrategy.apply(price);
  }
}

Now the discount strategy can be changed without changing the Checkout class.

Example

const checkout = new Checkout(
  new PercentageDiscount(10)
);

console.log(checkout.getFinalPrice(1000));

Output:

We can also change the strategy:

checkout.setDiscountStrategy(
  new FlatDiscount(200)
);

console.log(checkout.getFinalPrice(1000));

Output:

Why is the Strategy Pattern Useful?

Without the Strategy Pattern, we might write something like:

if (type === "percentage") {
  // percentage logic
} else if (type === "flat") {
  // flat discount logic
} else {
  // no discount logic
}

As more discount types are added, this code becomes harder to maintain.

With the Strategy Pattern, each discount algorithm has its own class.

This provides:

Better separation of responsibilities
Easier testing
Easier extension
Less conditional logic
Runtime strategy selection

2. Adapter Pattern

What is the Adapter Pattern?

The Adapter Pattern allows two incompatible interfaces to work together.

A simple real-world example is a travel plug adapter.

Device Plug
     ↓
   Adapter
     ↓
Wall Socket

The device and socket may use different interfaces, but the adapter allows them to communicate.

The same idea can be used in software.

The Problem

Suppose our application expects a payment gateway with this method:

pay(amount)

But an old payment system provides:

makePayment(amountInCents)

The interfaces are different.

Instead of changing the entire application or rewriting the old gateway, we can create an adapter.

Application
     |
     ↓
Payment Adapter
     |
     ↓
Legacy Payment Gateway

My Implementation

I created a legacy payment gateway:

class LegacyPaymentGateway {
  makePayment(amountInCents) {
    return {
      success: true,
      amountInCents
    };
  }
}

The application expects a simpler pay() method.

So I created a PaymentAdapter:

class PaymentAdapter {
  constructor(legacyGateway) {
    this.legacyGateway = legacyGateway;
  }

  pay(amount) {
    return this.legacyGateway.makePayment(amount * 100);
  }
}

The adapter converts the application's expected input into the format required by the legacy gateway.

Example

const legacyGateway = new LegacyPaymentGateway();

const paymentAdapter =
  new PaymentAdapter(legacyGateway);

console.log(paymentAdapter.pay(10));

The application provides:

The adapter converts it to:

1000 cents

and calls:

makePayment(1000)

The application does not need to know about the legacy gateway's interface.

Checkout Payment Service

I also created a service that works with the expected payment interface.

class CheckoutPaymentService {
  constructor(paymentGateway) {
    this.paymentGateway = paymentGateway;
  }

  checkout(amount) {
    return this.paymentGateway.pay(amount);
  }
}

Now the service can work with the adapter:

const service = new CheckoutPaymentService(
  paymentAdapter
);

console.log(service.checkout(50));

The flow becomes:

CheckoutPaymentService
          |
          ↓
   PaymentAdapter
          |
          ↓
LegacyPaymentGateway

Strategy vs Adapter

Although both patterns help organize code, they solve different problems.

Pattern	Main Purpose
Strategy	Choose between different algorithms or behaviors
Adapter	Make incompatible interfaces work together

Strategy

Same problem
     ↓
Different algorithms
     ↓
Choose one at runtime

Example:

Discount
 ├── No Discount
 ├── Percentage
 └── Flat

Adapter

Different interfaces
       ↓
     Adapter
       ↓
Compatible interface

Example:

Application
    ↓
PaymentAdapter
    ↓
Legacy Gateway

Testing

I used Node.js's built-in assert module to test both patterns.

Strategy Pattern Tests

I tested:

No discount
Percentage discount
Flat discount
Changing strategies
Final price calculation

Example:

assert.strictEqual(
  checkout.getFinalPrice(1000),
  900
);

Adapter Pattern Tests

I tested:

The adapter correctly calls the legacy gateway.
The amount is converted correctly.
The checkout service can use the adapted gateway.

Example:

assert.deepStrictEqual(
  service.checkout(10),
  {
    success: true,
    amountInCents: 1000
  }
);

What I Learned

Strategy Pattern

I learned that the Strategy Pattern allows us to separate different algorithms into individual classes and choose the required behavior at runtime.

Instead of modifying one large class whenever a new algorithm is added, we can create a new strategy.

Adapter Pattern

I learned that the Adapter Pattern is useful when we need to integrate existing code with a new system that expects a different interface.

Instead of changing the existing implementation, we can place an adapter between the two systems.

Key Takeaways

The main concepts I learned from this task are:

Strategy → Choose between different behaviors

Adapter  → Convert one interface into another

Strategy

Focuses on:

Behavior
Algorithms
Runtime selection
Flexibility

Adapter

Focuses on:

Compatibility
Interface conversion
Legacy systems
Integration

Conclusion

Week 06 Task 01
helped me understand two more important JavaScript design patterns: Strategy and Adapter.

The Strategy Pattern showed me how to make behavior interchangeable, while the Adapter Pattern showed me how to make incompatible interfaces work together.

Implementing both patterns and writing tests helped me understand not only what these patterns are, but also when and why they should be used.

These concepts are useful when building larger applications because they help keep code modular, flexible, and easier to maintain.

# Week 06 Task 01: Design Patterns in JavaScript

koushikmaya — Tue, 29 Sep 2026 06:59:10 +0000

Introduction

This week, I learned how Design Patterns can help organize JavaScript applications and make code easier to maintain, reuse, and extend.

For Task 01, I implemented three commonly used design patterns:

Observer Pattern
Singleton Pattern
Factory Pattern

Instead of only learning the theory, I implemented each pattern using a small practical example and tested the implementations using Node.js's built-in assert module.

What Are Design Patterns?

Design patterns are reusable solutions to common software design problems.

They are not ready-made code that we copy into every project. Instead, they provide a proven structure for solving certain types of problems.

For example:

Need one object to notify multiple objects? → Observer
Need only one shared instance of something? → Singleton
Need to create different types of objects without exposing the creation logic? → Factory

1. Observer Pattern

What is the Observer Pattern?

The Observer Pattern is useful when one object needs to notify multiple other objects whenever something happens.

A simple real-world example is YouTube subscriptions.

When a channel uploads a new video:

YouTube Channel
      |
      | notification
      ↓
Subscribers
   ↓    ↓    ↓
User1 User2 User3

The channel doesn't need to manually manage what every subscriber does. It simply sends an event, and the subscribers respond.

My Implementation

I created a small event emitter:

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

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

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

  off(event, listener) {
    if (!this.events[event]) return;

    this.events[event] = this.events[event].filter(
      (item) => item !== listener
    );
  }

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

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

  once(event, listener) {
    const wrapper = (data) => {
      listener(data);
      this.off(event, wrapper);
    };

    this.on(event, wrapper);
  }
}

The class supports:

on() → subscribe to an event
off() → unsubscribe
emit() → trigger an event
once() → execute a listener only once

Example

const emitter = new MiniEventEmitter();

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

emitter.emit("login", "Koushik");

Output:

Koushik logged in

Why is this useful?

This pattern is useful when different parts of an application need to react to the same event.

Examples include:

Notifications
UI events
Logging
Message systems
Real-time applications

2. Singleton Pattern

What is the Singleton Pattern?

The Singleton Pattern ensures that a class has only one instance throughout the application.

For example, an application configuration manager usually doesn't need multiple instances.

Instead of:

Config 1
Config 2
Config 3

we want:

        Config
          ↑
     ┌────┼────┐
     ↓    ↓    ↓
   App  Service API

Everyone uses the same configuration object.

My Implementation

I created a singleton configuration manager:

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

    this.config = {};

    ConfigManager.instance = this;
  }

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

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

module.exports = new ConfigManager();

Now whenever the module is imported, the same instance is reused.

Example

const config = require("./singleton-config");

config.set("environment", "development");

console.log(config.get("environment"));

Output:

development

Why is this useful?

Singletons can be useful for shared resources such as:

Configuration
Logging
Application state
Connection managers
Caches

However, Singleton should not be used everywhere because excessive global shared state can make applications harder to test and maintain.

3. Factory Pattern

What is the Factory Pattern?

The Factory Pattern is used when we want to create different types of objects without putting the object creation logic everywhere in the application.

For example, imagine a notification system.

We may have:

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

The application only needs to tell the factory which notification it wants.

My Implementation

I created notification classes:

class EmailNotification {
  send(message) {
    return `Email: ${message}`;
  }
}

class SMSNotification {
  send(message) {
    return `SMS: ${message}`;
  }
}

class PushNotification {
  send(message) {
    return `Push: ${message}`;
  }
}

Then I created a factory:

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 do:

const notification =
  NotificationFactory.create("email");

console.log(notification.send("Hello!"));

Output:

Email: Hello!

The calling code doesn't need to know how the EmailNotification object is created.

Testing

For testing, I used Node.js's built-in assert module.

Example:

const assert = require("assert");

assert.strictEqual(
  notification.send("Hello!"),
  "Email: Hello!"
);

I tested the important behaviors of each pattern.

Observer tests

I verified:

Listeners can subscribe.
Events are emitted correctly.
Listeners can unsubscribe.
once() listeners execute only once.

Singleton tests

I verified that:

const config1 = require("./singleton-config");
const config2 = require("./singleton-config");

refer to the same instance.

Factory tests

I verified that the factory creates the correct notification type and rejects unsupported types.

Project Structure

The final Task 01 structure was:

week-06/
└── Task-01/
    ├── README.md
    ├── mini-event-emitter.js
    ├── singleton-config.js
    ├── notification-factory.js
    └── test.js

Each file had a specific responsibility:

File	Purpose
`mini-event-emitter.js`	Observer Pattern
`singleton-config.js`	Singleton Pattern
`notification-factory.js`	Factory Pattern
`test.js`	Tests
`README.md`	Documentation

What I Learned

This task helped me understand that design patterns are mainly about structuring code to solve recurring problems.

Observer

I learned how objects can communicate through events without being tightly coupled.

Singleton

I learned how to maintain one shared instance when multiple parts of an application need the same resource.

Factory

I learned how to separate object creation from the code that uses those objects.

Key Takeaways

The main concepts I learned from this task are:

Observer  →  Event-based communication

Singleton →  One shared instance

Factory   →  Centralized object creation

These patterns are especially useful when applications become larger and different parts of the system need clear responsibilities.

Conclusion

Week 06 Task 01 gave me practical experience with three important JavaScript design patterns: Observer, Singleton, and Factory.

Instead of just reading about these patterns, I implemented each one from scratch and wrote tests to verify their behavior.

This exercise helped me understand how design patterns can improve code organization, reusability, maintainability, and separation of responsibilities.

I’ll be building on these concepts in the next tasks by exploring more design patterns and applying them to practical problems.

# Understanding Async/Await, Promise Combinators, and Concurrency Limiting in JavaScript

koushikmaya — Thu, 24 Sep 2026 09:22:16 +0000

Asynchronous programming is one of the most important concepts in JavaScript, especially when working with APIs, databases, file operations, and network requests.

In this blog, I will explain three important concepts:

Async/Await
Promise Combinators
Concurrency Limiting

As part of my Week 05 Task 02, I also implemented custom versions of Promise.all(), Promise.race(), and Promise.allSettled(), along with a concurrency-limited task runner.

1. What is Asynchronous JavaScript?

JavaScript normally executes code from top to bottom:

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

Output:

Start
Middle
End

But some operations take time, such as:

API requests
Database queries
Reading files
Timers
Network requests

JavaScript uses Promises to represent the future result of these operations.

const promise = fetch("https://example.com");

The request does not immediately give us the final response. Instead, it gives us a Promise that will eventually be fulfilled or rejected.

2. Promises

A Promise can be in one of three states:

Pending
   ↓
Fulfilled

or:

Pending
   ↓
Rejected

For example:

const promise = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("Data received");
  }, 1000);
});

Initially the Promise is pending.

After one second, it becomes fulfilled with:

Data received

We can consume it using .then():

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

3. Async/Await

async and await provide a cleaner way to work with Promises.

Instead of:

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

We can write:

async function getData() {
  try {
    const data = await fetchData();
    console.log(data);
  } catch (error) {
    console.error(error);
  }
}

The important thing to understand is that await does not block the entire JavaScript program.

It pauses the execution of the current async function until the Promise settles, while JavaScript can continue handling other work.

4. Sequential vs Parallel Async Operations

Consider three API requests:

const user = await getUser();
const posts = await getPosts();
const likes = await getLikes();

These operations run sequentially.

If each takes one second, the total time can be approximately:

1 second + 1 second + 1 second = 3 seconds

If the operations are independent, we can run them concurrently:

const [user, posts, likes] = await Promise.all([
  getUser(),
  getPosts(),
  getLikes(),
]);

The total time can be closer to:

max(1s, 1s, 1s) = 1 second

This is one of the main reasons Promise combinators are useful.

5. Promise Combinators

JavaScript provides several useful Promise combinators.

The three implemented in this task are:

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

6. Promise.all()

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

const result = await Promise.all([
  Promise.resolve("A"),
  Promise.resolve("B"),
  Promise.resolve("C"),
]);

console.log(result);

Output:

["A", "B", "C"]

An important property of Promise.all() is that it preserves the input order.

Even if the second operation finishes first, the result remains in the same order as the input.

Fail-fast behavior

If one Promise rejects:

await Promise.all([
  Promise.resolve("A"),
  Promise.reject("Something failed"),
  Promise.resolve("C"),
]);

The returned Promise rejects.

This is called fail-fast behavior.

The other operations that have already started are not automatically cancelled.

7. My Custom Promise.all()

For this task, I implemented:

customAll(iterable)

The implementation:

Converts the iterable into an array.
Handles an empty iterable.
Processes every item.
Stores results using the original index.
Resolves only after everything fulfills.
Rejects when an item rejects.

The index is important because it allows the implementation to preserve input order.

Conceptually:

results[index] = value;

So completion order and result order can be different.

8. Promise.race()

Promise.race() settles when the first Promise settles.

const result = await Promise.race([
  delay(1000, "Slow"),
  delay(100, "Fast"),
]);

console.log(result);

Output:

Fast

For example:

Task A → 1000 ms
Task B → 200 ms
Task C → 500 ms

Winner → Task B

The first fulfilled or rejected Promise determines the result.

9. My Custom Promise.race()

I implemented:

customRace(iterable)

Each input is converted into a Promise-like value.

Then each one tries to settle the same resulting Promise.

Conceptually:

items.forEach((item) => {
  Promise.resolve(item).then(
    resolve,
    reject
  );
});

Only the first settlement matters.

An empty iterable remains pending, matching the behavior of native Promise.race().

10. Promise.allSettled()

Sometimes we don't want the entire operation to fail just because one Promise failed.

That is where Promise.allSettled() is useful.

const result = await Promise.allSettled([
  Promise.resolve("Success"),
  Promise.reject("Failed"),
  Promise.resolve("Another success"),
]);

The result looks like:

[
  {
    status: "fulfilled",
    value: "Success"
  },
  {
    status: "rejected",
    reason: "Failed"
  },
  {
    status: "fulfilled",
    value: "Another success"
  }
]

Unlike Promise.all(), allSettled() waits for every operation.

11. When Should We Use Each Combinator?

Combinator	Behavior
`Promise.all()`	Wait for everything, fail if one rejects
`Promise.race()`	Take the first settled result
`Promise.allSettled()`	Wait for everything and report every result

Promise.all()

Useful when every operation is required.

Example:

Load user + permissions + profile

Promise.race()

Useful when the first result matters.

Example:

Try multiple servers and use the first response.

Promise.allSettled()

Useful when every result should be inspected.

Example:

Send notifications to 100 users and inspect which succeeded or failed.

12. Concurrency

Now we come to another important concept: concurrency.

Imagine we have 100 tasks:

const tasks = [
  task1,
  task2,
  task3,
  // ...
  task100
];

If we start all 100 at once, we could have:

100 tasks running
        ↓
High resource usage
        ↓
Too many network requests
        ↓
Possible API rate limits
        ↓
System overload

Sometimes we need to control how many tasks can run at the same time.

That is called concurrency limiting.

13. What Does a Concurrency Limit Mean?

Suppose:

limit = 3

This means:

At most 3 tasks are allowed to run at the same time.

The basic flow is:

Start 3 tasks
     ↓
One finishes
     ↓
Start the next task
     ↓
One finishes
     ↓
Start the next task
     ↓
Repeat until everything completes

The important rule is:

active tasks <= concurrency limit

14. Why Tasks Must Be Functions

One important design decision is that the task list contains functions, not already-created Promises.

Correct:

const tasks = [
  () => fetchUser(1),
  () => fetchUser(2),
  () => fetchUser(3),
];

Why?

Because a function lets the concurrency limiter decide when the operation starts.

If we instead write:

const tasks = [
  fetchUser(1),
  fetchUser(2),
  fetchUser(3),
];

the requests may already have started before the limiter gets control.

So the function acts like a delayed instruction:

Task function
     ↓
Wait in queue
     ↓
Limiter starts it
     ↓
Promise begins

15. My Concurrency Limiter

I implemented:

runWithConcurrency(tasks, limit)

For example:

const results = await runWithConcurrency(
  [
    () => delay(300, "A"),
    () => delay(100, "B"),
    () => delay(200, "C"),
    () => delay(150, "D"),
  ],
  2
);

The limit is 2, so only two tasks can run simultaneously.

The basic algorithm is:

Start up to LIMIT tasks
        ↓
One task finishes
        ↓
Start the next queued task
        ↓
Repeat
        ↓
All tasks complete

16. Preserving Result Order

Suppose tasks finish in this order:

Task 2
Task 3
Task 1
Task 4

The returned result should still be:

[
  result1,
  result2,
  result3,
  result4
]

To achieve this, the implementation stores every result using the task's original index:

results[index] = value;

So completion order and result order can be different.

17. Handling Errors

The concurrency limiter rejects if a task fails.

For example:

const tasks = [
  () => successfulTask(),
  () => failingTask(),
  () => anotherTask(),
];

If one task rejects, the returned Promise rejects.

However, tasks that were already running cannot generally be cancelled automatically.

This is an important distinction:

Promise rejection
        ≠
Automatic cancellation

JavaScript Promises do not provide generic cancellation by themselves.

When supported by the underlying API, AbortController can be used for cancellation.

18. Input Validation

The implementation also validates the arguments.

For example, the concurrency limit must be a positive integer.

Invalid:

runWithConcurrency(tasks, 0);
runWithConcurrency(tasks, -1);
runWithConcurrency(tasks, 1.5);

Valid:

runWithConcurrency(tasks, 3);

The implementation also checks that every task is a function.

19. Testing the Implementation

The tests cover the main behaviors.

Promise.all

Tested:

Multiple fulfilled values
Input ordering
Rejection
Empty iterable
Native Promise compatibility

Promise.race

Tested:

Fastest settlement
Rejection
Empty iterable behavior

Promise.allSettled

Tested:

Fulfilled results
Rejected results
Mixed results
Input ordering
Empty iterable

Concurrency limiter

Tested:

Maximum concurrency
Result ordering
Task failures
Invalid limits
Invalid task values
Empty task arrays

Run the tests with:

node week-05/Task-02/test.js

Expected output:

All Week 05 Task 02 tests passed.

20. Concurrency vs Parallelism

These terms are related but not exactly the same.

Concurrency means multiple tasks can make progress during the same period.

Parallelism means tasks are literally executing at the same time, usually using multiple CPU cores or workers.

For JavaScript asynchronous I/O, we commonly talk about concurrency because multiple operations can be in progress while the JavaScript thread continues handling other work.

21. Real-World Example

Imagine an application needs to download 1,000 images.

A naive implementation might start everything immediately:

await Promise.all(
  images.map((image) => download(image))
);

This can create a very large number of active operations.

A concurrency limiter can instead do:

await runWithConcurrency(
  images.map((image) => () => download(image)),
  5
);

Now only five downloads are active at a time.

This gives us better control over resource usage and external service pressure.

22. What I Learned

Through this task, I learned that asynchronous programming is not only about writing async and `await.

The important concepts are:

How Promises work
How Promise states change
How Promise.all() coordinates multiple operations
How Promise.race() selects the first settlement
How Promise.allSettled() collects every outcome
Why input ordering matters
Why concurrency needs to be controlled
Why queued tasks should be functions
Why Promise rejection does not automatically cancel running operations
How to test asynchronous behavior reliably

The biggest takeaway for me was understanding the difference between:

text Starting everything immediately

and:

text Controlling when asynchronous work starts

That distinction becomes very important when building real applications.

23. Conclusion

Async/Await makes asynchronous JavaScript easier to read, but Promise combinators provide the tools needed to coordinate multiple asynchronous operations.

`text
Promise.all()
↓
Everything must succeed

Promise.race()
↓
First settlement matters

Promise.allSettled()
↓
Every result matters
`

Concurrency limiting adds another layer of control:

text Large number of tasks ↓ Task queue ↓ Concurrency limit ↓ Controlled execution ↓ Ordered results

Understanding these concepts gives a strong foundation for working with APIs, databases, file operations, background jobs, and other asynchronous systems in JavaScript.

Repository

The implementation for this task is part of my Week 05 learning project.

Branch:

text week-05-task-02-async-await-combinators

Task directory:

text week-05/Task-02/

Files:

text promise-combinators.js concurrency-limiter.js test.js README.md

Final Takeaway

When working with asynchronous JavaScript, ask three questions:

Do I need all operations to succeed?
- Use Promise.all().
Do I only care about the first result?
- Use Promise.race().
Do I need to know the result of every operation?
- Use Promise.allSettled().

And when there are many tasks:

Don't just start everything. Control how much work runs at once.

That is the core idea behind concurrency limiting.

JavaScript Promises Explained: Callback Hell, Promise States, Chaining & Error Propagation

koushikmaya — Tue, 08 Sep 2026 22:21:37 +0000

Asynchronous JavaScript is one of the most important concepts to
understand when building modern web applications.

At first, asynchronous code is often written using callbacks. But when
multiple asynchronous operations depend on each other, the code can
become difficult to read and maintain. This problem is commonly known as
callback hell.

JavaScript Promises provide a cleaner way to handle asynchronous
operations using .then(), .catch(), and .finally().

In this article, we'll understand:

Callback hell
What a Promise is
Promise states: pending, fulfilled, and rejected
.then()
.catch()
.finally()
Promise chaining
Error propagation
Error recovery

1. What is a Callback?

A callback is a function that is passed to another function and executed
later, usually after an operation has completed.

function getUser(callback) {
  setTimeout(() => {
    callback("User data");
  }, 1000);
}

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

Here:

getUser() starts an asynchronous operation.
The callback function is passed to getUser().
After one second, the callback is executed.
"User data" is received by the callback.

Callbacks work well for simple operations, but problems appear when we
have many dependent asynchronous operations.

2. Callback Hell

Imagine that we need to:

Get a user
Get that user's posts
Get comments for those posts
Get likes for those comments

Using callbacks, we might write:

getUser((user) => {
  getPosts(user, (posts) => {
    getComments(posts, (comments) => {
      getLikes(comments, (likes) => {
        console.log(likes);
      });
    });
  });
});

Notice how the functions keep getting nested inside one another.

This is called callback hell, also known as the Pyramid of Doom.

Why is callback hell a problem?

Deeply nested callbacks can make code:

Difficult to read
Difficult to debug
Difficult to maintain
Difficult to handle errors in
Harder to extend when more asynchronous operations are added

Promises provide a cleaner alternative.

Instead of:

getUser((user) => {
  getPosts(user, (posts) => {
    getComments(posts, (comments) => {
      getLikes(comments, (likes) => {
        console.log(likes);
      });
    });
  });
});

We can write:

getUser()
  .then(getPosts)
  .then(getComments)
  .then(getLikes)
  .catch(handleError);

The flow becomes much easier to follow.

3. What is a Promise?

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

A Promise can either:

Complete successfully
Fail

For example:

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

  resolve("Success!");
});

A Promise receives two functions:

resolve() --- used when the operation succeeds
reject() --- used when the operation fails

For example:

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

  if (success) {
    resolve("Operation successful");
  } else {
    reject("Operation failed");
  }
});

4. Promise States

Every Promise has three possible states:

Pending
   |
   +----> Fulfilled
   |
   +----> Rejected

4.1 Pending

A Promise starts in the pending state.

It means the asynchronous operation has not completed yet.

const promise = new Promise((resolve, reject) => {
  // Operation is still running
});

At this point, the Promise is pending.

4.2 Fulfilled

If the operation completes successfully, we call resolve().

const promise = new Promise((resolve, reject) => {
  resolve("Data received");
});

The Promise is now fulfilled.

The successful result can be handled using .then().

4.3 Rejected

If something goes wrong, we call reject().

const promise = new Promise((resolve, reject) => {
  reject("Something went wrong");
});

The Promise is now rejected.

The error can be handled using .catch().

Important: A Promise settles only once

A Promise starts as pending and eventually becomes either fulfilled or
rejected.

Once it is settled, its state cannot be changed again.

             Fulfilled
            /
Pending ----
            \
             Rejected

For example:

const promise = new Promise((resolve, reject) => {
  resolve("Success");
  reject("Error");
});

The rejection will not change the result because the Promise has already
been fulfilled.

5. `.then()`

The .then() method is used to handle a successful Promise result.

Promise.resolve("Hello")
  .then((result) => {
    console.log(result);
  });

Output:

Hello

The value passed to resolve() becomes the value received by .then().

const promise = new Promise((resolve) => {
  resolve("User data");
});

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

6. Promise Chaining

One of the biggest advantages of Promises is chaining.

We can attach multiple .then() calls:

Promise.resolve(10)
  .then((num) => {
    return num * 2;
  })
  .then((num) => {
    return num + 10;
  })
  .then((result) => {
    console.log(result);
  });

The output is:

The flow is:

The important rule

Whatever you return from one .then() becomes the input to the next
.then().

For example:

Promise.resolve(5)
  .then((value) => {
    return value * 2;
  })
  .then((value) => {
    console.log(value);
  });

The first .then() returns 10, so the second .then() receives 10.

7. Chaining Asynchronous Operations

Promises become especially useful when one asynchronous operation
depends on another.

For example:

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

The flow is:

getUser()
   ↓
user
   ↓
getPosts(user)
   ↓
posts
   ↓
getComments(posts)
   ↓
comments

Each operation returns a Promise, and the next .then() waits for that
Promise to settle successfully.

8. `.catch()`

.catch() is used to handle rejected Promises and errors that occur in
the Promise chain.

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

Output:

Network error

A common pattern is:

fetchData()
  .then((data) => {
    console.log(data);
  })
  .catch((error) => {
    console.log("Error:", error);
  });

If fetchData() fails, the .catch() handles the error.

9. Error Propagation

This is one of the most important Promise concepts.

Suppose an error occurs inside a .then():

Promise.resolve()
  .then(() => {
    throw new Error("Something went wrong");
  })
  .then(() => {
    console.log("This will not execute");
  })
  .catch((error) => {
    console.log(error.message);
  });

Output:

Something went wrong

What happened?

.then()
   ↓
Error is thrown
   ↓
Promise becomes rejected
   ↓
Next .then() is skipped
   ↓
.catch() handles the error

An error can therefore propagate through the Promise chain until a
.catch() handler is found.

10. Error Propagation Through Multiple `.then()` Calls

Consider:

Promise.resolve("Start")
  .then((value) => {
    console.log(value);
    return "Step 1";
  })
  .then((value) => {
    console.log(value);
    throw new Error("Failed!");
  })
  .then(() => {
    console.log("This won't run");
  })
  .then(() => {
    console.log("This won't run either");
  })
  .catch((error) => {
    console.log(error.message);
  });

The output is:

Start
Step 1
Failed!

Once the error is thrown, the remaining .then() handlers are skipped
until .catch() is reached.

This is why we can put a single .catch() at the end of a Promise chain
to handle errors from multiple operations.

11. `.finally()`

.finally() runs regardless of whether the Promise is fulfilled or
rejected.

fetchData()
  .then((data) => {
    console.log(data);
  })
  .catch((error) => {
    console.log(error);
  })
  .finally(() => {
    console.log("Operation finished");
  });

The flow is:

Success → .then() → .finally()

Failure → .catch() → .finally()

A common use case is a loading indicator.

setLoading(true);

fetchData()
  .then((data) => {
    displayData(data);
  })
  .catch((error) => {
    displayError(error);
  })
  .finally(() => {
    setLoading(false);
  });

Whether the request succeeds or fails, the loading indicator is turned
off.

12. `.catch()` Can Recover From an Error

An interesting feature of Promise chains is that .catch() can return a
value.

Promise.reject("Error")
  .catch((error) => {
    console.log(error);
    return "Recovered";
  })
  .then((value) => {
    console.log(value);
  });

Output:

Error
Recovered

Why does the final .then() execute?

Because the .catch() returned "Recovered".

The flow is:

Rejected
   ↓
.catch()
   ↓
return "Recovered"
   ↓
Fulfilled
   ↓
.then()

So a .catch() can handle an error and allow the Promise chain to
continue.

13. Complete Example

Let's combine all the concepts.

function getUser() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve({
        id: 1,
        name: "Koushik"
      });
    }, 1000);
  });
}

function getPosts(user) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(["Post 1", "Post 2"]);
    }, 1000);
  });
}

getUser()
  .then((user) => {
    console.log("User:", user);
    return getPosts(user);
  })
  .then((posts) => {
    console.log("Posts:", posts);
  })
  .catch((error) => {
    console.log("Error:", error);
  })
  .finally(() => {
    console.log("Finished");
  });

The execution flow is approximately:

getUser()
   ↓
Pending
   ↓
Fulfilled
   ↓
.then(user)
   ↓
getPosts(user)
   ↓
Pending
   ↓
Fulfilled
   ↓
.then(posts)
   ↓
.catch() if something fails
   ↓
.finally()

14. Callback Hell vs Promises

Callback version

getUser((user) => {
  getPosts(user, (posts) => {
    getComments(posts, (comments) => {
      getLikes(comments, (likes) => {
        console.log(likes);
      });
    });
  });
});

Promise version

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

The Promise version is flatter, easier to read, and provides a
centralized error-handling mechanism.

15. Quick Summary

Concept Meaning

Callback Function executed later
Callback Hell Deeply nested callbacks
Promise Represents the eventual result of an async operation
Pending Operation is still in progress
Fulfilled Operation completed successfully
Rejected Operation failed
.then() Handles successful results
.catch() Handles errors
.finally() Runs regardless of success or failure
Promise chaining Connecting multiple asynchronous operations
Error propagation Errors move through the chain until handled

The most important flow to remember is:

             ┌──→ Fulfilled → .then()
             │
Pending ─────┤
             │
             └──→ Rejected → .catch()

                         ↓
                      .finally()

And the most important Promise chaining rule is:

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

Final Takeaway

Callbacks are useful for handling asynchronous operations, but deeply
nested callbacks can lead to callback hell.

Promises provide a structured way to manage asynchronous operations. A
Promise starts as pending and eventually becomes either
fulfilled or rejected.

Use .then() for successful results.
Use .catch() for errors.
Use .finally() for code that should run regardless of the result.
Use chaining to organize multiple asynchronous operations.
Errors thrown anywhere in a chain can propagate to .catch().

Understanding these concepts gives you the foundation for learning
async/await, which provides another cleaner way to work with
Promises.

# Functional Programming in JavaScript: Writing Code That Is Easier to Understand

koushikmaya — Thu, 03 Sep 2026 05:03:01 +0000

When I first started learning JavaScript, I mostly focused on what the
code should do.

If I needed to change an array, I would change the array.\
If I needed to reuse some logic, I would put it inside a function.\
If I needed to process data, I would probably reach for a for loop.

There is nothing wrong with that approach. But as applications become
larger, the way we structure our logic starts to matter just as much as
the result.

This is where Functional Programming (FP) becomes useful.

Functional programming is not about avoiding every loop or writing
complicated one-line expressions. It is mainly about making our code
predictable, reusable, and easier to reason about.

In this blog, I'll walk through some of the most useful functional
programming concepts in JavaScript:

Pure functions
Immutability
Higher-order functions
map(), filter(), and reduce()
Currying
Composition with pipe() and compose()

1. What Is Functional Programming?

Functional programming is a programming style where we try to solve
problems by combining functions and transforming data.

Instead of thinking:

"First change this variable, then change that variable, then update
another variable."

we can think:

"Take this data, transform it, and pass the result to the next
function."

For example:

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

const doubled = numbers.map(number => number * 2);

console.log(doubled);
// [2, 4, 6, 8, 10]

The original numbers array is still there. We created a new result
from it.

That small idea is at the heart of a lot of functional programming.

2. Pure Functions

A pure function is a function that behaves predictably.

A function is considered pure when:

The same input always produces the same output.
The function does not create side effects outside itself.

Example of a pure function

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

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

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

Every time we call add(2, 3), we get 5.

The function does not depend on some outside variable that might
suddenly change.

Another example

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

This is easy to understand:

square(4); // 16
square(10); // 100

We know exactly what the function will return.

Impure functions

Now consider this:

let total = 10;

function addToTotal(value) {
    total += value;
    return total;
}

This function changes the external variable total.

So the result depends on what happened before:

addToTotal(5); // 15
addToTotal(5); // 20

The same argument 5 did not produce the same result.

This makes the function harder to reason about.

Why pure functions are useful

Pure functions make code:

Easier to test
Easier to debug
Easier to reuse
Easier to understand
Safer to combine with other functions

A useful mental model is:

input → function → output

The fewer hidden dependencies a function has, the easier it is to work
with.

3. Immutability

Immutability means that instead of changing existing data, we create
new data.

Consider an array:

const numbers = [1, 2, 3];

We could modify it directly:

numbers.push(4);

Now the original array has changed:

console.log(numbers);
// [1, 2, 3, 4]

That is a mutation.

In functional programming, we often prefer:

const numbers = [1, 2, 3];

const updatedNumbers = [...numbers, 4];

console.log(numbers);
// [1, 2, 3]

console.log(updatedNumbers);
// [1, 2, 3, 4]

We kept the original data untouched and created a new array.

Immutability with objects

The same idea applies to objects.

Instead of:

const user = {
    name: "Koushik",
    age: 22
};

user.age = 23;

we can create a new object:

const user = {
    name: "Koushik",
    age: 22
};

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

console.log(user);
// { name: "Koushik", age: 22 }

console.log(updatedUser);
// { name: "Koushik", age: 23 }

This becomes particularly useful in applications where many parts of the
program depend on the same data.

When data is not unexpectedly modified, tracking changes becomes much
easier.

4. Higher-Order Functions

A higher-order function is a function that does at least one of
these:

Takes another function as an argument
Returns another function

JavaScript supports this because functions are treated as values.

For example:

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

function processUser(callback) {
    return callback("Koushik");
}

console.log(processUser(greet));
// Hello Koushik

Here, processUser() receives another function.

So processUser is a higher-order function.

A function returning another function

This is also a higher-order function:

function multiplyBy(number) {
    return function(value) {
        return value * number;
    };
}

const multiplyByTwo = multiplyBy(2);

console.log(multiplyByTwo(5));
// 10

The interesting part is:

multiplyBy(2)

doesn't immediately return a number.

It returns a new function.

That idea will become important when we talk about currying.

5. map(), filter(), and reduce()

Three of the most useful functional methods in JavaScript are:

map()
filter()
reduce()

They allow us to transform and process collections without manually
managing indexes.

map()

Use map() when you want to transform every item in an array.

For example:

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

const doubled = numbers.map(number => number * 2);

console.log(doubled);
// [2, 4, 6, 8]

Think of map() as:

one item → transform it → one new item

If the original array has 4 items, the resulting array normally also has
4 items.

Another example

const users = [
    { name: "Asha", age: 21 },
    { name: "Rahul", age: 25 },
    { name: "Maya", age: 23 }
];

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

console.log(names);
// ["Asha", "Rahul", "Maya"]

We transformed an array of objects into an array of names.

6. filter()

Use filter() when you want to keep only the items that satisfy a
condition.

Example:

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

const evenNumbers = numbers.filter(number => number % 2 === 0);

console.log(evenNumbers);
// [2, 4, 6]

The callback returns either:

true

false

If it returns true, the item stays.

If it returns false, the item is removed from the result.

Real-world example

const users = [
    { name: "Asha", active: true },
    { name: "Rahul", active: false },
    { name: "Maya", active: true }
];

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

console.log(activeUsers);

This is much easier to read than manually creating another array and
pushing items into it.

7. reduce()

reduce() is useful when we want to combine many values into one
result.

For example, adding numbers:

const numbers = [10, 20, 30, 40];

const total = numbers.reduce(
    (sum, number) => sum + number,
    0
);

console.log(total);
// 100

The second argument:

is the initial value of the accumulator.

You can think about reduce() like this:

start with 0
   ↓
0 + 10 = 10
   ↓
10 + 20 = 30
   ↓
30 + 30 = 60
   ↓
60 + 40 = 100

reduce() can do more than addition

For example, we can create an object from an array:

const users = [
    { name: "Asha", role: "developer" },
    { name: "Rahul", role: "designer" },
    { name: "Maya", role: "developer" }
];

const usersByRole = users.reduce((result, user) => {
    if (!result[user.role]) {
        result[user.role] = [];
    }

    result[user.role].push(user.name);

    return result;
}, {});

console.log(usersByRole);

The result becomes:

{
    developer: ["Asha", "Maya"],
    designer: ["Rahul"]
}

This shows why reduce() is powerful: it can transform a collection
into many different kinds of results.

8. map vs filter vs reduce

A simple way to remember them:

Method Main purpose Typical result

map() Transform every item New array
filter() Select certain items Smaller/new array
reduce() Combine items into a result Any value

For example:

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

`map()`

numbers.map(n => n * 2);

Result:

[2, 4, 6, 8, 10]

`filter()`

numbers.filter(n => n > 2);

Result:

[3, 4, 5]

`reduce()`

numbers.reduce((sum, n) => sum + n, 0);

Result:

9. Currying

Currying sounds complicated at first, but the basic idea is simple.

Currying converts a function that takes multiple arguments into a
series of functions that each take one argument.

Instead of:

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

add(2, 3);

we can write:

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

console.log(add(2)(3));
// 5

The first function receives 2 and returns another function.

That second function receives 3.

Currying with arrow functions

The same thing can be written more compactly:

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

console.log(add(2)(3));
// 5

It may look strange initially, but break it down:

add(2)

returns:

b => 2 + b

Then:

add(2)(3)

becomes:

2 + 3

which gives:

Why use currying?

Currying becomes useful when we want to create specialized functions.

For example:

const multiplyBy = a => b => a * b;

const multiplyBy10 = multiplyBy(10);

console.log(multiplyBy10(5));
// 50

console.log(multiplyBy10(8));
// 80

Instead of repeatedly passing 10, we created a reusable function that
already knows it should multiply by 10.

This idea is closely connected to function reuse and composition.

10. Function Composition

Function composition means taking small functions and combining them to
create a larger operation.

Imagine these functions:

const double = number => number * 2;

const addTen = number => number + 10;

We can manually combine them:

const result = addTen(double(5));

console.log(result);
// 20

The flow is:

5
 ↓
double
 ↓
10
 ↓
addTen
 ↓
20

This is composition.

Instead of putting all the logic into one large function, we keep each
operation small.

11. pipe()

A pipe() function allows us to write the same flow from left to
right.

Here is a simple implementation:

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

Now we can write:

const double = number => number * 2;

const addTen = number => number + 10;

const processNumber = pipe(
    double,
    addTen
);

console.log(processNumber(5));
// 20

The data flows like this:

5
 ↓
double
 ↓
10
 ↓
addTen
 ↓
20

I personally find pipe() easier to read because the execution order is
the same as the order in which the functions are written.

12. compose()

compose() is very similar to pipe(), but the functions are usually
applied right to left.

For example:

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

Now:

const double = number => number * 2;

const addTen = number => number + 10;

const processNumber = compose(
    addTen,
    double
);

console.log(processNumber(5));
// 20

The execution is:

5
 ↓
double
 ↓
10
 ↓
addTen
 ↓
20

The important difference is how the functions are listed.

pipe()

pipe(double, addTen);

Reads:

double → addTen

compose()

compose(addTen, double);

Reads from right to left:

double → addTen

13. Putting Everything Together

Now let's combine several of these ideas.

Suppose we have a list of users:

const users = [
    { name: "Asha", age: 20, active: true },
    { name: "Rahul", age: 17, active: true },
    { name: "Maya", age: 25, active: false },
    { name: "Arjun", age: 30, active: true }
];

Our goal is:

Keep active users.
Keep users who are adults.
Extract their names.

We can do that with:

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

const getAdults = users =>
    users.filter(user => user.age >= 18);

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

Now we can compose them:

const getActiveAdultNames = pipe(
    getActiveUsers,
    getAdults,
    getNames
);

console.log(getActiveAdultNames(users));

Result:

["Asha", "Arjun"]

This is a good example of the functional programming mindset.

Instead of writing one large function that does everything, we created
several small functions.

Each function has one responsibility.

Then we connected them together.

14. Why This Style Is Useful

Functional programming can make applications easier to maintain because
small functions are easier to understand individually.

For example:

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

This function has a very clear responsibility.

If something goes wrong with active-user filtering, we know where to
look.

The same idea becomes especially useful in:

Data processing
API response transformation
State management
Frontend applications
Backend services
Testing
Complex business logic

It also encourages us to avoid unnecessary mutations and hidden side
effects.

15. A Practical Mental Model

When writing JavaScript, I find it useful to ask a few questions:

1. Can this function be pure?

Instead of depending on external variables:

function calculatePrice(price) {
    return price * 1.18;
}

keep the required data as input when possible.

2. Do I really need to mutate this data?

Instead of:

items.push(newItem);

consider:

const updatedItems = [...items, newItem];

when immutability makes the code easier to reason about.

3. Can I reuse this logic?

If the same logic appears in several places, extract it into a function.

4. Can I transform the data with map/filter/reduce?

Instead of manually managing indexes and temporary variables, see
whether one of these methods expresses the intention more clearly.

5. Can I break a large operation into smaller functions?

For example:

fetchData
→ filterData
→ transformData
→ sortData
→ formatData

can often be represented as a pipeline.

16. Functional Programming Does Not Mean "Never Use Loops"

This is an important point.

Functional programming is a programming style, not a rule that says:

"You are not allowed to write a for loop."

There are situations where a loop is perfectly reasonable.

The goal is not to make code look "functional."

The goal is to make code:

Clear
Predictable
Reusable
Maintainable

If a simple loop communicates the idea better, use the loop.

Good programming is about choosing the right tool for the problem.

17. Quick Summary

Here is the easiest way to remember these concepts:

Pure functions

Same input → Same output
No unwanted side effects

Immutability

Don't change existing data unnecessarily.
Create new data instead.

Higher-order functions

Functions can receive functions
or return functions.

map()

Transform every item.

filter()

Keep items that match a condition.

reduce()

Combine many items into one result.

Currying

multiple arguments
        ↓
series of functions

Example:

add(2)(3);

pipe()

function A → function B → function C

compose()

function C ← function B ← function A

Final Thoughts

The biggest lesson I took from functional programming is that small
functions can be surprisingly powerful when they are combined well.

Instead of building one huge function that knows how to do everything,
we can create small pieces:

filterUsers()
getAdults()
getNames()
sortUsers()

and connect them:

pipe(
    filterUsers,
    getAdults,
    getNames,
    sortUsers
);

Each function has a clear job.

That makes the overall program easier to understand because we can look
at the pipeline and almost read it like a sentence.

Functional programming is not about writing clever code.

It is about writing code where the data flow and intention are easy to
see.

And once concepts like pure functions, immutability, higher-order
functions, map, filter, reduce, currying, and composition start to
click, JavaScript becomes a lot more expressive.

DEV Community: koushikmaya

# NestJS Fundamentals: Modules, Controllers, Services, Dependency Injection & Request Lifecycle

1. What Is NestJS?

2. Imagine a Restaurant

3. Controllers: Receiving Requests

@Controller('users')

@Get()

findAll()

Why not put all the logic in the controller?

4. Providers and Services: Doing the Work

What does @Injectable() mean?

5. Modules: Organizing the Application

@Module()

controllers

providers

6. How the Pieces Connect

7. Dependency Injection (DI)

8. What Is the DI Container?

9. Why Is DI Better Than Creating Classes Manually?

10. How Does NestJS Know What to Inject?

11. The Main Application Module

12. Understanding the Three Main Decorators

@Module()

@Controller()

@Injectable()

13. The Request Lifecycle

14. Middleware

15. Guards

16. Interceptors

17. Pipes

18. Exception Filters

19. A Small End-to-End Example

20. A Note About Provider Scope

21. Common Beginner Mistakes

Mistake 1: Forgetting to register a service

Mistake 2: Putting all business logic in the controller

Mistake 3: Thinking modules automatically share every provider

Mistake 4: Confusing authentication and validation

Mistake 5: Thinking a service must always connect to a database

22. The Big Picture

23. Quick Revision Cheat Sheet

24. Final Takeaway

week-07 Task-3 # package.json, SemVer, npm Scripts, Configuration & Monorepos: Understanding the Node.js Project Setup

1. What Is package.json?

2. Why Does package.json Matter?

3. Creating package.json

4. Understanding the Main Fields

5. name

6. version

7. SemVer: Semantic Versioning

8. MAJOR Version

9. MINOR Version

10. PATCH Version

11. The Easy SemVer Memory Trick

12. What Does ^ Mean?

13. What Does ~ Mean?

14. Exact Versions

15. dependencies vs devDependencies

16. Example of a Dependency

17. Example of a Dev Dependency

18. More Examples

Usually dependencies

Usually devDependencies

19. A Simple Question to Decide

20. What Is package-lock.json?

21. npm Scripts

22. Why Are npm Scripts Useful?

23. npm run

24. A Realistic scripts Section

25. Configuration Management

26. Environment Variables

27. Why Not Put Secrets in Git?

28. What Is dotenv?

29. dotenv/config

30. .env Should Usually Not Be Committed

31. Configuration Should Be Centralized

32. Configuration Validation

33. Development vs Production Configuration

34. What Is a Monorepo?

35. Why Use a Monorepo?

`@Controller('users')`

`@Get()`

`findAll()`

What does `@Injectable()` mean?

`@Module()`

`controllers`

`providers`

`@Module()`

`@Controller()`

`@Injectable()`

1. What Is `package.json`?

2. Why Does `package.json` Matter?

3. Creating `package.json`

5. `name`

6. `version`

12. What Does `^` Mean?

13. What Does `~` Mean?

15. `dependencies` vs `devDependencies`

20. What Is `package-lock.json`?

23. `npm run`

24. A Realistic `scripts` Section

29. `dotenv/config`

30. `.env` Should Usually Not Be Committed

38. Why `private: true`?