DEV Community: Dulaj Thiwanka

Asterism: Turning Large Codebases into Interactive Visual Maps

Dulaj Thiwanka — Fri, 11 Sep 2026 23:05:42 +0000

Asterism: Turning Large Codebases into Interactive Visual Maps

Subtitle: How I built a VS Code extension that uses language-server capabilities and interactive graphs to help developers understand how code is connected.

Introduction

Understanding a large codebase is one of the hardest parts of software development.

When joining an unfamiliar project, developers often start by opening files and following imports, function calls, class definitions, and references manually. That works reasonably well for small projects, but becomes increasingly difficult as the codebase grows.

A function may call another function several layers deep. A class may inherit from another class defined in a different folder. A variable may be used across multiple methods. A change to one symbol may affect code that is not immediately obvious from the file being edited.

The problem isn't necessarily that the code is poorly written.

The problem is that the relationships inside the codebase are difficult to see.

That observation led to my idea for Asterism, a VS Code extension designed to turn those relationships into an interactive visual map.

Instead of only reading code line by line, developers can explore a graph of functions, methods, classes, interfaces, variables, files, and folders — and move between that visual representation and the actual source code.

The Problem with Understanding Large Codebases

Software is naturally represented as text.

Developers write:

function A() {
    B();
}

function B() {
    C();
}

A human can understand this small example immediately.

But imagine the same relationship spread across:

500 files
thousands of functions
dozens of classes
multiple inheritance relationships
shared variables
deeply nested folders
several layers of abstraction

Finding relationships manually becomes expensive.

Consider a seemingly simple question:

"If I change this function, what other parts of the application might be affected?"

You may need to:

Find the function.
Find its references.
Identify callers.
Inspect those callers.
Follow additional calls.
Check related classes.
Check inherited implementations.
Check variables or fields being used.
Navigate between multiple files.

The information exists inside the codebase, but it is distributed across many source files and language constructs.

Asterism approaches the problem from a different direction:

What if the relationships already understood by the development environment could be turned into an interactive graph?

What Is Asterism?

Asterism is a Visual Studio Code extension for exploring the structure and relationships of a codebase through interactive graphs.

The name comes from the astronomical concept of an asterism — a recognizable pattern formed by stars.

That idea maps nicely to software.

A codebase contains many individual "points":

Functions
Methods
Classes
Interfaces
Variables
Files
Folders

And relationships connect those points.

For example:

             ┌─────────────┐
             │ Controller  │
             └──────┬──────┘
                    │ calls
                    ▼
             ┌─────────────┐
             │  Service    │
             └──────┬──────┘
                    │ calls
                    ▼
             ┌─────────────┐
             │ Repository  │
             └─────────────┘

Asterism turns relationships like these into an interactive graph that developers can explore.

How Asterism Works

At a high level, the process looks like this:

VS Code Workspace
       │
       ▼
Workspace Scanner
       │
       ▼
VS Code Language APIs
       │
       ├── Symbols
       ├── Calls
       ├── References
       ├── Definitions
       └── Type Relationships
       │
       ▼
Relationship Model
       │
       ▼
Graph Generation
       │
       ▼
Cytoscape.js
       │
       ▼
Interactive Webview

The important design decision here is that Asterism does not try to build a custom parser for every programming language.

Instead, it makes use of capabilities that VS Code and the installed language extensions already provide.

That makes the architecture considerably more language-neutral.

The Language-Server Advantage

One of the most important technical decisions in Asterism is relying on VS Code's language-service and language-server ecosystem.

Modern development environments already understand a lot about source code.

Depending on the language and installed extension, VS Code can provide information about things such as:

Symbols
Definitions
References
Call hierarchies
Incoming calls
Outgoing calls
Type hierarchies
Implementations
Symbol relationships

Rather than rebuilding all of that knowledge from scratch, Asterism asks VS Code's language infrastructure for the information it needs.

Conceptually:

Source Code
    │
    ▼
Language Extension
    │
    ▼
Language Server / Service
    │
    ▼
VS Code APIs
    │
    ▼
Asterism
    │
    ▼
Interactive Graph

This is particularly useful because programming languages have very different syntax and semantics.

A custom parser-based approach would require maintaining language-specific parsing and analysis logic.

With Asterism's approach, much of that language-specific work remains within the existing VS Code ecosystem.

A practical consequence

If VS Code has appropriate language support installed for a programming language, Asterism can potentially use the information exposed by that language support.

The quality and completeness of the resulting graph therefore depend partly on what the language service provides.

Main Features

Asterism is built around several kinds of code relationships.

Function and Method Calls

The graph can show relationships between functions and methods.

For example:

authenticate()
      │
      ▼
validateUser()
      │
      ▼
findUser()

This makes it possible to explore both directions:

Outgoing calls: What does this function call?
Incoming calls: What calls this function?

This is useful when investigating execution flow or estimating the potential impact of a change.

Class Inheritance

Object-oriented code often contains relationships that are difficult to understand when spread across multiple files.

Asterism can visualize inheritance relationships:

BaseController
       ▲
       │ inherits
       │
UserController

This provides another dimension of understanding beyond function calls.

Interface Implementations

Interfaces can also form important architectural relationships.

For example:

PaymentProvider
       ▲
       │ implements
       │
StripePaymentProvider

Visualizing these relationships can make larger object-oriented systems easier to navigate.

Variable and Field References

Not every important relationship is a function call.

A function may depend heavily on:

A global variable
A class field
A shared object
A configuration value

Asterism can represent relationships involving variables and class fields as well.

This helps answer questions such as:

"Which parts of the code use this value?"

From Workspace to Graph

The typical Asterism workflow is intentionally simple.

1. Open a project

Open an existing project or workspace in VS Code.

2. Open Asterism

Click the Asterism icon in the VS Code Activity Bar.

3. Workspace scanning

Asterism scans the workspace and builds its available file representation.

4. Browse the project

The Activity Bar sidebar provides a workspace-oriented view of folders and files.

5. Search

If the project is large, developers can search for a file rather than manually navigating through folders.

6. Generate a graph

Click a file to generate a graph related to that source.

You can also generate a graph representing the workspace.

7. Explore

Once the graph appears, you can:

Click nodes
Search symbols
Filter relationships
Trace connected nodes
Collapse structures
Double-click symbols
Follow symbols under the cursor

8. Return to source code

Double-clicking a symbol allows you to jump back to its source code.

The goal is to make visual exploration and traditional code navigation work together rather than treating them as separate workflows.

The Activity Bar Workflow

One of the usability decisions behind Asterism was to make the extension feel like a natural part of VS Code.

Instead of requiring developers to remember commands or navigate complicated menus, Asterism has a dedicated entry point in the Activity Bar.

The workflow becomes:

Activity Bar
     │
     ▼
Asterism Sidebar
     │
     ├── Browse folders
     ├── Browse files
     ├── Search
     └── Workspace graph
              │
              ▼
        Interactive graph
              │
              ▼
         Source code

This reduces the number of steps required to move from:

"I want to understand this part of the project"

to:

"Show me how this code is connected."

Keeping Large Graphs Understandable

A graph can become difficult to use if everything is displayed at once.

Imagine a graph containing hundreds or thousands of nodes.

Even if the underlying data is correct, displaying everything simultaneously can produce something visually overwhelming.

Asterism therefore provides several mechanisms for controlling graph complexity.

Grouping

Nodes can be grouped by:

Folder
File
No group

For example:

src/
 ├── controllers/
 │     ├── UserController
 │     └── AuthController
 │
 ├── services/
 │     ├── UserService
 │     └── AuthService
 │
 └── repositories/
       └── UserRepository

Grouping provides a higher-level structure around the graph.

Collapsing

Folders, files, and classes can be collapsed.

Instead of showing every individual node:

UserService
 ├── createUser()
 ├── updateUser()
 ├── deleteUser()
 ├── validateUser()
 └── notifyUser()

the graph can represent the larger structure more compactly.

This is important because visualization is not simply about displaying more information.

It is about displaying the right amount of information at the right time.

Filtering Relationships

Not every relationship is useful for every investigation.

Sometimes you only care about function calls.

At another point, you may want to understand inheritance.

Asterism provides filtering for relationship categories including:

Calls
Inheritance
Variable references

This allows developers to reduce visual noise while investigating a particular question.

For example:

"Show me only the call flow."

rather than:

"Show me every relationship the system knows about."

Searching Inside the Graph

Large graphs introduce another navigation problem.

Even after generating a graph, finding one particular symbol can be difficult.

Asterism therefore supports symbol search inside the graph.

This allows a developer to move from:

"I know the symbol I need."

to:

"Show me where that symbol sits in the architecture."

That combination of search + visualization is particularly useful for large projects.

Tracing Connections

Asterism also allows developers to select a node and trace its relationships.

The idea is simple:

              A
              │
              ▼
        ┌─────B─────┐
        │            │
        ▼            ▼
        C            D

Selecting B can make its surrounding relationships easier to identify.

This helps developers focus on a specific part of a larger graph without losing the broader context.

Following the Symbol Under the Cursor

Another useful workflow is following the symbol currently under the cursor.

Instead of manually generating a new graph every time you move to another symbol, Asterism can use the active symbol to update the graph.

This creates a more continuous workflow between code editing and visual exploration.

Jumping Between Graph and Source Code

Visualization is useful, but developers ultimately work with source code.

Asterism therefore treats the graph as a navigation layer rather than a replacement for the editor.

Double-clicking a symbol can take the developer back to its source.

The workflow becomes:

Source
  ↓
Graph
  ↓
Explore relationship
  ↓
Select symbol
  ↓
Open source
  ↓
Continue investigation

This creates a feedback loop between visual understanding and actual implementation.

Why Visual Code Maps Are Useful

The usefulness of a graph depends on the question being asked.

There are several situations where visual relationships can be particularly helpful.

1. Learning an unfamiliar project

When joining a new project, developers need to build a mental model.

A visual map can help answer:

Where are the important components?
Which functions connect?
Which classes depend on others?
Where does execution flow?

2. Planning refactoring

Before changing a function or class, it is useful to understand its relationships.

A graph can provide another perspective on potential dependencies.

Instead of immediately modifying code, developers can first investigate how the symbol connects to the surrounding system.

3. Understanding legacy systems

Legacy applications often contain years of accumulated behavior.

Documentation may be incomplete or outdated.

The code itself becomes the most reliable source of information.

A visual representation can help developers gradually reconstruct the system's structure.

4. Finding highly connected functions

Some functions become central points in an application.

They may have:

Many callers
Many outgoing calls
Numerous references

These highly connected areas can be useful places to investigate when trying to understand architecture or potential change impact.

5. Reviewing dependencies

A graph can provide a visual representation of relationships that are otherwise spread across files.

This can make dependency investigation more approachable.

6. Investigating bugs

When debugging, developers frequently ask:

"How did execution get here?"

Following incoming and outgoing relationships can help reconstruct the path surrounding a problematic symbol.

7. Developer onboarding

New developers often need to understand a system before they can contribute effectively.

A visual exploration tool can complement:

Documentation
Code reviews
Architecture diagrams
Existing development guides

8. Understanding inheritance

Inheritance structures can become particularly difficult when classes are distributed across packages and directories.

A graph makes those relationships easier to inspect.

9. Estimating change impact

Before modifying an important symbol, developers can inspect its connections and identify areas that may deserve additional attention.

It isn't a replacement for careful testing, but it can provide useful context before making a change.

Technical Architecture

Asterism is built around several core technologies.

TypeScript

The extension is implemented using TypeScript.

TypeScript provides:

Static typing
Better tooling
Improved maintainability
Strong integration with the VS Code extension ecosystem

For an extension that coordinates workspace scanning, language-service requests, graph generation, and UI communication, maintaining clear contracts between components is particularly useful.

VS Code Extension API

The VS Code Extension API provides the foundation for Asterism.

It gives the extension access to the development environment it is running inside.

Asterism uses VS Code capabilities for things such as:

Workspace interaction
File-system events
Commands
Activity Bar integration
Sidebar views
Language-service/provider functionality
Editor interaction
Theme information

This lets Asterism behave as part of VS Code rather than as an entirely separate application.

Language-Service Provider Commands

The language layer is one of the most important parts of the architecture.

Rather than parsing every language independently, Asterism uses VS Code's available language-service capabilities to discover relationships.

Conceptually, the extension asks questions such as:

What symbol is this?
       ↓
Where is it defined?
       ↓
What references it?
       ↓
What does it call?
       ↓
What calls it?
       ↓
What types are related to it?

The exact information available can vary depending on the language extension and language server.

That variability is an important part of the architecture.

Cytoscape.js

Once relationships have been discovered, Asterism needs a way to render them.

For this, it uses Cytoscape.js.

Cytoscape.js is designed for interactive graph and network visualization.

Asterism represents code relationships using graph concepts:

Node  = code entity
Edge  = relationship

For example:

UserController ──calls──> UserService

or:

AdminController ──inherits──> BaseController

This creates a natural mapping between software architecture and graph structures.

fCoSE Layout

They also need to be positioned in a way that makes relationships understandable.

Asterism uses the fCoSE graph layout to organize graph structures.

The purpose of the layout is to produce a more readable arrangement of interconnected nodes, particularly when grouping structures are involved.

This matters because graph visualization is partly a data problem and partly a spatial problem.

The same relationships can be much easier or harder to understand depending on how they are arranged visually.

Webviews

Asterism's interactive graph interface runs through a VS Code Webview.

This provides a bridge between the VS Code extension environment and web-based UI technologies.

Conceptually:

VS Code Extension
       │
       │ messages / data
       ▼
     Webview
       │
       ▼
Cytoscape.js Graph

This allows the graph interface to provide interactive behaviors such as:

Selecting nodes
Searching
Filtering
Collapsing
Tracing
Navigating

while remaining inside VS Code.

Activity Bar and Sidebar

The Activity Bar provides the primary entry point for the extension.

The sidebar handles workspace exploration and file selection.

This separation is useful because it keeps two different concerns distinct:

Sidebar

"What part of the project do I want to investigate?"

Graph

"How is that part of the project connected?"

VSIX Packaging

Asterism is packaged as a VSIX, the standard packaging format for VS Code extensions.

This allows users to install the extension directly into VS Code.

The same packaging approach also makes it possible to distribute the extension through the VS Code ecosystem.

Language Support Through VS Code

Asterism's language strategy is worth emphasizing.

It isn't designed around the assumption that one parser can understand every programming language.

Instead:

Asterism
   │
   ▼
VS Code Language APIs
   │
   ▼
Installed Language Extension
   │
   ▼
Language Server

This provides an abstraction layer.

For example, Asterism doesn't necessarily need to know every syntactic rule of a language in order to ask:

"What calls this function?"

The language service may already know that.

Asterism's responsibility becomes:

Request relationship information.
Interpret the returned information.
Convert it into a common internal graph representation.
Render that representation.
Let the developer interact with it.

This is one of the architectural choices that makes the project interesting to me.

Design and Usability Decisions

Technical functionality is only part of building a developer tool.

The other challenge is making the functionality easy to use.

Simple Entry Point

The Activity Bar provides an obvious place to start.

Developers don't need to learn a complicated command sequence before seeing the extension.

Automatic Workspace Scanning

Workspace scanning happens automatically.

This removes an additional setup step and allows the sidebar to immediately represent the project.

Fast Path from File to Graph

The sidebar is designed around a simple interaction:

Find file → Click file → Explore graph

That keeps graph generation close to the user's existing project navigation workflow.

Grouping and Collapsing

Large graphs can quickly become unreadable.

Grouping and collapsing allow developers to move between different levels of abstraction.

You can think of this as:

Workspace
   ↓
Folder
   ↓
File
   ↓
Class
   ↓
Method

The user can decide how much detail is appropriate for the current investigation.

Theme Integration

A developer tool should feel native to its host environment.

Asterism supports:

Light themes
Dark themes
High-contrast VS Code themes

This allows the graph interface to adapt to the developer's VS Code environment.

Workspace File Updates

Projects change constantly.

Files can be:

Created
Edited
Renamed
Deleted

Asterism responds to these workspace changes and refreshes the file representation accordingly.

This avoids treating the workspace as a static snapshot.

Performance Considerations

Visualizing code relationships introduces practical limitations.

Theoretically, a graph can contain a huge number of nodes and edges.

Practically, that doesn't mean displaying everything at once is a good user experience.

Asterism therefore applies limits intended to keep the interface usable.

For example, it can limit the number of files and graph nodes involved in analysis.

It also skips common generated or dependency-heavy directories such as:

node_modules/
dist/
build/
.venv/
venv/

These directories can contain large amounts of code that generally isn't useful when initially exploring the application's own source.

Language Server Startup

Another practical consideration is that language servers may need time to initialize.

If a language service is still loading or hasn't finished analyzing a workspace, the information returned to an extension may be incomplete.

Therefore, the graph should not always be interpreted as an absolute representation of every relationship in the workspace at every instant.

The quality of the results depends on the language support available in VS Code.

Large Workspaces

Very large workspaces may require adjusting configuration such as:

Maximum files
Call depth
Graph limits

The objective isn't to claim that every codebase can be visualized without constraints.

The objective is to provide useful exploration while recognizing that code analysis and graph rendering both have practical boundaries.

Development Process and AI-Assisted Coding

Asterism began from my original idea and core concept.

I defined the overall direction of the project, including:

The product concept
Technical direction
Feature requirements
Architecture decisions
User experience decisions
Testing decisions
Branding
Integration requirements
Packaging and release preparation

During implementation, I used GPT-5.6 LUNA Agentic Coding as a development assistant.

The AI-assisted workflow helped with areas such as:

Exploring implementation approaches
Generating and refining code
Debugging
Iterating on features
Reasoning through technical problems
Improving implementation details

However, this was an AI-assisted development process, not an AI-owned project.

The project direction, decisions, evaluation, testing, integration, and final development responsibility remained under my direction.

I think this distinction is important.

AI coding assistants can significantly change how software is developed, but using an AI tool doesn't mean the tool independently owns the product or replaces the developer's responsibility for architectural and engineering decisions.

For Asterism, I treated AI as a development partner and coding assistant while remaining responsible for the project itself.

Lessons Learned

Building Asterism highlighted several lessons that extend beyond this particular project.

1. Use Existing Language Infrastructure

One of the strongest lessons was the value of building on top of capabilities that already exist.

Creating a parser and semantic analyzer for every supported language would dramatically increase the complexity of the project.

Using VS Code's language ecosystem allows Asterism to focus more heavily on visualization and developer experience.

2. Language-Neutral Architecture Matters

Different languages have different concepts and semantics.

A language-neutral graph model provides an abstraction:

Language-specific information
           ↓
     Common model
           ↓
      Graph nodes
           +
      Graph edges

That separation makes it easier to think about relationships independently of syntax.

3. Mapping Language Results to Graph Nodes Is Difficult

Getting information from a language service is only half the problem.

That information needs to become stable graph entities.

For example, the system needs to reason about:

Symbol
   ↓
Definition
   ↓
File
   ↓
Position
   ↓
Graph Node

Different language servers can return information with different levels of completeness.

Connecting these results reliably is an important engineering challenge.

4. Incomplete Results Are Normal

Language services aren't guaranteed to return perfect information at every moment.

Workspaces may still be loading.

Some symbols may not resolve.

Some relationships may not be available.

A robust visualization system needs to handle these cases gracefully rather than assuming that every query returns a complete dataset.

5. Large Graphs Need Constraints

More data doesn't automatically mean more useful information.

A graph with thousands of nodes might contain valuable information but still be practically impossible to understand.

Grouping, filtering, collapsing, and sensible limits are therefore essential features rather than optional UI improvements.

6. A Simple Sidebar Workflow Matters

Developer tools compete with an existing workflow.

If a developer needs to execute several commands just to inspect one file, the tool becomes harder to adopt.

The Activity Bar → Sidebar → File → Graph workflow keeps the interaction simple.

7. Powerful Analysis vs. Readable Interface

There is always a balance.

More relationships can produce a more complete analysis.

But displaying more relationships can also produce more visual noise.

Asterism's development reinforced an important principle:

A useful developer tool isn't necessarily the one that displays the most information. It's the one that makes the important information easier to understand.

Future Improvements

Asterism's current architecture leaves room for several future improvements.

Some possibilities include:

Graph Export

Export graph views as:

This would make it easier to include visual architecture diagrams in documentation or technical discussions.

Saved Graph Views

Allow developers to save graph configurations for a workspace and return to them later.

Analysis Caching

Caching previously discovered relationships could reduce repeated analysis work in suitable situations.

External Library Visualization

External library calls could potentially appear as visually differentiated or faded nodes, helping distinguish application code from dependencies.

Advanced Dependency Analysis

Future versions could provide richer dependency relationships beyond the current graph categories.

Graph History

A history mechanism could allow developers to move backward and forward between explored graph states.

Refactoring Impact Analysis

A future impact-analysis feature could help developers investigate potential affected areas before modifying a symbol.

Project-Level Summaries

Higher-level summaries could provide a more architectural view of the project before diving into individual symbols.

More Language-Service Features

As VS Code's language capabilities evolve, Asterism can potentially make use of additional language-service functionality.

More Language Edge Cases

Automated testing around language-specific and language-server edge cases would help improve reliability across different projects and language environments.

Installation and First Use

Asterism can be installed using the VSIX package or, when available, through the VS Code Marketplace.

The general workflow is:

1. Install Asterism

Install the VSIX through VS Code, or install Asterism from the Marketplace when it is available there.

2. Open a Workspace

Open the project you want to investigate in VS Code.

3. Open Asterism

Click the Asterism icon in the Activity Bar.

4. Let the Workspace Scan

Asterism scans the workspace and builds the file representation.

5. Choose What to Explore

Select an individual file or generate a graph for the workspace.

6. Explore

Use:

Search
Filtering
Node selection
Tracing
Grouping
Collapsing

to investigate the relationships.

7. Return to Code

Double-click a symbol to jump back to its source code.

The basic loop is:

Open project
    ↓
Open Asterism
    ↓
Scan workspace
    ↓
Select file / workspace
    ↓
Generate graph
    ↓
Explore relationships
    ↓
Jump back to source

Conclusion

Large codebases aren't difficult only because they contain a lot of code.

They're difficult because the relationships between that code are distributed across thousands of individual elements.

A developer might understand every function in isolation and still struggle to understand how the entire system fits together.

That's the problem Asterism is trying to address.

By combining VS Code's language-service capabilities, TypeScript, Cytoscape.js, fCoSE, Webviews, and the VS Code Extension API, Asterism turns code relationships into an interactive visual environment.

The key idea isn't to replace source code with diagrams.

It's to provide another way of looking at the same system.

Instead of only asking:

"What does this file contain?"

developers can also ask:

"What is this connected to?"

"What calls this?"

"What does this call?"

"Which classes are related?"

"Where is this symbol used?"

"What does the surrounding architecture look like?"

That shift — from reading code exclusively as text to also exploring it as a network of relationships is the core idea behind Asterism.

And as codebases continue to grow, I think tools that help developers see software structure rather than only read it will become increasingly valuable.

Argon2 vs bcrypt vs PBKDF2 in Node.js: Which Password Hashing Algorithm Should You Use in 2026?

Dulaj Thiwanka — Fri, 31 Jul 2026 06:25:32 +0000

Introduction

Password storage is one of the most important security decisions when building a backend application.

A common mistake developers make is storing passwords using fast hashing algorithms like:

SHA256(password)
MD5(password)

These algorithms are designed to be fast, which makes them perfect for data integrity checks but terrible for password storage.

If your database is leaked, attackers can use GPUs and password-cracking tools to test billions of passwords.

Modern password hashing algorithms solve this problem by intentionally making password cracking expensive.

The three most common choices in Node.js applications are:

Argon2id
bcrypt
PBKDF2

This article explains how each works and how to implement them correctly in Node.js applications.

1. Password Hashing Flow in a Node.js Application

A secure authentication system follows this flow:

User Registration
        |
        |
        v
User enters password
        |
        |
        v
Generate random salt
        |
        |
        v
Password Hashing Algorithm
        |
        |
        v
Store Hash in Database

Example database:

{
    "email": "user@example.com",
    "password": "$argon2id$v=19$m=65536,t=3,p=4$..."
}

During login:

User Login
     |
     |
     v
Enter Password
     |
     |
     v
Retrieve Stored Hash
     |
     |
     v
Verify Password
     |
     |
     v
Allow / Reject Login

2. Argon2id Implementation in Node.js

What is Argon2id?

Argon2id is currently the recommended password hashing algorithm for new applications.

It was designed to resist:

GPU cracking attacks
Password dictionary attacks
Large-scale offline attacks

Unlike bcrypt and PBKDF2, Argon2id is memory-hard.

That means an attacker cannot simply add more GPUs to increase cracking speed.

Installing Argon2

Install the package:

npm install argon2

Basic Argon2id Password Hashing

Example:

const argon2 = require("argon2");


async function hashPassword(password){

    const hash = await argon2.hash(password,{
        type: argon2.argon2id
    });

    return hash;
}


async function verifyPassword(password,hash){

    return await argon2.verify(
        hash,
        password
    );
}

Argon2id Configuration

Production systems should configure the cost parameters.

Example:

const hash = await argon2.hash(password,{

    type: argon2.argon2id,

    memoryCost: 65536,

    timeCost: 3,

    parallelism: 4

});

Understanding Argon2 Settings

memoryCost

Controls RAM usage.

Example:

memoryCost: 65536

means:

65536 KB

≈

64 MB RAM

Higher value:

More security
+
More server memory usage

timeCost

Number of iterations.

Example:

timeCost:3

means:

Password processing happens 3 times

parallelism

Number of CPU threads.

Example:

parallelism:4

means:

Use 4 parallel lanes

Recommended Node.js Production Config

const ARGON_CONFIG = {

    type: argon2.argon2id,

    memoryCost: 65536,

    timeCost: 3,

    parallelism: 4

};

Complete User Registration Example

const argon2 = require("argon2");


async function registerUser(password){

    const passwordHash =
        await argon2.hash(
            password,
            ARGON_CONFIG
        );


    await User.create({

        password: passwordHash

    });

}

Database stores:

$argon2id$v=19$m=65536,t=3,p=4$...

The configuration is stored inside the hash.

You do not need to save:

memoryCost
timeCost
parallelism

separately.

Login Verification

async function login(password,storedHash){

    const valid =
        await argon2.verify(
            storedHash,
            password
        );


    if(valid){

        return "Login success";

    }


    throw Error("Invalid password");

}

3. bcrypt Implementation in Node.js

What is bcrypt?

bcrypt is one of the oldest and most widely used password hashing algorithms.

It is still secure when configured correctly.

Many existing Node.js applications use bcrypt.

Installing bcrypt

npm install bcrypt

Basic bcrypt Example

const bcrypt = require("bcrypt");


async function hashPassword(password){

    const saltRounds = 12;


    return await bcrypt.hash(
        password,
        saltRounds
    );

}

Understanding bcrypt Cost Factor

Example:

bcrypt.hash(password,12)

The number:

is the cost factor.

Calculation:

2^cost

Example:

cost 10

=
1024 rounds


cost 12

=
4096 rounds

Higher cost:

More secure
+
Slower login

Recommended bcrypt Configuration

const BCRYPT_ROUNDS = 12;

For high-security applications:

const BCRYPT_ROUNDS = 14;

bcrypt Verification

const match =
await bcrypt.compare(
    userPassword,
    databaseHash
);


if(match){

    console.log("Authenticated");

}

bcrypt Limitations

bcrypt has one major limitation:

Maximum password length:

72 bytes

Example:

VeryLongPassword....................

Only first 72 bytes processed

For new systems, Argon2id is usually preferred.

4. PBKDF2 Implementation in Node.js

What is PBKDF2?

PBKDF2 is a password-based key derivation algorithm.

It is commonly used in:

Enterprise systems
Banking systems
Compliance environments

Node.js already includes PBKDF2 through the built-in crypto module.

No package installation required.

PBKDF2 Example

const crypto = require("crypto");


function hashPassword(password){

    const salt =
    crypto.randomBytes(16)
    .toString("hex");


    const hash =
    crypto.pbkdf2Sync(

        password,

        salt,

        600000,

        64,

        "sha256"

    );


    return {

        salt,

        hash:
        hash.toString("hex")

    };

}

PBKDF2 Configuration

crypto.pbkdf2Sync(

password,

salt,

iterations,

keyLength,

digest

)

Example:

means:

600,000 iterations

Recommended PBKDF2 Settings

{

iterations:600000,

keyLength:64,

algorithm:"sha256"

}

PBKDF2 Verification

function verifyPassword(
password,
salt,
storedHash
){

const hash =
crypto.pbkdf2Sync(

password,

salt,

600000,

64,

"sha256"

);


return (
hash.toString("hex")
===
storedHash
);

}

5. Node.js Configuration Comparison

Algorithm	Package	Configuration
Argon2id	argon2	memory, iterations, parallelism
bcrypt	bcrypt	salt rounds
PBKDF2	crypto	iterations, key length

6. Environment-Based Configuration

Do not hardcode security settings.

Example:

.env

PASSWORD_ALGORITHM=argon2id

ARGON_MEMORY=65536
ARGON_TIME=3
ARGON_PARALLELISM=4

BCRYPT_ROUNDS=12

PBKDF2_ITERATIONS=600000

Configuration file:

module.exports={

argon2:{
memoryCost:
Number(process.env.ARGON_MEMORY),

timeCost:
Number(process.env.ARGON_TIME),

parallelism:
Number(process.env.ARGON_PARALLELISM)

},


bcrypt:{
rounds:
Number(process.env.BCRYPT_ROUNDS)
}

};

7. Migrating bcrypt Users to Argon2id

You don't need to reset every password.

Migration flow:

User Login

      |

Check bcrypt hash

      |

Password correct?

      |

Generate Argon2id hash

      |

Replace old hash

Example:

if(await bcrypt.compare(password,user.password)){


const newHash =
await argon2.hash(
password,
ARGON_CONFIG
);


user.password=newHash;

await user.save();

}

Migration happens automatically.

8. Final Recommendation for Node.js Developers in 2026

New Projects

Use:

Argon2id

Example stack:

Node.js
+
Express
+
PostgreSQL/MongoDB
+
Argon2id
+
JWT/Session
+
MFA

Existing Applications

If you already use bcrypt:

Keep bcrypt

+

Increase cost factor

+

Gradually migrate to Argon2id

Enterprise Applications

If compliance requires it:

PBKDF2-HMAC-SHA256

Final Security Checklist

A production authentication system should have:

✅ Argon2id/bcrypt/PBKDF2
✅ Unique salt per password
✅ Rate limiting
✅ Account lockout protection
✅ MFA support
✅ Password breach detection
✅ Secure session management
✅ HTTPS everywhere

Conclusion

For Node.js applications in 2026:

Argon2id is the default choice for new systems.

bcrypt remains reliable for existing applications, while PBKDF2 continues to be useful where compliance standards require it.

The best implementation is not only choosing a strong hashing algorithm but also correctly configuring it, monitoring performance, and combining it with other authentication security layers.

What 24 Hours of Non-Stop Coding Taught Me About Being a Developer

Dulaj Thiwanka — Sat, 04 Apr 2026 17:05:58 +0000

I Tried Building a Full App in 24 Hours… and It Was Way Harder Than I Expected

I’ve started more projects than I can count.

Some had amazing ideas.
Some had clean designs.
Some even had “this could actually work” potential.

But most of them had one thing in common:

They were never finished.

And if you’re a developer, you probably know this feeling a little too well.

You start strong.
You feel motivated.
You imagine the final product.

Then slowly…

You get stuck.
You overthink.
You tweak things that don’t matter.
And eventually, the project just… dies.

No deadline. No pressure. No urgency.

Just another unfinished folder sitting on your laptop.

So one day, I decided to break that pattern.

Not by learning more.
Not by watching another tutorial.

But by forcing myself into a corner.

The Challenge

I gave myself exactly 24 hours.

Not “over the weekend.”
Not “whenever I have time.”

24 real, continuous hours.

And the goal was simple:

Build a complete full-stack app. Start to finish.

That means:

Backend working
Frontend working
Database connected
Everything integrated

No fake demos. No half-built features.

Just something real.

The Stack (No Time to Experiment)

I didn’t want to waste time choosing tools, so I stuck to what I already knew:

React + Tailwind for the frontend
Node.js + Express for the backend
MySQL with Sequelize

This wasn’t about learning new tech.

This was about execution under pressure.

Hour 1–2: The Most Dangerous Phase

This part almost ruined everything.

I wasn’t coding yet.

I was thinking.

And thinking.

“Maybe I should build something unique…”
“What if I add authentication?”
“Should I make it scalable?”

It sounds productive.

But it’s actually a trap.

Because the more you think, the bigger the project becomes.

And the bigger the project becomes…

The less likely you are to finish.

Eventually, I forced myself to stop.

No more ideas. No more upgrades.

I picked something simple:

A basic task manager

Create. Update. Delete.

That’s it.

No login system. No complex features.

And honestly?

That single decision was the reason I didn’t fail.

Hour 3–8: Backend Flow State

This was probably the smoothest part of the entire challenge.

I set up:

Express server
API routes
Sequelize models
Database connection

Basic endpoints:

POST /tasks
GET /tasks
PUT /tasks/:id
DELETE /tasks/:id

Everything felt… under control.

No major bugs. No confusion.

I was in that “flow state” where things just click.

And for a moment, I genuinely thought:

“I might actually finish this early.”

Looking back, that was very optimistic

Hour 9–16: Where Everything Started Slipping

Frontend always looks easier than it actually is.

You think:

“It’s just UI.”

Until you start building it.

At first, it was fine.

I created components.
Styled with Tailwind.
Connected the API.

Then things started breaking.

Slowly.

Then all at once.

I ran into issues like:

State not updating correctly
API calls returning unexpected data
UI showing stale information
Components re-rendering in weird ways

At one point:

The database updated correctly… but the UI didn’t reflect it
Then I fixed the UI… and broke the API connection

It felt like a loop.

Fix one thing → break another.

This is the part most tutorials don’t show.

Because this is where real development happens.

Hour 17–22: The Mental Wall

This was the hardest phase.

Not because of complexity.

But because of fatigue.

After ~15 hours, your brain just slows down.

Simple bugs take longer to understand.
You reread the same code multiple times.
You start making small mistakes.

And then…

💥 CORS issues
💥 Endpoint mismatches
💥 Random errors that didn’t exist before

At one point I just stared at the screen thinking:

“Why is this even happening?”

This is where most projects die.

Not because they’re impossible.

But because the developer gives up.

Hour 23: A Shift in Mindset

Something changed here.

I stopped trying to make things “good.”

And started trying to make things work.

I asked myself:

“What is the minimum required for this app to function?”

And then I cut everything else.

No extra features
No refactoring
No polishing

Just core functionality.

This was the turning point.

Hour 24: Done… Not Perfect, But Done

And finally…

It worked.

Was it clean?
Not really.

Was it scalable?
Definitely not.

Was it something I’d proudly show in a portfolio?

Probably no.

But it was finished.

And that felt different.

Because finishing something under pressure hits in a way that slow projects don’t.

The Final App

Simple and honest:

Add tasks
Edit tasks
Delete tasks

That’s it.

No authentication.
No animations.
No “cool features.”

Just a working product.

What This Actually Taught Me

This wasn’t just a coding challenge.

It exposed how I work.

1. I Overthink Way More Than I Realize

Most of my delays weren’t technical.

They were mental.

2. Simplicity Is Not “Basic” — It’s Strategic

The smaller the scope, the higher the success rate.

3. Perfection Is Just a Delay Mechanism

Trying to make things perfect almost made me fail completely.

4. Execution Is a Skill

And like any skill, it improves under pressure.

5. Finishing Is Rare

Starting is easy.

Planning is easy.

Learning is easy.

But finishing?

That’s what separates people.

Would I Do It Again? 🤔

Yes.

But smarter.

Next time I would:

Define scope faster
Cut features earlier
Focus only on what matters

Because this challenge isn’t about building something impressive.

It’s about proving one thing:

You can finish what you start.

If You’re Still Reading…

Try this.

Seriously.

Give yourself 24 hours.

No extensions. No excuses.

Build something.

And when you’re done, ask yourself:

“Did I actually finish… or did I overthink again?”

The Ultimate Guide to Browser Storage: LocalStorage, IndexedDB, Cookies, and More

Dulaj Thiwanka — Thu, 12 Mar 2026 08:02:04 +0000

Modern browsers have evolved far beyond simple document viewers. Today they function almost like miniature operating systems running inside your computer. They manage memory, execute applications, cache resources, and even host databases.

One of the most powerful capabilities browsers provide is client-side storage the ability to store data directly on the user’s device.

Client-side storage allows web applications to:

Reduce server requests
Improve performance
Persist user preferences
Enable offline experiences
Cache network resources
Store complex application data

Without browser storage, modern web applications like Gmail, Notion, Spotify Web, and Figma would be significantly slower and far less capable.

In this article, we’ll explore the most important browser storage mechanisms available today:

Local Storage
Session Storage
Extension Storage
IndexedDB
Cookies
Cache Storage
Storage Buckets

Understanding these systems helps developers choose the right tool for each type of data.

Why Browser Storage Exists

Before diving into each storage system, it’s helpful to understand why browsers need storage mechanisms in the first place.

Early web applications relied entirely on servers. Every user action required a network request, and every piece of state lived on the server.

This approach had several problems:

High latency
Server overload
No offline capability
Poor user experience

Client-side storage solves these issues by allowing applications to store data locally.

For example:

A theme preference can be stored locally instead of requested every time.
Cached assets can load instantly without network requests.
Entire applications can function offline.

Modern browsers therefore provide multiple storage systems designed for different types of data.

1. Local Storage

Local Storage is the most widely known browser storage API. It provides a simple way to store persistent key–value data inside the browser.

The stored data remains available even after:

Page reloads
Browser restarts
System restarts

This makes Local Storage ideal for storing small pieces of persistent application state.

Characteristics

Key–value storage
Stores strings only
Persistent across sessions
Around 5–10 MB per origin
Synchronous API

The synchronous nature means Local Storage operations block the main thread, which is why it should only be used for small data.

Basic Usage

// Save data
localStorage.setItem("username", "dulaj");

// Retrieve data
const username = localStorage.getItem("username");

// Remove item
localStorage.removeItem("username");

// Clear all data
localStorage.clear();

Since Local Storage only stores strings, objects must be serialized using JSON.

const user = { name: "Dulaj", age: 23 };

localStorage.setItem("user", JSON.stringify(user));

const storedUser = JSON.parse(localStorage.getItem("user"));

Storage Scope

Local Storage is scoped by origin, which means:

protocol + domain + port

For example:

https://example.com

A different subdomain or port creates a different storage space.

Common Use Cases

Local Storage is commonly used for:

UI preferences
Theme settings
Language configuration
Feature flags
Remembering user interface states

However, Local Storage is not suitable for large datasets or high-frequency operations.

2. Session Storage

Session Storage is extremely similar to Local Storage but with a shorter lifespan.

Instead of persisting across browser restarts, Session Storage exists only during the lifetime of a browser tab.

Once the tab closes, the stored data is permanently deleted.

Characteristics

Key–value storage
Stores strings
Scoped per tab session
Around 5 MB capacity
Synchronous API

Each tab has its own isolated session storage, meaning two tabs from the same website do not share session data.

Example

sessionStorage.setItem("step", "2");

const step = sessionStorage.getItem("step");

Use Cases

Session Storage is useful when the stored data should not persist permanently.

Examples include:

Multi-step form progress
Temporary UI states
Checkout process data
Navigation history state

If the user refreshes the page, the data remains. If the tab closes, the data disappears.

3. Extension Storage

Browser extensions operate in a different environment than normal web pages. Because of this, browsers provide a dedicated Extension Storage API.

This API allows extensions to store configuration data, cached content, and synced settings.

Types of Extension Storage

Most browsers support three storage types:

storage.local

Stores data locally on the user's device.

storage.sync

Synchronizes data across devices using the browser account.

For example:

Chrome sync
Firefox sync

storage.session

Temporary storage for the extension session.

Example

chrome.storage.local.set({ theme: "dark" });

chrome.storage.local.get("theme", (result) => {
  console.log(result.theme);
});

Unlike Local Storage, Extension Storage APIs are asynchronous, making them more suitable for larger data operations.

Common Use Cases

Extensions use storage for:

User settings
Feature toggles
Cached extension data
Syncing configuration across devices

4. IndexedDB

When developers need to store large amounts of structured data, IndexedDB becomes the primary solution.

IndexedDB is a transactional NoSQL database built directly into the browser.

It allows developers to store complex data such as:

Objects
Files
Blobs
Structured datasets

Key Concepts

IndexedDB introduces several database concepts:

Database

The top-level container for stored data.

Object Store

Similar to tables in relational databases.

Index

Allows fast lookup of records.

Transaction

Ensures safe and consistent database operations.

Example

const request = indexedDB.open("AppDatabase", 1);

request.onupgradeneeded = (event) => {
  const db = event.target.result;

  const store = db.createObjectStore("users", {
    keyPath: "id"
  });

  store.createIndex("email", "email", { unique: true });
};

Once created, the database can store large volumes of structured data.

Advantages

IndexedDB provides several benefits:

Asynchronous API
Large storage capacity
Efficient querying through indexes
Offline functionality
Structured data storage

Real-World Usage

Many major applications rely on IndexedDB:

Gmail (offline email storage)
Google Docs
Notion
Figma
Progressive Web Apps

IndexedDB allows web apps to behave much more like native applications.

5. Cookies

Cookies are the oldest form of browser storage, originally designed to maintain state across HTTP requests.

HTTP itself is stateless, meaning each request is independent. Cookies solve this by storing small pieces of data that the browser automatically sends with each request.

Characteristics

Maximum size: ~4 KB
Automatically included in HTTP requests
Can have expiration times
Supports security flags

Example

document.cookie = "theme=dark; path=/; expires=Fri, 31 Dec 2026 12:00:00 UTC";

Security Flags

Cookies can be configured with additional security options.

HttpOnly

Prevents JavaScript access.

Secure

Only sent over HTTPS.

SameSite

Controls cross-site request behavior.

Example:

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict

Use Cases

Cookies are commonly used for:

Authentication sessions
Tracking identifiers
Personalization
Server-side preferences

Because cookies are included with every request, they should contain minimal data.

6. Cache Storage

Cache Storage is part of the Service Worker API and is designed for storing network resources.

Instead of storing arbitrary data, it stores HTTP request–response pairs.

This enables developers to implement custom caching strategies.

Example

const cache = await caches.open("app-cache");

await cache.add("/index.html");
await cache.add("/styles.css");
await cache.add("/app.js");

When a user visits the site again, the cached version can be served instantly.

Benefits

Cache Storage enables:

Offline web applications
Faster loading times
Reduced server load
Advanced caching strategies

Common Strategies

Cache First

Use cache before network.

Network First

Try network first, fallback to cache.

Stale While Revalidate

Serve cached version while fetching an updated version in the background.

These strategies are widely used in Progressive Web Apps (PWAs).

7. Storage Buckets

Storage Buckets are a relatively new browser storage concept aimed at improving storage management.

Instead of storing all application data in one shared space, developers can create separate logical buckets.

Each bucket can have its own:

Lifetime
Storage quota
Eviction priority

Example structure:

App Storage
├── user-data
├── cache
└── temporary-files

If the browser needs to free space, it can remove lower priority buckets first.

This prevents critical application data from being deleted unexpectedly.

Storage Buckets are still evolving but represent a major improvement in browser storage architecture.

Comparison of Browser Storage Options

Storage Type	Persistence	Capacity	Data Type
Local Storage	Persistent	~5–10 MB	Strings
Session Storage	Tab lifetime	~5 MB	Strings
Cookies	Configurable	~4 KB	Strings
IndexedDB	Persistent	Large	Structured objects
Cache Storage	Persistent	Large	HTTP responses
Extension Storage	Persistent	Large	JSON-like
Storage Buckets	Managed	Large	Multiple types

How Modern Web Apps Use Browser Storage

Most production web applications combine multiple storage systems.

For example:

A Progressive Web App might use:

Local Storage for UI preferences
IndexedDB for large application data
Cache Storage for offline assets
Cookies for authentication sessions

This layered storage architecture enables fast, responsive, and reliable web applications.

Final Thoughts

Browser storage has evolved dramatically over the past decade. What once started as simple cookies has grown into a complete ecosystem of storage technologies.

Today, browsers provide:

Key–value storage
Databases
Network caches
Offline storage systems
Structured storage management

This capability allows web applications to behave increasingly like native desktop or mobile apps.

Understanding how each storage system works — and when to use it — is a critical skill for modern web developers building scalable and high-performance applications.

Git, Explained

Dulaj Thiwanka — Tue, 03 Feb 2026 11:05:22 +0000

Git is everywhere.
Jobs expect it. Teams depend on it. Tutorials assume you already understand it.

And yet, many developers use Git daily while secretly hoping nothing goes wrong.

This article is not about memorizing commands.
It’s about understanding what Git is thinking, so the commands stop feeling dangerous.

We’ll go slowly. Very slowly. On purpose.

Part 1: Why Git Exists (A Very Human Problem)

Imagine writing a document over several weeks.

You save versions like:

report.docx
report_final.docx
report_final_v3_REAL.docx

Now imagine three people editing that document at the same time.

That chaos is what Git was built to prevent.

Git exists to:

Track changes over time
Let multiple people work safely
Make mistakes reversible
Preserve context (the why, not just the what)

Git is not just backup.
Git is structured memory.

Part 2: The Mental Model That Changes Everything

Here’s the idea that makes Git stop feeling random:

Git does not track changes.
Git tracks snapshots.

Every commit is a photograph of your entire project folder at a specific moment in time.

If a file hasn’t changed, Git doesn’t store it again.
It simply points to the previous version.

This is why:

Git is efficient
Git is fast
Git history feels immutable

Once something is committed, it becomes a historical fact.

Part 3: Creating a Repository (Where Memory Begins)

git init

This creates a hidden folder called .git.

That folder contains:

Every commit
Every branch
The entire history graph
All metadata

Your code files are outside .git.
Your project’s memory lives inside .git.

If .git disappears, Git forgets everything.

Part 4: The Three Places Your Code Can Exist

This is the most important concept in Git.
If you understand this, almost everything else makes sense.

1. Working Directory

This is your normal folder.
You edit files here.
Git is watching, but nothing is saved yet.

2. Staging Area (Index)

This is where you tell Git:

“These specific changes are ready to be recorded.”

Not everything. Just what you choose.

3. Repository (Commits)

This is Git’s permanent history.
Once something is here, it’s part of the timeline.

Git never commits directly from your folder.
It commits from the staging area—because intention matters.

Part 5: Asking Git What It Sees

Before running any command, get used to this:

git status

This tells you:

What changed
What’s staged
What’s not tracked
What Git is waiting for

If Git ever feels confusing, it’s usually because git status wasn’t read.

Part 6: What `git add` Really Does

git add index.html

This does not mean “save forever”.

It means:

“Take the current version of this file and copy it into the staging area.”

You can still edit the file afterward.
The staged version will not change unless you add it again.

This lets you:

Stage only part of your work
Create clean, focused commits

Part 7: Committing (Freezing a Moment)

git commit -m "Add homepage layout"

This creates:

A snapshot
A unique hash (ID)
A permanent history point

Commits cannot be edited.
Git does not erase history—it adds to it.

Think of commits as pages in a journal.
You don’t rip out pages. You write new ones.

Part 8: Commit Messages Are for Humans

Bad messages:

fix
update
stuff

Good messages explain intent:

Fix broken layout on small screens
Add input validation for signup form
Refactor auth logic to simplify flow

Your future self will read this.
So will teammates.
Write like you’re explaining your thinking.

Part 9: Reading History Without Fear

git log

Better:

git log --oneline --graph

This shows:

Commits as nodes
Parent relationships
Branch structure

Git history is a graph, not a straight line.
That’s why merges and branches exist.

Part 10: Branches (The Safest Place to Experiment)

A branch is not a copy of your code.

A branch is:

A movable label pointing to a commit

That’s why creating branches is cheap and encouraged.

git checkout -b feature/settings

Now:

main stays stable
Your work happens safely elsewhere

Each commit moves the branch pointer forward.

Part 11: HEAD (Git’s “You Are Here” Marker)

HEAD simply means:

“This is where you are right now.”

Usually it points to a branch.
Sometimes it points directly to a commit.

Most confusion comes from not knowing where HEAD is.

When lost, ask:

What branch am I on?
What commit does it point to?

Part 12: Merging (Bringing Work Together)

When a feature is ready:

git checkout main
git merge feature/settings

Git tries to combine histories.

Two common outcomes:

Fast-forward merge (simple pointer move)
Merge commit (combining branches)

Both are normal.
History shape is a choice, not a mistake.

Part 13: Merge Conflicts (Not Errors)

A conflict means:

“Git can’t decide for you.”

Git stops.
Marks the file.
Waits.

You:

Open the file
Choose what stays
Remove conflict markers

Then:

git add .
git commit

Conflicts are collaboration points, not failures.

Part 14: Working With Other Humans (Remotes)

A remote repository is just another copy of the same timeline.

git push

“I’m sharing my history.”

git fetch

“Show me new history.”

git pull

“Combine their history with mine.”

If you’re unsure, fetch first.
Nothing breaks from fetching.

Part 15: Undoing Mistakes Calmly

Undo local file changes:

git checkout -- file.txt

Undo a commit safely:

git revert <commit>

Revert creates a new commit that cancels the old one.
History remains truthful.

Part 16: Stashing (Hiding Work Temporarily)

git stash

Git hides uncommitted changes.

git stash pop

Git restores them.

Stash is for interruptions, not long-term storage.

Part 17: Rebase (Editing the Story)

Rebase rewrites commits so history looks clean and linear.

Think of it as editing a draft before publishing.

Golden rule:

Never rebase commits others already have

Part 18: Interactive Rebase (Advanced Control)

git rebase -i HEAD~5

This lets you:

Combine commits
Rename messages
Remove mistakes
Reorder history

This is how clean histories are made.

Part 19: Reflog (The Panic Button)

git reflog

Git remembers:

Every checkout
Every reset
Every mistake

If you think something is lost, reflog usually knows where it went.

Part 20: Habits That Make Git Pleasant

Commit small changes
Write clear messages
Read git status
Don’t force-push shared branches
Respect the timeline

Final Thought

Git is strict, not cruel.

It does exactly what you tell it to do.
Nothing more.
Nothing less.

Once you understand snapshots, staging, and history, Git stops being scary and starts being dependable.

And a dependable memory is one of the most powerful tools a developer can have.

Keep committing.

Before I Write Any Code, I Do This First (A Practical Project Walkthrough)

Dulaj Thiwanka — Mon, 26 Jan 2026 07:41:35 +0000

Most people believe software projects fail because of bad code.

That’s rarely true.

They fail because:

The problem wasn’t clear
The scope was too big
Decisions were made too late
Structure was an afterthought

I used to jump straight into coding. It felt productive. It felt exciting.

But I kept hitting the same wall:

Rewriting things
Adding features endlessly
Losing motivation halfway
Abandoning projects that should have worked

Eventually, I realized something simple but uncomfortable:

If I’m confused while building, it’s because I was confused before I started.

So now, before I write any code, I structure the project carefully. This article shows exactly how, step by step, using a real project example—no tech background required.

The Example Project We’ll Use

To keep this real and relatable, let’s use a practical example:

A very simple expense-tracking app
(Not a startup, not a “next big thing” — just something useful.)

This makes it easier to see how each step affects real decisions.

Step 1: I Slow Down and Kill the “Build Something” Urge

The first thing I do is nothing.

No editor.
No framework.
No repo.

Why?

Because excitement is dangerous. When you’re excited, you say yes to everything—and regret it later.

Instead, I open a blank document and write one sentence:

“What problem am I trying to solve?”

For our example, the wrong answer would be:

“People need a finance app”

The better answer is:

“People don’t know where their money goes, and most tracking apps feel too complex to use daily.”

This sentence becomes the foundation of everything else.

Step 2: I Remove All Technical Language on Purpose

At this stage, technical words are banned.

No:

Database
API
Backend
UI
Stack

Only human language.

If I can’t explain the project without tech words, it means I don’t understand it well enough.

This step forces clarity—and clarity is power.

Step 3: I Choose a Single, Specific User

This is where many projects quietly fail.

I don’t build for:

“Everyone”
“All users”
“The market”

I build for one type of person.

For our expense app:

“A busy person who wants to quickly log expenses without thinking.”

This single decision eliminates dozens of future arguments:

Do we need advanced charts? → No
Do we need onboarding tutorials? → Minimal
Do we need customization? → Probably not

When the user is clear, complexity drops.

Step 4: I Write the User’s Day as a Story

Now I imagine the project in real life.

I write something like this:

“It’s the end of the day.
The user bought lunch and paid for transport.
They open the app.
They immediately see an ‘Add Expense’ option.
They enter amount and category.
They see today’s total spending.
They close the app feeling calm and aware.”

This story does several things:

It removes unnecessary features
It highlights the main action
It shows what really matters

If something doesn’t appear in the story, it probably doesn’t belong in version one.

Step 5: I Define the Core Promise of the Project

Now I write one sentence called the core promise:

“This app helps you quickly record expenses and see how much you spent today.”

Not five promises.
Not a feature list.

Just one promise.

Every future decision must support this sentence.
If it doesn’t, it waits.

Step 6: I Ruthlessly Cut Features (Before They Exist)

This is uncomfortable—but critical.

I create a section called:

“Things This Project Will NOT Do (Yet)”

For our example:

No monthly budgeting
No charts or graphs
No bank syncing
No user accounts
No cloud backup
No AI insights

Writing this down feels risky, but it creates focus and peace.

Instead of feeling like I’m behind, I feel intentional.

Step 7: I Break the Project Into Mental Building Blocks

Now—and only now—I think about structure.

Not code.
Not files.

Just parts.

For the expense tracker:

Input expenses
Save expenses
Show today’s total
Basic settings

That’s the entire system.

If I can’t describe the project in 4–6 blocks, it’s too big.

Step 8: I Sketch the Flow (Very Rough)

I might draw:

Boxes on paper
Arrows between screens
Or just bullet points

Example flow:

Home → Add Expense → Back to Home
Home → Today’s Summary

No design.
No polish.

Just logic.

This step catches problems early—when fixing them is cheap.

Step 9: I Write a “Project Blueprint” Document

Before coding, I always write this. Always.

Here’s what it looks like for our example:

Project Name

Simple Expense Tracker

Problem

People struggle to track daily spending because existing apps feel complex.

Target User

Busy individuals who want fast, low-effort expense tracking.

Core Promise

Log expenses quickly and see daily totals.

Main Actions

Add expense
View today’s spending

Out of Scope

Budgets, charts, syncing, accounts, analytics

Success Looks Like

A user can add an expense in under 10 seconds without confusion.

This document is my anchor.

Future me will thank present me for this.

Step 10: Only Now Do I Touch Technology

Only after everything above do I ask:

Is this web or mobile?
How simple can the tech be?
What’s the least complex solution?

Because now:

Overengineering feels silly
Decisions are obvious
Trade-offs are clear

Technology becomes a tool—not the driver.

Why This Process Works So Well

It looks slow.
It feels boring at first.

But it saves enormous time later by:

Reducing rewrites
Preventing scope creep
Making decisions easier
Increasing the chance of finishing

You trade early excitement for long-term momentum.

This Isn’t Just for Developers

This approach works for:

SaaS ideas
Freelance projects
Content platforms
Newsletters
Startups
Personal side projects

The pattern is universal:
Clarity → Structure → Execution

Final Thought

Writing code feels productive.

But knowing exactly what you’re building is what actually gets projects finished.

Now, whenever I feel stuck, I ask myself:

“Did I skip the thinking part?”

Most of the time, the answer is yes.

So I go back—before the code.

New Year, New You Portfolio Challenge Presented by Google AI

Dulaj Thiwanka — Thu, 08 Jan 2026 04:19:12 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me:

Hi! 👋 I’m Dulaj Thiwanka, a passionate and dedicated Full Stack Developer with a strong foundation in building user-centric and scalable web applications. I graduated in Information Technology and specialize in technologies like React, Node.js, cloud services, and modern development tools. I enjoy solving complex problems, creating meaningful software solutions, and continuously expanding my skills—especially in areas like AI, prompt engineering, and cloud technologies.

Beyond coding, I’m an avid learner and explorer—whether it’s new tech, creative problem-solving, or connecting with others who share similar goals. My portfolio showcases the projects I’ve built, from full-stack applications and IoT systems to RESTful APIs and dynamic user interfaces, with the aim of expressing my growth, versatility, and commitment to impactful tech. Through this portfolio, I hope to communicate not just what I can do, but what I’m eager to create next—whether that’s collaborating on meaningful projects, contributing to open-source, or pushing the boundaries of what technology can achieve.

Portfolio:

How I Built It:

This project was built using React with ViteJS for a fast, modern development experience and optimized performance. Tailwind CSS was chosen to create a clean, responsive, and consistent UI while allowing rapid iteration and customization.

From a design perspective, I focused on simplicity, usability, and scalability—keeping the interface minimal while ensuring smooth user interaction and clear visual hierarchy. Components were structured to be reusable and maintainable, following best practices in modern frontend development.

For AI integration, I embedded the Google Gemini API to enhance functionality with intelligent, context-aware responses. This allowed the application to demonstrate real-world AI usage, combining frontend performance with powerful generative AI capabilities.

Overall, my development process emphasized modular architecture, performance optimization, and seamless AI integration, resulting in a polished and future-ready application.

What I'm Most Proud Of:

I’m most proud of successfully integrating Google’s Gemini API into a modern React application and making AI feel both accessible and practical within a clean user experience. Turning a powerful generative AI tool into something intuitive for users was a key achievement.

From a technical standpoint, I’m proud of the performance and structure of the application—using ViteJS for fast builds, React component reusability, and Tailwind CSS for a responsive, visually consistent design. The project maintains a good balance between functionality and simplicity.

I’m also proud of the overall development workflow, from planning the UI and component architecture to embedding AI features in a scalable way. This project represents my growth as a developer and my ability to combine modern frontend technologies with real-world AI integration to build meaningful, future-ready applications.

JWT vs OAuth: Why Everyone Argues, and Almost Everyone Is Slightly Wrong

Dulaj Thiwanka — Thu, 08 Jan 2026 04:06:38 +0000

JWT vs OAuth: Why Everyone Argues, and Almost Everyone Is Slightly Wrong

At some point, usually after your first “secure” API ships to production, a quiet dread appears.

You open your auth middleware.
You stare at a token.
You wonder if you actually understand why this works.

Then the question arrives:

“Are we using JWT… or OAuth?”

The problem is not the question.
The problem is that the internet answers it like a shouting match instead of a conversation.

So let’s have the conversation.

Why This Topic Refuses to Stay Simple

JWT and OAuth live in the same ecosystem:

both deal with tokens
both show up in authentication flows
both are involved in “secure APIs”

That overlap tricks people into thinking they solve the same problem.

They don’t.

They solve different problems at different layers, and the confusion only exists because we keep collapsing layers to move faster.

Speed is fun. Security remembers everything.

JWT: A Token That Refuses to Be Forgetful

A JSON Web Token (JWT) is a self-contained, verifiable data package.

It says:

“Here are some claims.
Here’s proof they haven’t been altered.”

Nothing more. Nothing less.

A JWT has three parts:

header.payload.signature

The header says how the token was signed
The payload contains claims (user ID, roles, expiration, etc.)
The signature proves integrity

The Seduction of Statelessness

JWT’s biggest selling point is statelessness.

The server doesn’t remember sessions.
It just verifies math.

That means:

no session store
no sticky sessions
easy horizontal scaling

This is why JWT exploded alongside microservices and cloud-native systems.

But stateless does not mean consequence-free.

The Trade-Off JWT Makes (And Never Warns You About)

JWT trades control for performance.

Once issued:

the server can’t easily revoke it
the token lives until it expires
whoever has it is the user

This is fine when:

tokens are short-lived
scopes are narrow
refresh strategies are sane

It’s dangerous when:

tokens last days or weeks
secrets leak into payloads
JWT is treated like a magical session replacement

JWT is a sharp knife.
It cuts beautifully.
It does not ask permission.

OAuth: The Art of Delegated Trust

OAuth is not about identity.

OAuth is about permission.

It exists to answer one specific question:

“Is this application allowed to access that resource on behalf of this user?”

That’s it.
No identity. No emotions. Just boundaries.

OAuth introduces formal roles:

Resource Owner – the user
Client – the application
Authorization Server – issues tokens
Resource Server – protects data

This structure feels heavy because trust is heavy.

Why OAuth Feels Complicated (Because It Is)

OAuth wasn’t designed for:

small apps
solo projects
“just log the user in”

It was designed for:

ecosystems
third-party access
companies that do not trust each other (correctly)

OAuth assumes:

multiple apps
limited permissions
tokens that can be revoked
scopes that matter

It’s verbose because ambiguity is dangerous.

The Moment Everyone Gets Fooled: “Login With Google”

Here’s the twist that breaks brains:

When you “log in” with Google, you’re not using OAuth alone.

You’re using OpenID Connect (OIDC).

OIDC is an identity layer on top of OAuth 2.0.

OAuth says:

“This app may access this resource.”

OIDC adds:

“And here is who the user actually is.”

Without OIDC, OAuth does not authenticate humans.
It authorizes software.

How JWT, OAuth, and OIDC Actually Work Together

This is the real-world flow most systems use, even if they don’t realize it:

User authenticates via OIDC
Authorization server validates identity
An access token is issued
That access token is often a JWT
APIs verify the JWT signature locally

JWT becomes the container.
OAuth defines who may receive it.
OIDC defines who the user is.

This is not redundancy.
This is layering.

Access Tokens vs Refresh Tokens (Where Many Breaches Begin)

Not all tokens are equal.

Access tokens
- short-lived
- sent with every request
- frequently JWTs
Refresh tokens
- long-lived
- never sent to APIs
- used only to obtain new access tokens

If your refresh token leaks, you have a real problem.

If your access token leaks, expiry limits the blast radius.

Security is about containing damage, not preventing mistakes.

When JWT Alone Is Enough

JWT-only authentication is reasonable when:

you control the entire system
users don’t need third-party login
permissions are simple
tokens expire quickly

This is common in:

internal tools
early-stage products
mobile apps with a single backend

JWT shines in closed worlds.

When OAuth/OIDC Is Worth the Pain

OAuth and OIDC earn their keep when:

users expect social login
multiple clients exist (web, mobile, partners)
APIs are exposed externally
access must be scoped and revocable

OAuth is not overengineering.
It’s honest engineering.

Persistent Myths That Refuse to Die

“JWT is more secure than OAuth”
They solve different problems. Stop comparing them.

“OAuth replaces JWT”
OAuth frequently uses JWT as its token format.

“JWT payloads are private”
They are readable. Assume visibility.

“Stateless means simpler”
Stateless means fewer knobs when things go wrong.

The Mental Model That Actually Works

If nothing else sticks, let this one stick:

JWT → how claims are packaged
OAuth → who may access what
OIDC → who the user is

Once you separate those layers, the noise fades.

Final Thought: Security Is Memory

Security systems are not about clever code.
They are about remembering past decisions under pressure.

JWT remembers claims.
OAuth remembers permissions.
OIDC remembers identity.

Confusion happens when we forget why each one exists.

Clarity is not optional here.
It’s the difference between a clean audit and a long incident report.

And incident reports are never written at pleasant hours.

Read on Medium : Medium Article

Vibe Coding: Shipping Code While the Brain Is Still Happy

Dulaj Thiwanka — Wed, 10 Dec 2025 09:40:20 +0000

You know that moment when everything clicks?

The editor feels fast.
The idea is clear.
You’re not googling every 30 seconds.
The code is flowing and you don’t want to stop.

That’s the vibe.

Vibe Coding is leaning into that state instead of fighting it with over-engineering, premature rules, and 12 tabs of documentation you didn’t need yet.

What Is Vibe Coding (In Plain Dev Terms)

Vibe Coding isn’t a framework.
It’s not “cowboy coding”.
It’s not an excuse to ship garbage.

It’s a way of working where you optimize for:

Flow
Momentum
Mental clarity
Enjoyment

You write code that makes sense right now, and you trust yourself to make it better later.

The Core Things That Make Up Vibe Coding

Think of Vibe Coding as a small toolkit, not a philosophy lecture.

1. Momentum Over Perfection

If you stop every 5 minutes to “do it properly”, you kill the idea before it’s alive.

Get it working first.
Make it pretty later.

2. Low Cognitive Load

Your brain has limited RAM.

Vibe Coding means:

Fewer abstractions early
Fewer files at the start
Obvious names over clever ones
Straight lines instead of fancy patterns

Simple code = more brain space for the actual problem.

3. Feedback Loops That Are Instant

Fast feedback keeps the vibe alive.

Hot reload
Live preview
Console logs (yes, really)
Visual output over theory

If feedback is slow, motivation dies quietly.

4. Code That Feels Readable

Not “enterprise clean”.
Not “leetcode clever”.

Just:

“Yeah… I get what this does.”

Readable code keeps you in flow longer.

5. Emotional Awareness (Underrated Skill)

Vibe Coding includes noticing:

When you’re tired
When you’re forcing it
When flow is gone

Pushing through bad mental states usually creates bad code.

Stopping is a skill.

How to Actually Practice Vibe Coding (Step-by-Step)

This is the part most articles skip.

Step 1: Start Before You Feel Ready

If you wait for the perfect plan, you’ll never start.

Open the editor.
Create the file.
Write the ugly first version.

Motion creates clarity.

Step 2: Build the “Stupid Version” First

Ask:

“What’s the dumbest possible version that works?”

Hardcode things.
Duplicate code.
Ignore edge cases.

You’re sketching, not painting.

Step 3: Stay in One Mental Mode

Don’t mix:

Designing
Optimizing
Refactoring
Naming perfectly

Pick one mode.
Vibe Coding mode = build mode.

Step 4: Let Patterns Appear Naturally

Once you see:

Repeated logic
Similar components
Copy-paste growing

That’s your signal to refactor.

Refactoring before patterns exist is just guessing.

Step 5: Refactor in Short, Focused Bursts

Refactor after momentum, not during it.

Rename things
Extract functions
Clean files
Add types/tests

Then stop.
Don’t spiral.

Step 6: Lock It Down Before Shipping

Vibe Coding ends before production.

Before shipping:

Handle edge cases
Add validation
Clean obvious messes
Remove debug junk

Vibe ≠ reckless.

Things That Help the Vibe (Surprisingly Practical)

Environment Things

Editor theme you enjoy
Font that doesn’t strain your eyes
Minimal UI clutter
Comfortable keyboard/layout

Your environment affects your thinking more than you think.

Workflow Things

One task at a time
One screen if possible
Notifications off
Clear goal for the session

Vibe dies when attention fragments.

Mental Things

Accept messy first drafts
Don’t judge code too early
Don’t compare mid-work
Treat coding like writing, not math

Drafts are allowed.

Where Vibe Coding Works Best

Vibe Coding shines in:

Side projects
MVPs
Hackathons
UI-heavy apps
Learning new frameworks
Creative experiments

It struggles in:

Safety-critical systems
Compliance-heavy apps
Massive legacy codebases

Context matters. Always.

Vibe Coding With AI (Use Carefully)

AI is amazing for:

Boilerplate
Scaffolding
Explaining errors
Unblocking flow

AI is bad at:

Architecture decisions
Product judgment
Knowing your context

Use AI to support the vibe, not replace thinking.

Common Mistakes People Make

Never refactoring
Using “vibe” as an excuse for chaos
Shipping prototypes to production
Ignoring tests forever
Coding while exhausted and angry

Vibe Coding still requires responsibility.

Final Thought

Vibe Coding is about respecting how humans actually think.

Flow beats force.
Momentum beats over-planning.
Clarity beats cleverness.

Write the code that lets you keep going.

Clean it later.
Ship it when it’s ready.
And enjoy the process — that’s usually where the best ideas show up.

Follow Me : https://medium.com/@dulthiwanka2015

Using Console Colors with Node.js: A Complete Guide for Cleaner, Smarter Terminal Output

Dulaj Thiwanka — Fri, 14 Nov 2025 10:18:14 +0000

Terminal output is the heartbeat of backend developers. Whether you're debugging a stubborn API issue, running background jobs, or building a CLI tool, the console is your most constant companion. Adding color to that output transforms a flood of text into an organized dashboard for your brain.

Node.js makes this surprisingly easy. This guide digs into how console colors really work, common libraries, advanced tricks, and practical patterns for using them effectively.

How Console Colors Work Under the Hood

Terminals support something called ANSI escape codes, tiny embedded instructions inside strings that change how text appears. These color codes have been around since the early days of UNIX.

A simple example looks like this:

\x1b[31mHello\x1b[0m

\x1b means ESC (escape).
[31m means “switch to red”.
[0m means “reset styles”.

Node.js outputs this directly to your terminal when you call:

console.log("\x1b[31mThis is red\x1b[0m");

This gives you bare-metal control, which is useful once you understand the pattern.

The Core ANSI Color Codes (Reference)

Foreground colors:

Black: \x1b[30m
Red: \x1b[31m
Green: \x1b[32m
Yellow: \x1b[33m
Blue: \x1b[34m
Magenta: \x1b[35m
Cyan: \x1b[36m
White: \x1b[37m

Background colors:

Red background: \x1b[41m
Green background: \x1b[42m
Yellow background: \x1b[43m
Blue background: \x1b[44m
Magenta background: \x1b[45m
Cyan background: \x1b[46m

Style modifiers:

Bold: \x1b[1m
Dim: \x1b[2m
Italic: \x1b[3m
Underline: \x1b[4m

Reset:

Reset all: \x1b[0m

These codes stack, which lets you do things like:

console.log("\x1b[1m\x1b[33mBold Yellow\x1b[0m");

It’s low-level, but powerful.

Using Chalk for Cleaner Syntax and Modern Features

Working with raw escape codes is like writing HTML inline styles everywhere. Chalk fixes that with a clean API.

Install:

npm install chalk

Use:

import chalk from 'chalk';

console.log(chalk.red('Error'));
console.log(chalk.green('Success'));
console.log(chalk.yellow('Warning'));
console.log(chalk.bold.blue('Info message'));

Chalk Highlights

Chalk gives you three key advantages:

Cleaner syntax
No escape code juggling.
Automatic color support detection
Some terminals don’t support color. Chalk gracefully downgrades.
Nested & chained styling
Chalk handles resets for you.

console.log(chalk.bgRed.white.bold(" Critical System Failure "));

Extended Color Support

Chalk supports 256-color and TrueColor (16 million colors):

console.log(chalk.hex('#ff8800')('Orange heading'));
console.log(chalk.rgb(150, 120, 50)('Custom tone'));

This is useful when designing CLI tools that need branding or visual structure.

Using `colors` for Inline Style Shortcuts

Install:

npm install colors

Use:

import 'colors';

console.log("Updated successfully".green);
console.log("Something went wrong".red.bold);
console.log("Check configuration".yellow.underline);

Caveat: Prototype Modification

This library modifies the String.prototype.

Great for small scripts.
Not ideal for large or shared codebases.

Using `kleur` for a Lightweight Alternative

If you want Chalk-like features with a smaller footprint:

Install:

npm install kleur

Use:

import kleur from 'kleur';

console.log(kleur.red('Error'));
console.log(kleur.bold().green('Success'));
console.log(kleur.bgYellow().black('Warning'));

kleur is fast and tiny, good for performance-sensitive CLI tools.

Formatting Output with `console` Methods

Node gives you some built-in variations:

console.error(chalk.red("Fatal error"));
console.warn(chalk.yellow("Warning"));
console.info(chalk.blue("Info"));
console.log(chalk.green("Done"));

Each has a semantic purpose:

console.error() prints to stderr
console.log() prints to stdout

This matters when scripting or logging to other processes.

Detecting If Colors Are Supported

Some environments strip ANSI codes:

Docker logs
CI systems
Windows terminal (older versions)
File exports

Chalk makes detection easy:

if (!chalk.supportsColor) {
  console.log("Your terminal doesn't support color");
}

Manual detection:

const colorSupported = process.stdout.isTTY;

Good CLI tools gracefully degrade.

Creating a Reusable Logger with Colors

A small logger can unify styles for an entire project:

import chalk from 'chalk';

const log = {
  info: (msg) => console.log(chalk.blue("[INFO]"), msg),
  success: (msg) => console.log(chalk.green("[SUCCESS]"), msg),
  warn: (msg) => console.log(chalk.yellow("[WARN]"), msg),
  error: (msg) => console.log(chalk.red("[ERROR]"), msg),
};

log.info("Server started");
log.success("Database connected");
log.warn("High memory usage");
log.error("Failed to load config");

This gives your project consistent, structured output.

Tips for Designing Color Logic

A few guidelines from writing CLI tools:

• Use color for meaning, not decoration.
• Reserve red for actual errors.
• Yellow works best for non-critical warnings.
• Magenta and cyan help differentiate categories.
• Don’t overload a single line with too many styles.
• Test output in multiple terminals.

A good rule: if every line is colorful, none of them matter.

Final Thoughts

Colored console output is more than an aesthetic trick. It’s a tight feedback loop for developers, a way of turning raw text into a readable system of symbols. Once you understand ANSI codes and the available Node.js libraries, you can design output that actually helps you think.

This small skill pays off when you build tools, monitor logs, debug servers, or shape your own development workflow. Exploring this further even opens paths into advanced CLI UI frameworks like Ink, Commander.js integration, loading spinners, progress bars, and full interactive terminal interfaces.

Color is just the beginning.

Understanding the MERN Stack for Beginners

Dulaj Thiwanka — Tue, 11 Nov 2025 04:24:29 +0000

The MERN Stack is one of the most popular and practical ways to build modern web applications. If you're interested in becoming a full-stack developer, learning MERN gives you the skills to create complete apps — everything from the visual interface to the database behind the scenes.

And the best part? You only need to know JavaScript.

This guide expands your understanding step-by-step, keeping things friendly, practical, and beginner-focused.

What is the MERN Stack?

MERN is made up of four core technologies:

Letter	Technology	What It Does
M	MongoDB	Stores your application's data
E	Express.js	Handles backend logic and API routing
R	React.js	Builds the user interface (UI)
N	Node.js	Runs JavaScript on the server

These four pieces work together to create a complete web app.

Why Learn the MERN Stack?

Uses one programming language — JavaScript — everywhere.
Easy to scale and great for real-world apps.
Huge community and lots of free learning resources.
Used by startups, tech companies, and freelancers.

If your goal is to build a portfolio that stands out, MERN projects are perfect.

MERN Architecture (How Everything Communicates)

Simple Example:

User clicks Add Task → React sends task to backend → Backend saves it in MongoDB → MongoDB stores → Backend sends confirmation → React updates screen.

This cycle is the heart of MERN.

Breakdown of Each Technology

1. MongoDB — The Database

MongoDB stores data as documents (similar to JSON):

{
  "name": "Alice",
  "age": 22,
  "isStudent": true
}

This format makes MongoDB easy to use with JavaScript.

2. Express.js — Handling APIs

Express helps you create routes like:

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

Express receives requests, processes logic, and sends responses.

3. React.js — Building the UI

React focuses on creating components.

function Welcome() {
  return <h1>Welcome to MERN Learning!</h1>;
}

React updates only the parts of the page that change — making apps feel fast.

4. Node.js — Runs Your Backend

Node allows JavaScript to run outside the browser.

node server.js

This starts your backend server.

Typical MERN Folder Structure

project/
│
├── client/           → React (Frontend)
│   ├── src/
│   └── package.json
│
├── server/           → Node + Express (Backend)
│   ├── models/       → MongoDB schemas
│   ├── routes/       → API endpoints
│   ├── server.js
│   └── package.json
│
└── README.md

Separating frontend and backend keeps your project clean.

Core Concepts You Must Learn

1. REST APIs

Your frontend talks to your backend using HTTP requests like:

GET (read data)
POST (send data)
PUT (update data)
DELETE (remove data)

2. JSON Format

This is how data travels between frontend and backend.

3. State Management in React

Examples: useState, useEffect hooks.

Basic CRUD Example (Create, Read, Update, Delete)

Backend Route Example:

// Create Task
app.post('/tasks', async (req, res) => {
  const newTask = new Task({ text: req.body.text });
  await newTask.save();
  res.send('Task saved');
});

Frontend Fetch Example:

fetch('/tasks', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ text: 'Learn MERN' })
});

Deploying a MERN App

You can host:

Frontend on Vercel / Netlify
Backend on Render / Railway
Database on MongoDB Atlas

This lets your project become public — great for portfolios.

Learning Roadmap (Beginner Friendly)

Start with:

JavaScript Basics (functions, arrays, objects)
React Basics (components, props, hooks)
Node + Express (API routes, server setup)
MongoDB (CRUD operations)
Build small projects (notes app, messenger, to-do app)

Practice is everything.

Final Thoughts

The MERN stack is powerful, modern, and approachable — perfect for anyone learning full-stack development.

Take it step-by-step, build consistently, and focus on understanding how data flows.

You're not just learning tools — you're learning how to build real applications.

Happy coding! 🚀