Forem: Abdullah al Mubin

The Diet Your App Deserves: Tree Shaking vs Dead Code Elimination

Abdullah al Mubin — Thu, 07 May 2026 18:43:15 +0000

We’ve all done this:

Install a huge library
Use ONE function
Ship 300KB of JavaScript

In modern web apps:

Shipping less code = faster apps

Two terms always come up here:

Tree Shaking
Dead Code Elimination (DCE)

They sound similar…

But they work in very different ways.

Let’s break it down with a real-world example so it actually sticks.

The Problem: Bloated Bundles
Real-World Scenario: The Overloaded App
Dead Code Elimination (DCE): The Surgeon
Tree Shaking: The Gardener
Why ES Modules Matter
Key Differences
How to Make Your Code Shakeable
Mental Model
Final Thoughts

The Problem: Bloated Bundles

Imagine your app loads slowly.

Users wait…

Bounce rate increases

You check your bundle:

500KB JavaScript

But your actual logic?

Maybe 50KB

So what happened?

Unused code is being shipped

Real-World Scenario: The Overloaded App

You’re building:

quickdash.com (a dashboard app)

You install a utility library:

import _ from "lodash";

But you only use:

js _.debounce()

What gets shipped?

The ENTIRE library

Result

Bigger bundle
Slower load time
Worse performance

This is where optimization kicks in.

Dead Code Elimination (DCE): The Surgeon

DCE is the classic optimization technique.

What it does

Removes code that will never run

Example

js if (false) { console.log("This will never run"); }

DCE removes it completely

Another Example

js function unusedFunction() { return 42; }

If never called → removed

Analogy

A surgeon removing useless organs

Precise. Logical. Necessary.

What DCE Targets

Unreachable code
Unused variables
Functions never called

It works at code level

Tree Shaking: The Gardener

Tree Shaking works differently.

What it does

Removes unused imports/modules

Example

js import { debounce, throttle } from "lodash-es";

If you only use:

js debounce()

throttle gets removed

Analogy

Shaking a tree so dead leaves fall off

Only what’s needed stays.

Key Idea

Include ONLY what you use

Works at module level

Why ES Modules Matter

Tree Shaking depends on:

ES6 modules (import/export)

Why?

Because they are:

Static (analyzable at build time)

CommonJS (bad for tree shaking)

js const lib = require("lodash");

Dynamic → bundler can’t analyze usage

ES Modules (good)

js import { debounce } from "lodash-es";

Bundler knows exactly what’s used

Key Differences

Feature	Dead Code Elimination	Tree Shaking
Level	Code / function	Module / import
Removes	Unreachable code	Unused exports
Works with	Any JS	ES Modules only
Timing	After code analysis	During bundling

How to Make Your Code Shakeable

Using a bundler isn’t enough.

You need to write shake-friendly code

1. Avoid Side Effects

Bad:

js import "./init"; // modifies global state

Bundler won’t remove it

Good

Mark in package.json:

json { "sideEffects": false }

2. Use Named Exports

Bad:

js export default { a, b, c };

Good:

js export const a = ... export const b = ...

Bundler can pick only what’s needed

3. Import Only What You Need

Bad:

js import _ from "lodash";

Good:

js import { debounce } from "lodash-es";

Smaller bundle instantly

Real Impact

Without optimization:

Large JS bundles
Slow page load
Poor mobile performance

With Tree Shaking + DCE:

Smaller bundles
Faster load times
Better user experience

Mental Model

If you remember just this:

DCE → Removes code that can’t run
Tree Shaking → Removes code you didn’t import

DCE cleans inside your code
Tree Shaking trims your dependencies

Final Thoughts

Tree Shaking and DCE are invisible…

But powerful.

They:

Reduce bundle size
Improve performance
Make apps faster

The fastest code is the code you never ship.

What About You?

Do you:

Check your bundle size?
Use tools like Webpack Analyzer?
Optimize imports?

Let’s discuss in comment...

Stop Making Users Wait: Streaming SSR Explained with a Real-World Example

Abdullah al Mubin — Fri, 01 May 2026 09:52:59 +0000

Have you ever clicked a page and just… stared at a blank screen?

For 2–3 seconds… nothing happens.

That’s the old way of Server-Side Rendering (SSR).

The server waits for everything… before sending anything.

But modern apps don’t work like that anymore.

They stream the page in parts.

Let’s break this down using a real-world example you already know:

An e-commerce product page (like Amazon).

The Problem: The All-or-Nothing Bottleneck
Real-World Scenario: Product Page Loading
The Solution: Streaming SSR
How the Page Loads in Chunks
Code Example (Next.js + Suspense)
What “Streaming” Actually Means
Why This Is a Game Changer
Mental Model
Final Thoughts

The Problem: The All-or-Nothing Bottleneck

Traditional SSR works like this:

The server gathers ALL data
Builds the FULL HTML
Sends it to the browser

Real-Life Analogy

Imagine a restaurant:

You order:

Drinks
Appetizer
Main course

But the restaurant says:

“We’ll serve everything only when the steak is ready.”

What Happens?

You sit there doing nothing
Table is empty
You get frustrated

Same Problem in SSR

If your page has:

Fast data

Product title
Images
Basic info

Slow data

Reviews
Recommendations
Personalized content

The fast data is blocked by slow data

Result

Blank screen
Slow Time To First Byte (TTFB)
Poor user experience

Real-World Scenario: Product Page Loading

Let’s say a user opens a product page.

Example:

Headphones product

The Problem

The page needs:

Navbar (fast)
Product info (medium)
Reviews (slow API)

Traditional SSR waits for ALL of this

The Solution: Streaming SSR & Suspense

Streaming SSR changes everything.

Instead of waiting for everything…
The server sends HTML in chunks

How the Page Loads in Chunks

Here’s what actually happens:

Chunk 1: Layout (Instant)

Navbar
Search bar
Page structure

Sent immediately

User feels: “Page is fast”

Chunk 2: Product Info

Product image
Price
Title

Loads next

User can already start browsing

Chunk 3: Heavy Data

Reviews
Recommendations

Loads later

Page keeps growing smoothly

Result

No blank screen
No waiting
Progressive loading

Feels instant

Code Example (Next.js + Suspense)

Here’s how you implement this:

import { Suspense } from 'react';

export default function ProductPage({ params }) {
  return (
    <div className="layout">

      {/* Loads instantly */}
      <Navbar />

      <main>

        {/* Product section */}
        <Suspense fallback={<ProductSkeleton />}>
          <ProductHero id={params.id} />
        </Suspense>

        {/* Slow section */}
        <Suspense fallback={<ReviewSkeleton />}>
          <Reviews id={params.id} />
        </Suspense>

      </main>
    </div>
  );
}

What’s Happening Here?

Each <Suspense> creates a boundary
React sends content as it becomes ready
Fallback UI prevents layout shift

You define what can load later
React handles how to stream it

What “Streaming” Actually Means

Streaming doesn’t mean:

Breaking HTML randomly into chunks

It means:

Sending logical UI pieces as they’re ready

Under the Hood

Server keeps HTTP connection open
React renders components progressively
Sends HTML + small scripts
Browser injects content in the right place

It’s like progressive page assembly

Why This Is a Game Changer

Faster First Paint

Users see something instantly

Better Perceived Performance

Even if backend is slow:

UI feels fast

Better SEO

Search engines see content earlier

Selective Hydration

Header becomes interactive first
Slow parts hydrate later

Reduced TTFB Impact

No more waiting for full page render

Mental Model

If you remember just this:

Old SSR = Wait → Send everything
Streaming SSR = Send → Continue sending

“Render now, stream the rest”

Final Thoughts

Streaming SSR is not just a performance trick.

It’s a UX improvement.

Instead of:

Blank screens
Waiting

You give users:

Instant feedback
Progressive content

The best websites don’t make users wait.
They show something immediately—and improve it over time.

What About You?

Are you using Streaming SSR yet?

Or still relying on traditional SSR?

Let’s discuss in comment...

Beyond SSR vs SSG: Partial Prerendering (PPR) Explained with a Real-World Story

Abdullah al Mubin — Fri, 01 May 2026 09:30:45 +0000

For years, frontend developers have been stuck in an annoying trade-off:

SSG (Static Site Generation): Fast, but data gets stale
SSR (Server-Side Rendering): Fresh data, but slower

It always felt like:

“Pick speed OR freshness… you can’t have both.”

But what if you didn’t have to choose?

That’s where Partial Prerendering (PPR) comes in.

The Problem: Blank Screen vs Spinner Hell
The Idea: The Swiss Cheese Model
Real-World Scenario: Buying Concert Tickets
How PPR Actually Works
Code Example (Next.js + Suspense)
Why PPR is a Game Changer
Mental Model
Final Thoughts

The Problem: Blank Screen vs Spinner Hell

Let’s say you're building something like an e-commerce site.

A user clicks on a product page.

Now depending on your rendering strategy…

❌ SSR (The Waiting Game)

The server waits to fetch:

User name
Personalized price
Cart count

Then sends the page

Result:

White screen for 1–2 seconds
User thinks: “Is this site slow?”

❌ CSR (Spinner Chaos)

The page loads instantly…

But:

Price loads later
Cart loads later
Recommendations load later

Everything appears in pieces

Result:

Layout shifts
Janky experience
Feels unpolished

So you’re stuck between:

Blank screen (SSR)
Spinner hell (CSR)

The Idea: The Swiss Cheese Model

Partial Prerendering solves this beautifully.

Think of your page like:

Swiss Cheese🧀

The solid part (cheese) = Static content
The holes = Dynamic content

What Happens?

At build time:

Static parts are pre-rendered
Dynamic parts are left as “holes”

At runtime:

Static loads instantly
Dynamic content streams in later

Best of both worlds.

Real-World Scenario: Buying Concert Tickets

Imagine you're on a ticket booking site during a huge sale.

50,000 people are trying to buy tickets at the same time.

What Loads Instantly (Static Shell)

Artist name
Event details
Venue map
Page layout

This is pre-rendered and served from CDN

What Loads Dynamically (The “Holes”)

Remaining ticket count
Your personalized price
“Buy Now” button state

What You Experience

Page appears instantly
You can already read and interact
Dynamic data fills in smoothly

Even if the database takes 1 second…

The page feels like it loaded in 0.1 seconds

How PPR Actually Works

Under the hood:

Static HTML is served immediately
Dynamic components are streamed in later
React fills in the gaps without reloading the page

This is powered by:

React Suspense
Streaming rendering

Code Example (Next.js + Suspense)

Here’s a simple example:

export default function ProductPage() {
  return (
    <main>

      {/* Static content (instant) */}
      <ProductNavigation />
      <ProductDetails />

      {/* Dynamic part (hole) */}
      <Suspense fallback={<PriceSkeleton />}>
        <DynamicUserPrice />
      </Suspense>

      {/* Another dynamic part */}
      <Suspense fallback={<RecommendationSkeleton />}>
        <RecommendedProducts />
      </Suspense>

    </main>
  );
}

What’s Happening Here?

Static components load immediately
Suspense creates “holes”
Fallback UI (skeletons) prevents layout shift
Data streams in and fills the gaps

Smooth, fast, and user-friendly

Why PPR is a Game Changer

Instant First Paint

Users see something immediately
→ Feels fast

Better SEO

Search engines see:

Titles
Content
Structure

No waiting for JavaScript

No Layout Shift

Skeletons reserve space

No jumping UI

Better Perceived Performance

Even if backend is slow:

UI feels instant

Mental Model

If you remember just this:

SSG = Everything ready early
SSR = Everything waits
PPR = Load what you can now, stream the rest

PPR = “Render now, stream later”

Final Thoughts

Partial Prerendering is a big shift in how we think about rendering.

It’s not:

Static vs Dynamic

It’s:

Static + Dynamic together

The future of the web isn’t about loading pages.
It’s about making them feel instant.

What Do You Think?

Are you planning to try PPR in your next project?

Or still sticking with SSR/CSR?

Let’s discuss in comment...

PostgreSQL Design at Scale: Normalization vs JSONB (A Real-World Guide)

Abdullah al Mubin — Tue, 21 Apr 2026 17:00:25 +0000

When you start building an app, everyone gives the same advice:

“Normalize your database.”

And they’re right… at the beginning.

But once your app starts scaling?

That same “clean design” can become your biggest bottleneck.

This is where denormalization (especially JSONB in PostgreSQL) becomes a powerful tool.

Let’s break this down with a real-world example.

The Scenario: A High-Traffic Food Delivery App
Part 1: Normalization — The Clean Approach
The Problem with JOINs at Scale
Part 2: Denormalization (JSONB) — The Fast Approach
Better Query Example (Real-World)
The Trade-Off (This Is Important)
When Should You Use JSONB
When to Use Normalization
Hybrid Approach
JSONB Indexing
Final Thoughts

The Scenario: A High-Traffic Food Delivery App

Imagine you built:

bitedash.com

At scale:

Millions of users
Millions of orders
Heavy traffic during peak hours

Now a user opens:

“Order History”

Seems simple, right?

But under the hood, your database might be struggling.

Part 1: Normalization — The Clean Approach

Normalization is like a perfectly organized filing system.

Every piece of data has exactly one place.

Typical Schema

You design your database like this:

orders
order_items
products
users

Everything is clean, structured, and reusable.

The Problem with JOINs at Scale

To show one "Order History" page, PostgreSQL has to:

Join orders
Join order_items
Join products
Join users

That’s a 4-table JOIN

At Small Scale

Works perfectly.

At Large Scale

When your database grows:

Orders → 10 million rows
Order_items → 50 million rows

Every request now requires expensive JOIN operations

The Cost

High CPU usage
Slower queries
Increased latency
Poor user experience

Mental Model

Normalization = Clean but computationally expensive at scale

Part 2: Denormalization (JSONB) — The Fast Approach

Now let’s flip the approach.

Instead of storing data separately…

Store everything together.

What is JSONB?

In PostgreSQL:

Binary JSON format
Faster than plain JSON
Supports indexing
Efficient querying

New Schema

Instead of multiple tables:

You store everything inside one table:

orders

With a column:

order_details (JSONB)

Example Data

{
  "items": [
    { "name": "Pizza", "price": 15 },
    { "name": "Coke", "price": 2 }
  ],
  "user_name": "John Doe",
  "user_id": 123,
  "total": 17.00
}

The Result

SELECT order_details FROM orders WHERE user_id = 123;

No JOINs
Single query
Extremely fast

Why It’s Fast

One row fetch
No table stitching
Less CPU work

Mental Model

JSONB = Pre-packaged data ready to serve

Better Query Example (Real-World)

Let’s say your product team asks:

“Show all orders where the user bought Pizza and total is greater than $10”

With Normalization

SELECT o.id, o.total
FROM orders o
JOIN order_items oi ON oi.order_id = o.id
JOIN products p ON p.id = oi.product_id
WHERE p.name = 'Pizza'
AND o.total > 10;

Problem

Multiple JOINs
Large tables
Slower at scale

With JSONB (use numeric cast for totals)

SELECT order_details
FROM orders
WHERE (order_details->>'total')::numeric > 10
  AND order_details @> '{"items":[{"name":"Pizza"}]}';

More robust match using jsonb_path_exists (recommended for arrays of objects)

SELECT order_details
FROM orders
WHERE (order_details->>'total')::numeric > 10
  AND jsonb_path_exists(
        order_details,
        '$.items[*] ? (@.name == "Pizza")'
      );

jsonb_path_exists is more flexible for matching nested arrays/objects than the simple @> containment operator.

Add Index for Speed

-- GIN index for general JSONB containment/search
CREATE INDEX idx_orders_order_details_gin ON orders USING GIN (order_details);

-- Expression index for numeric total (fast range/greater-than queries)
CREATE INDEX idx_orders_total_numeric ON orders (((order_details->>'total')::numeric));

Result

Fast filtering
No joins
Efficient queries

The Trade-Off (This Is Important)

Feature	Normalization	JSONB (Denormalization)
Read Speed	Slower (JOINs)	Very fast (single read)
Write Speed	Faster (small rows)	Slower (large JSON writes)
Data Integrity	Strong (FK constraints)	Risk of inconsistency
Storage	Efficient	Larger (data duplication)

There is no “perfect” solution. It’s always a trade-off.

Part 3: When Should You Use JSONB?

Use JSONB strategically, not everywhere

Use JSONB for: “Snapshots of the Past”

Example:

A user places an order.

Tomorrow:

Pizza price changes
Product name changes

If you rely on JOINs:

Old orders will show new values and its Wrong

Solution

Store order as JSONB:

Captures exact state at that moment
Keeps historical data correct
Makes reads extremely fast

Benefits

Accurate history
Faster dashboards
Better scalability

Part 4: When to Use Normalization

Normalization is still critical.

Use it for live, changing data.

Examples

User accounts
Passwords
Emails
Inventory
Account balances

Why?

You need a single source of truth

You cannot afford:

Duplicate data
Inconsistent updates

Part 5: The Hybrid Approach (Best of Both Worlds)

At scale, real systems use both approaches together.

Example Architecture

Users → Normalized
Products → Normalized
Orders → JSONB snapshot

Practical performance note

If you frequently filter by fields inside the JSONB (for example user_id or total), store those as first-class columns too:

orders.user_id (bigint)
orders.total (numeric)

Then keep order_details (JSONB) as the immutable snapshot. This gives you indexable scalars for fast filters/ranges and a JSON snapshot for state and flexible reads.

Result

Fast reads
Data consistency
Scalability

Pro Tip: Indexing JSONB

You can still make JSONB queries fast.

CREATE INDEX idx_order_user_name 
ON orders ((order_details->>'user_name'));

What this does:

Fast search inside JSON
Works like a normal column index

Combine GIN indexes for general JSONB containment with expression indexes for frequently filtered scalars.

Mental Model

Normalization = Clean + consistent
JSONB = Fast + flexible

Final Thoughts

Database design is always a balancing act.

Early stage:

Normalize everything

At scale:

Denormalize strategically

The best systems aren’t fully normalized or fully denormalized.
They’re carefully designed hybrids.

WebRTC vs WebSocket Explained: When to Use What (A Real-World Story)

Abdullah al Mubin — Sat, 18 Apr 2026 07:06:04 +0000

If you’re building real-time apps, you’ve probably heard of WebSocket and WebRTC. At first, they seem similar:

Both enable real-time communication
Both avoid constant HTTP requests
Both feel “live”

But in reality? They solve very different problems. Let’s break it down the simplest way possible using a real world story you won’t forget.

The Scenario: A Remote Team Workspace

Imagine you built a product called worksync123.com.

Your team uses it for:

Chatting
Notifications
Video meetings

Rahim (Engineer) and Aisha (Product Manager) are working together.

Part 1: Chat System (WebSocket World)

Rahim sends a message:

“Hey, did you push the latest code?”

Aisha instantly sees it. No refresh. No delay.

How does this work?

Instead of making repeated HTTP requests, the app opens a persistent connection. Think of it like a phone call that stays open, not sending a new letter every time.

What WebSocket Does

Creates a continuous connection between client and server
Allows instant two-way communication
Server can push updates anytime

Perfect for:

Chat apps
Notifications
Live dashboards
Multiplayer game state

Simple Code Idea

const socket = new WebSocket("wss://worksync123.com")

socket.onmessage = (event) => {
  console.log("New message:", event.data)
}

socket.send("Hello from Rahim")

Mental Model

WebSocket = Live messaging pipe between client and server

Part 2: Video Meeting (WebRTC World)

Now Rahim clicks “Start Meeting”. Aisha joins the same room. They turn on cameras.

Does WebSocket handle this?

No. Because video is:

Heavy
Continuous
Requires low latency
Needs direct peer connection

WebRTC Enters

Instead of sending video through the server, WebRTC connects users directly. Think of it like people sitting in the same meeting room rather than passing video through a middle office.

What Happens Behind the Scenes

Exchange info via server (signaling)
Try direct connection (STUN)
Use fallback if needed (TURN)
Start streaming video peer-to-peer

Mental Model

WebRTC = Direct video/audio pipe between users

WebSocket vs WebRTC (Simple Comparison)

Feature	WebSocket	WebRTC
Connection Type	Client ↔ Server	Peer ↔ Peer
Use Case	Data / messages	Media (video / audio)
Latency	Low	Ultra-low
Server Load	High (all data passes through server)	Low (direct communication)
Complexity	Simple	Complex
Protocol	TCP-based	UDP-based (mostly)

Real World Mapping

Chat Feature

Rahim sends message → Server → Aisha

Uses WebSocket

Video Call

Rahim camera → Aisha directly

Uses WebRTC

How They Work Together (Important)

Here’s the part most beginners miss: WebRTC still needs WebSocket for signaling. WebRTC handles the media stream, but peers must exchange the initial offer/answer and ICE candidates via some signaling channel, commonly WebSocket.

Combined Flow

WebSocket sends:
- Offer
- Answer
- ICE candidates
WebRTC handles:
- Actual video/audio streaming

So:

WebSocket = Setup communication
WebRTC = Real time media transfer

When Should You Use WebSocket?

Use WebSocket when you need:

Real-time messaging
Notifications
Live updates
Multiplayer game state
Collaborative editing

Data is small, frequent, and server-controlled.

When Should You Use WebRTC?

Use WebRTC when you need:

Video calls
Voice calls
Screen sharing
Peer-to-peer file transfer

Data is heavy and needs ultra-low latency.

Common Mistake

Beginners often think: “I’ll just stream video using WebSocket.”

Bad idea. Why?

High latency
Huge server cost
Poor scalability

Always use WebRTC for media.

Real Product Architecture

In a real app like worksync123.com:

WebSocket handles:

Chat messages
Typing indicators
Notifications
Signaling for WebRTC

WebRTC handles:

Video calls
Audio streaming
Screen sharing

Production Tip

Instead of building everything manually, consider using platforms like:

LiveKit
Agora
Twilio

They combine signaling (WebSocket) and media (WebRTC).

Final Mental Model

If you remember just this:

WebSocket = Talking through a server (messages)
WebRTC = Talking directly (video/audio)

Final Thought

Think of it like a workplace:

Chat messages go through company servers
Meetings happen directly between people

That’s exactly how modern real-time apps work.

PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale

Abdullah al Mubin — Fri, 17 Apr 2026 18:33:02 +0000

If you’ve ever scaled an app and suddenly your database starts struggling even though your queries are optimized, you’re not alone.

The issue often isn’t your SQL.

It’s your connections.

Let’s break this down with a real-world story so it actually sticks.

Content

The Scenario: A Busy Food Delivery App
The Problem Appears
The Hidden Problem: Too Many Connections
What Actually Happens
Do the Math
The CPU Problem: Context Switching
Why This Breaks at Scale
The Solution: Connection Pooling
Think of It Like a Restaurant Kitchen
How It Works
The Magic
Real Impact
Deep Dive: Pooling Modes
Why Transaction Pooling Wins
PgBouncer vs Odyssey
Real Architecture (Modern Apps)
Pro Tip: Double Pooling Strategy
Common Mistake
Mental Model
Final Thought

The Scenario: A Busy Food Delivery App

Imagine you built:

quickbite.com

At lunchtime:

5,000 users open the app
They browse menus
Place orders
Check delivery status

Every action hits your PostgreSQL database.

The Problem Appears

Everything works perfectly at low traffic.

But during peak hours:

API response time increases
Database CPU usage spikes
Memory usage grows rapidly
Requests start timing out

You start wondering:

“Is my database too slow?”

But the real problem is something else.

The Hidden Problem: Too Many Connections

PostgreSQL works differently from many other databases.

It uses a process-per-connection model

What Actually Happens

Every time your app connects to PostgreSQL:

A new OS process is created
Each process consumes ~10MB–20MB of RAM
That process stays alive for the entire connection

Do the Math

If you have:

500 active users → 500 processes
Each process uses ~20MB

That’s 10GB of RAM consumed just for connections

And you haven’t even executed a single query yet.

The CPU Problem: Context Switching

Now imagine:

Hundreds (or thousands) of processes
CPU constantly switching between them

The database spends more time:

Managing processes
Than executing actual queries

Why This Breaks at Scale

In modern systems:

Each API request may open a DB connection
Microservices multiply connection counts
Autoscaling creates sudden spikes

Suddenly:

1,000+ connections hit PostgreSQL at once

And everything slows down.

The Solution: Connection Pooling

Instead of letting every request connect directly to the database…

Introduce a middle layer

Connection Pooler (PgBouncer / Odyssey)

Think of It Like a Restaurant Kitchen

Without pooling:

1,000 customers → 1,000 chefs
The kitchen becomes chaotic

With pooling:

1,000 customers
Only 50 chefs
Orders are handled efficiently

That’s connection pooling.

How It Works

Without Pooling

App → PostgreSQL

(Each request opens a new connection)

With Pooling

App → Pooler → PostgreSQL

Pooler maintains a small pool (50–100 connections)
Thousands of users share these connections

The Magic

When a request comes in:

Pooler borrows a connection
Executes the query
Returns the connection to the pool

Fast reuse, minimal overhead

Real Impact

Without Connection Pooling

~1000 active database connections
~20GB RAM consumed just for connections
High CPU usage due to context switching
Slower query performance

With Connection Pooling

Only ~50 active database connections
~1GB RAM usage
Stable and efficient CPU usage
Faster query throughput

Deep Dive: Pooling Modes

1. Session Pooling (Basic, but inefficient)

One user = one connection (entire session)

Problem:

Idle users hold connections unnecessarily

Use only if:

You rely on session-specific features

2. Transaction Pooling (Best Option)

Connection is used only during a transaction

Flow:

BEGIN → query runs
COMMIT → connection released

Result:

1000 users can share 50 connections

3. Statement Pooling (Extreme Mode)

Connection released after each query

Problem:

Multi-step transactions break

Use only for:

High-volume, simple read workloads

Why Transaction Pooling Wins

Not all users query at the same time

So:

1000 users ≠ 1000 active queries

Pooling takes advantage of this timing gap

PgBouncer vs Odyssey

PgBouncer (Most Common)

Simple and lightweight
Extremely stable
Industry standard

Best for 90% of applications

Odyssey (Advanced)

Multi-threaded
Better for high-core systems
More complex setup

Best for very high-scale systems

Real Architecture (Modern Apps)

In production, it looks like this,

App Servers → Connection Pooler → PostgreSQL

Pro Tip: Double Pooling Strategy

1. App-Level Pool

Examples:

HikariCP (Java)
Node.js connection pools

Reduces connection overhead

2. Database-Level Pool

Example:

PgBouncer

Protects PostgreSQL from spikes

Combined Flow

App → App Pool → PgBouncer → PostgreSQL

So, Maximum efficiency + stability

Common Mistake

“Let’s just increase max_connections”

This makes things worse

Why?

More connections = more memory usage
More processes = more CPU overhead
Performance degrades further

Connection pooling is the real solution

Mental Model

PostgreSQL = expensive connections
Pooler = smart connection sharing

Final Thought

Connection pooling isn’t just an optimization.

It’s often the difference between:

A system that crashes under load
And one that scales smoothly

Instead of giving every user their own database process,

you let them share a small, efficient pool.

That’s how modern high-scale systems survive traffic spikes.

WebRTC Video Calls Explained: Simpler Than You Think

Abdullah al Mubin — Tue, 14 Apr 2026 07:11:03 +0000

Building real-time video apps sounds intimidating at first. You hear terms like SDP, ICE candidates, STUN, TURN, and suddenly it feels like you’re diving into networking hell.

But here’s the truth:

WebRTC becomes much easier when you stop thinking like an engineer and start thinking like a human.

Let’s walk through it as a simple, memorable story.

Content

A Real-World Scenario
Step 1: They Don’t Talk Directly (At First)
Step 2: “Here’s My Setup”
Step 3: The Handshake
Step 4: The Real Problem is Network Barriers
Step 5: Asking for Public Address (STUN)
Step 6: When Direct Connection Fails
Step 7: The Middleman (TURN)
Step 8: The Magic Moment (Video Starts)
Receive Remote Video
The Entire Flow in One View
The Simplest Mental Model
Real Product View (Corporate Meeting)
The Reality Most Tutorials Don’t Tell You
What Professionals Actually Do
Final Thought

A Real-World Scenario

Imagine you’ve built a corporate meeting platform called:

meet123.com

*Rahim *(a software engineer) joins a team meeting with *Aisha *(product manager).

At exactly 10 AM:

Rahim opens: meet123.com/room/team-sync

Aisha opens the same link

They’re now “in the same meeting.”

But… nothing happens yet.

The real question is:

How do their cameras actually connect?

Step 1: They Don’t Talk Directly (At First)

Here’s the key idea:

Browsers don’t connect directly immediately.

Instead:

Rahim connects to a meeting server
Aisha connects to the same server

Think of this server like a meeting coordinator.

This is called the Signaling Server

Step 2: “Here’s My Setup”

Before the meeting starts, both participants share their setups.

Rahim says:

“I’ve got camera, mic, and these formats.”

Aisha says:

“Same here.”

This exchange is called:

SDP (Session Description Protocol)

It includes:

Video/audio formats (codecs)
Resolution
Device capabilities
Network info

Think of it like:

“Here’s how I can communicate.”

Step 3: The Handshake

Now they formally agree on how to communicate.

Flow:

Rahim creates an offer
Sends it to the backend (via WebSocket)
Backend forwards it to Aisha
Aisha creates an answer
Backend sends it back to Rahim

Now both sides agree on:

Formats
Communication rules

But they still aren’t connected yet.

Step 4: The Real Problem is Network Barriers

Here’s where reality hits.

Rahim might be:

On home WiFi
Behind a router
Using a private IP

Aisha might be:

In an office network
Behind a firewall

Problem:

They don’t know how to reach each other.

Step 5: Asking for Public Address (STUN)

To solve this, both ask a helper:

STUN server

Rahim asks:

“What’s my public address?”

STUN replies:

“You appear as: 103.xx.xx.xx:54321”

Aisha does the same.

Now both know how they appear on the internet.

They attempt a direct connection.

Step 6: When Direct Connection Fails

Sometimes it works and sometimes it doesn’t.

Reasons:

Office firewalls block traffic
Strict corporate networks
Mobile data restrictions

So WebRTC needs a fallback.

Step 7: The Middleman (TURN)

If the direct connection fails, both sides use a relay:

TURN server

Now the flow becomes:

Rahim → TURN → Aisha

It’s like saying:

“We can’t connect directly, so let’s use a central meeting room.”

This guarantees connectivity but adds some latency and cost.

Step 8: The Magic Moment (Video Starts)

Once the connection is established:

Camera captures video
Audio is recorded
Data is encoded
Sent over the network
Decoded on the other side
Displayed instantly

Now the meeting is live.

Mapping This to Real Code

1. Turn on Camera & Microphone

const stream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true
})


videoElement.srcObject = stream

2. Create Peer Connection

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:stun.l.google.com:19302" }
  ]
})

3. Add Media Tracks

stream.getTracks().forEach(track => {
  pc.addTrack(track, stream)
})

4. Create Offer (Rahim)

const offer = await pc.createOffer()
await pc.setLocalDescription(offer)

socket.emit("offer", offer)

5. Aisha Responds with Answer

await pc.setRemoteDescription(offer)

const answer = await pc.createAnswer()
await pc.setLocalDescription(answer)

socket.emit("answer", answer)

6. Rahim Receives Answer

await pc.setRemoteDescription(answer)

7. Exchange ICE Candidates

pc.onicecandidate = (event) => {
  if (event.candidate) {
    socket.emit("ice-candidate", event.candidate)
  }
}

8. Receive Remote Video

pc.ontrack = (event) => {
  remoteVideo.srcObject = event.streams[0]
}

The Entire Flow in One View

Rahim sends offer
Aisha sends answer
Both exchange ICE candidates
Try direct connection (STUN)
Fallback to TURN if needed
Meeting starts

The Simplest Mental Model

If you remember just this, you understand WebRTC:

WebRTC → Direct video pipe
Signaling server → Meeting coordinator
STUN → Finds your public identity
TURN → Backup relay when direct fails

Real Product View (Corporate Meeting)

In your actual app:

Participant:

Clicks “Join Meeting”
Camera starts
Waits in room

Team Members:

Join the same room
Instantly connect

Everything else happens behind the scenes.

The Reality Most Tutorials Don’t Tell You

Raw WebRTC is powerful but:

Hard to scale
Full of edge cases
Painful to debug
Requires TURN infrastructure

This is where most developers get stuck.

What Professionals Actually Do

Instead of building everything manually, most teams use:

LiveKit
Agora
Twilio

With these, your code becomes:

const room = await connect(url, token)
await room.localParticipant.enableCameraAndMicrophone()

No need to manage:

Offers & answers
ICE candidates
Network traversal

Final Thought

At its core, WebRTC is beautifully simple:

Team members trying to join a meeting,
using a coordinator to exchange info,
figuring out how to reach each other,
and using a central room only if needed.

Once you see it this way, everything clicks.

Dictionary C#. Easier than we think.

Abdullah al Mubin — Sat, 05 Aug 2023 14:25:49 +0000

What is Dictionary:

The Dictionary is a generic collection of key-value pair of data. It contains a unique key, we can easily get our specific data using that unique key. The dictionary is the most useful and popular data structure whenever we need to find value based on key..

Syntax:

Dictionary<TKey, TValue> dictionaryObj = new Dictionary<TKey, TValue>();

in the above line, dictionaryObj is name of the dictionary, Tkey is The type of key we pass in the dictionaryObj and TValue is The type of value we pass in the dictionaryObj.

TKey and TValue can be any data type.

Characteristics

Comes under System.Collections.Generic namespace.
Dictionary stores key-value pairs.
Implements IDictionary interface.
Keys must be unique and cannot be null.
Values can be null or duplicate.
Values can be accessed by passing associated key in the indexer e.g. myDictionary[key]
Elements are stored as KeyValuePair objects.
It is faster than a Hashtable because there is no boxing and unboxing.

Create a Dictionary

We have already seen the syntax, let's try to create a dictionary,

Dictionary<int, string> myDictionary = new Dictionary<int, string>();

In the above code, key will be int and value will be string.

let's add some value on it, here, 1 is key and value is myName

myDictionary.Add(1, "myName");

put below code in our compiler and run the code.

Dictionary<int, string> myDictionary = new Dictionary<int, string>();
myDictionary.Add(1, "mubin");

foreach (var item in myDictionary)
{
Console.WriteLine(item.Key + ": and value is: " + item.Value);
}

Then the output will be,
1: and value is: mubin

let's put an object in a dictionary,

Declare a class UserDetails

class UserDetails
    {
        public string Name { get; set; }
        public int Age { get; set; }
        public string Address { get; set; }
    }

Now declare a dictionary using that class

Dictionary<int, UserDetails> userDetails = new Dictionary<int, UserDetails>();
userDetails.Add(1, new UserDetails { Name = "Galib", Age = 123, Address = "Naogaon" });

foreach (var item in userDetails)
{
Console.WriteLine("Key is: "+item.Key + " Name " + item.Value.Name + " Age: " + item.Value.Age + " Address: " + item.Value.Address);
}

if we run above code then the result will be

Get Data from Dictionary:

To get data from dictionary we can use the square bracket notation to access an item data in the dictionary.

Dictionary<int, string> myDictionary = new Dictionary<int, string>();
myDictionary.Add(1, "mubin");

string userName = myDictionary[1]; 
// Here 1 is a key, using 1 we can get value

Update Data in a Dictionary

To update data, We can use square bracket and notation then assign new value.

Dictionary<int, string> myDictionary = new Dictionary<int, string>();
myDictionary.Add(1, "mubin");
myDictionary[1] = "Update Username";

Delete Data in a Dictionary

We can use remove method to delete data in a dictionary.

myDictionary.Remove(1);

Properties of Dictionary:

Count
Count used to get the total length/number of key-value pairs in the Dictionary.

int count = myDictionary.Count;

Values
Values used to get a collection of all the values in the Dictionary.

var values = myDictionary.Values;

Keys
Get a collection of all the keys in the Dictionary.

var keys = myDictionary.Keys;

C# Dictionary Methods

Add()
Add(TKey key, TValue value): Add a new key-value pair item to the Dictionary.

Dictionary<string, int> bookPrice = new Dictionary<string, int>();
bookPrice.Add("Physics", 2.20);
bookPrice.Add("Chemistry", 1.80);

ContainsKey()
ContainsKey(TKey key): Returns a boolean indicating whether the Dictionary contains the specified key.

bool containsPhysics = bookPrice.ContainsKey("Physics"); // returns  true;
bool containsHistory = bookPrice.ContainsKey("History"); // returns false;

Note: If the key is null, an ArgumentNullException will be thrown, and if the requested key is not in the dictionary, a KeyNotFoundException will be thrown.

ContainsValue()
Returns a boolean indicating whether the Dictionary contains the specified value.

bool value = bookPrice.ContainsValue(1.80); // returns true;

Remove()
Remove() method deletes the value with the specified key from the Dictionary.
If the key is found and the item is successfully removed, it returns true; otherwise false.

// Use the Remove method to remove a key / value pair.
Console.WriteLine("\nRemove(\"107\")\n");
bookPrice.Remove("Physics");

// Check if item is removed from the dictionary object.
if (!bookPrice.ContainsKey("Physics"))
{
  Console.WriteLine("Key \"107\" is not found.");
}

TryGetValue()
This method is used to get the value for a specific key, which allows you to handle the case where the key does not exist. It will not throw an error if the key doesn’t exist in the collection.

int physicsPrice;
if (bookPrice.TryGetValue("Physics", out physicsPrice))
{
    Console.WriteLine($"The price of a Physics book is {physicsPrice}.");
}
else
{
    Console.WriteLine("The Physics book is not available.");
}

Clear()
Removes all key-value pairs from the Dictionary.

bookPrice.Clear();

That's all for today.. seee ya.

react useContext. Easier than we think.

Abdullah al Mubin — Sun, 23 Jul 2023 17:48:10 +0000

Here, we will learn about useContext in details with examples. we also learn about When and how we need to use useContext.

I have added github demo click here.

useContext Hook

Sometimes we use props to pass data from parent to child. It's a complex process and it is also inconvenient if we need to pass them through many components. The React Context API provides a way to share data inside the React component tree.

Usage:

Passing data deeply into the tree.
Overriding context for a part of the tree.
Optimizing re-renders when passing objects and functions.
Updating data passed via context.
Specifying a fallback default value.
useContext can pass data to our entire application and also it can use at any part of the application.

Syntax:

const value = useContext(SomeContext)

let's try useContext with simple application. let's change some font sizes and try to understand its data flow.

Final Result

At first, we need to create a context using React.createContext and this context will pass to the hook. I have created a folder called Context and put a file index.js inside the folder.

import { createContext } from "react";

//initial fontSize as 16.
const fontSizeContext = createContext(16);
export default fontSizeContext;

in the above code, we used createContext and set the initial value 16. It assign to fontSizeContext constant and export as a default.

What is createContext
It creates a context object and used to make sure that every component at different levels (inside tree) can use the same context to fetch data.

let's make some changes in app.js file.

import FontSizeContext from "./Context/context";
import { useState } from "react";
import UseContextExample from "./UseContextExample";

const App = () => {
  const [size, setSize] = useState(16);
  return (
    <FontSizeContext.Provider value={size}>
      <div style={{ width: '500px', margin: 'auto' }}>
        <UseContextExample />

        <button onClick={() => setSize(size + 5)}>Increase font size</button>
        <button
          onClick={() =>
            setSize((prevSize) => Math.min(prevSize - 5))
          }
        >
          Decrease font size
        </button>
      </div>
    </FontSizeContext.Provider>
  );
};
export default App;

In the above code, we use Font Size Context.Provider value={size} here, we wrapped our component with FontSize Context.Provider and make our size/value available to every component inside the tree.

we also added two buttons, one to increase the size and the other used to decrease the size. Whenever someone clicks on a button it updates its state and change the value of font size and then it passes to the entire component tree. So any component can easily access the value of font size.

Now, create a folder called UseContextExample inside the directory create a file called index.js and put the below code inside index.js file.

import { useContext } from "react";
import fontSizeContext from "../Context/context";
const UseContextExample = () => {
    const size = useContext(fontSizeContext);
    return <p style={{ fontSize: `${size}px` }}>font size now {size}px</p>;
};
export default UseContextExample;

in the above code, we use
const size = useContext(fontSizeContext); to get the value of font size. This component can easily access the data/value of font size because it stays inside the component tree.

I have added github demo click here.

That's it for today. See yaaa.

react useMemo, useCallback. Easier than we think.

Abdullah al Mubin — Sat, 22 Jul 2023 19:54:27 +0000

As front-end developers, we always try to make our application performance better and better. Sometimes we need to execute large and critical calculation in our system. Those function/calculation take time to complete, so our application will be slow.

Meanwhile, we try to improve performance using the Memoization technique.

In this lesson, we will learn about Memoization technique using useMemo and useCallback.

Memoization:

Memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls to pure functions and returning the cached result when the same inputs occur again.

useMemo Hook

The useMemo hook is designed to memoize expensive computations. Memoization simply means caching. It caches the computation result with respect to the dependency values so that when the same values are passed, useMemo will just spit out the already computed value without recomputing it again. This can significantly improve performance when done correctly.

Syntax:

useMemo hook can be used as follows,

const memoizedResult = useMemo(() => { return criticalComputeFn(parameter1, parameter2); }, [parameter1, parameter2]);

Here, criticalComputeFn represents the calculation function and dependencies represent the dependency array. ([parameter1, parameter2]).

UseCallBack

useCallback does the same thing as useMemo but it returns a memoized callback instead of memoized value.

Syntax:

This hook can be used as follows,

const memoizedResult = useCallback(() => { return criticalComputeFn(parameter1, parameter2); }, [parameter1, parameter2]);

Remember one thing, useMemo and useCallback are both used for same purpose, but useMemo return memoized value but useCallback return memoized callback.

What is callback?
It is a function that is passed as an argument to another function.

Rules:

During the first rendering or initial rendering useMemo and useCallback both invoke criticalComputeFn, then useMemo returns the result/value but useCallback returns the callback.
If dependencies change then useMemo and useCallback both invoke criticalComputeFn, then useMemo return the result/value but useCallback return the callback.
If dependencies don't change, then both don't invoke criticalComputeFn but useMemo return memoize result/value and useCallback return memoize callback.

Simple Example:

import React, { useCallback, useMemo, useEffect } from 'react'

export default function App() {
  const a = 5
  const b = 7

  const memoResult = useMemo(() => a + b, [a, b])

  const callbackResultFn = useCallback(() => a + b, [a, b])

  useEffect(() => {

  }, [])

  const callback = callbackResultFn()

  console.log(callbackResultFn) // Return function
  console.log(callback) // return value
  console.log(memoResult) // return value using useMemo



  return (
    <div>
      <><h2>Test test</h2></>
    </div>
  )
}

in the above code we can see that useMemo and useCallback show the same result/value. useMemo directly return the calculation result/value but useCallback return callback function then we need to process the result to show it.

Careful about:

useMemo/useCallback should be used only when it is necessary to optimize the computation. In other words, when recomputation is expensive.
It is advisable to first write the calculation without memoization and only memoize it if it is causing performance issues.
Unnecessary and irrelevant use of the useMemo/useCallback hook may even compound the performance issues.
Sometimes, too much memoization can also cause performance issues.

RealTime example of useMemo:

import axios from "axios";
import { useEffect, useMemo, useState } from "react";

export default function App() {
  const [employee, setEmployee] = useState({});
  const [employees, setEmployees] = useState([]);
  const [num, setNum] = useState(1);

  const endPoint =
    "https://my-json-server.typicode.com/ifeanyidike/jsondata/employees";

  useEffect(() => {
    const getEmployee = async () => {
      const { data } = await axios.get(`${endPoint}/${num}`);
      setEmployee(data);
    };
    getEmployee();

    return () => {};
  }, [num]);

  useEffect(() => {
    axios.get(endPoint).then(({ data }) => setEmployees(data));
  }, [num]);

  const taxVariablesCompute = useMemo(() => {
    const { income, noOfChildren, noOfDependentRelatives } = employee;

    const reliefAllowance1 = 0.01 * income >= 200000 ? 0.01 * income : 200000;
    const reliefAllowance2 = 0.2 * income;

    const numChildren = +noOfChildren <= 4 ? +noOfChildren : 4;
    const numRelatives =
      +noOfDependentRelatives <= 2 ? +noOfDependentRelatives : 2;

    const childrenRelief = numChildren * 2500;
    const relativesRelief = numRelatives * 2000;
    const pensionRelief = 0.075 * income;

    const reliefs =
      reliefAllowance1 +
      reliefAllowance2 +
      childrenRelief +
      relativesRelief +
      pensionRelief;

    return reliefs;
  }, [employee]);

  const taxCalculation = useMemo(() => {
    const { income } = employee;
    let taxableIncome = income - taxVariablesCompute;
    let PAYE = 0;

    const taxEndPoints = [300000, 300000, 500000, 500000, 1600000, 3200000];

    for (let i = 0; i < taxEndPoints.length; i++) {
      if (i === 0) {
        if (taxableIncome >= 300000) {
          PAYE += 0.07 * taxEndPoints[i];
          taxableIncome -= taxEndPoints[i];
        } else {
          PAYE += 0.07 * taxableIncome;
          break;
        }
      } else if (i === 1) {
        if (taxableIncome >= 300000) {
          PAYE += 0.11 * taxEndPoints[i];
          taxableIncome -= taxEndPoints[i];
        } else {
          PAYE += 0.11 * taxableIncome;
          break;
        }
      } else if (i === 2 && taxableIncome >= 500000) {
        if (taxableIncome >= 500000) {
          PAYE += 0.15 * taxEndPoints[i];
          taxableIncome -= taxEndPoints[i];
        } else {
          PAYE += 0.15 * taxableIncome;
          break;
        }
      } else if (i === 3) {
        if (taxableIncome >= 500000) {
          PAYE += 0.19 * taxEndPoints[i];
          taxableIncome -= taxEndPoints[i];
        } else {
          PAYE += 0.19 * taxableIncome;
          break;
        }
      } else if (i === 4) {
        if (taxableIncome >= 1600000) {
          PAYE += 0.21 * taxEndPoints[i];
          taxableIncome -= taxEndPoints[i];
        } else {
          PAYE += 0.21 * taxableIncome;
          break;
        }
      } else if (i === 5) {
        if (taxableIncome >= 3200000) {
          PAYE += 0.24 * taxEndPoints[i];
          taxableIncome -= taxEndPoints[i];
        } else {
          PAYE += 0.24 * taxableIncome;
          break;
        }
      }
    }

    const netIncome = income - PAYE;
    return { PAYE, netIncome };
  }, [employee, taxVariablesCompute]);

  return (
    <div className="App">
      <div>
        <p></p>
        <p>Name: {`${employee.firstName} ${employee.lastName}`}</p>
        <p>Job: {employee.job}</p>
        <p>Sex: {employee.sex}</p>
        <p>Income: {employee.income}</p>
        <p>No. of children: {employee.noOfChildren}</p>
        <p>No. of dependents: {employee.noOfDependentRelatives}</p>
        <p>PAYE: ₦{taxCalculation.PAYE}</p>
        <p>Income after PAYE: ₦{taxCalculation.netIncome}</p>
      </div>
      <div>
        <button
          disabled={num === 1}
          onClick={() =>
            setNum((prevNum) => (prevNum >= 1 ? prevNum - 1 : prevNum))
          }
        >
          &laquo;
        </button>
        <button
          disabled={num === employees.length}
          onClick={() =>
            setNum((prevNum) =>
              prevNum < employees.length ? prevNum + 1 : prevNum
            )
          }
        >
          &raquo;
        </button>
      </div>
    </div>
  );
}

In the above code, I have tried to calculate tax information. I think it's an expensive calculation. So I do it with useMemo.

That's it for today. See yaa.

React useReducer. Easier than we think.

Abdullah al Mubin — Tue, 18 Jul 2023 10:02:30 +0000

useReducer:

useReducer is one of the most popular react hooks. useReducer hook returns the current stage and a dispatch method. It is similar to the useState hook. If we want to make complex logic then useReducer may be very useful.

If you want to download the full demo project then click here Demo git.

Syntax:

useReducer(<reducer>, <initialState>)
useReducer(<reducer>, <initialState>, <init>)

Here, reducer function contains custom state logic and the initialState can be a sample default state value.

init is a function and it is used whenever we want to create the initial state lazily.

reducer:

A reducer is a function that is able to process user instruction/action. A reducer processes the existing state with user action and returns the new state.

below we will try to make a simple application for better understanding.

Todo Application:

The below image shows the UI of our application.

We can see that it contains a submit button, if we save it then it will show on the list, we can complete and remove that todo item.

We will make our code as simple as we can.

let try to make action type

Here, we will make 3 types of action,

Add Todo
Remove Todo
Complete Todo

I have created a new folder inside the src directory and the folder name is action. inside that folder, I have created an index.js file and put the below code.

// src/action/index.js

export const ADD_TODO = "ADD_TODO";
export const REMOVE_TODO = "REMOVE_TODO";
export const COMPLETE_TODO = "COMPLETE_TODO";

We have created three constants for user action types.

let try to make reducer

We already know that a reducer basically is a function that contain complex logic. We need to pass value and instruction/action then it will change previous state to new state. Just like Redux but we don't need to initialize our reducer here.

I have created a new folder and named it reducer, inside that folder I have created an index.js file and put the below code,

import { ADD_TODO, REMOVE_TODO, COMPLETE_TODO } from './../action'

const reducer = (state, action) => {
    switch (action.type) {
        case ADD_TODO:
            const newTodo = {
                id: action.id,
                text: action.text,
                completed: false
            };
            return [...state, newTodo];
        case REMOVE_TODO:
            return state.filter((todo) => todo.id !== action.id);
        case COMPLETE_TODO:
            const completeTodo = state.map((todo) => {
                if (todo.id === action.id) {
                    return {
                        ...todo,
                        completed: !todo.completed
                    };
                } else {
                    return todo;
                }
            });
            return completeTodo;
        default:
            return state;
    }
};
export default reducer;

Inside the reducer function, we used a switch statement to check user action. If the user want to add new todo, then the action type will be ADD_TODO and based on switch statement, it will perform ADD_TODO logic in that block. Finally it will return new state.

case ADD_TODO: const newTodo = { id: action.id, text: action.text, completed: false }; return [...state, newTodo];

To Remove a todo task, the action type will be REMOVE_TODO, and based on the switch _ statement, it will perform _REMOVE_TODO logic in that block. Finally, it will return to the new state.

case REMOVE_TODO: return state.filter((todo) => todo.id !== action.id);

To complete a todo, the action will be COMPLETE_TODO and it will perform his logic and return new state.

case COMPLETE_TODO: const completeTodo = state.map((todo) => { if (todo.id === action.id) { return { ...todo, completed: !todo.completed }; } else { return todo; } }); return completeTodo;

it's a simple example so I haven't divided UI into separate containers. I put everything inside app.js file.

let put useReducer in app.js

import { useReducer, useState } from "react";
import "./index.css";
import reducer from "./reducer";
import { ADD_TODO, REMOVE_TODO, COMPLETE_TODO } from './action'
export default function App() {
  const [id, setId] = useState(0);
  const [text, setText] = useState("");
  const initialState = [
    {
      id: id,
      text: "First todo Item",
      completed: false
    }
  ];

  //We could also pass an empty array as the initial state
  //const initialState = []

  const [state, dispatch] = useReducer(reducer, initialState);
  const addTodoItem = (e) => {
    e.preventDefault();
    const newId = id + 1;
    setId(newId);
    dispatch({
      type: ADD_TODO,
      id: newId,
      text: text
    });
    setText("");
  };
  const removeTodo = (id) => {
    dispatch({ type: REMOVE_TODO, id });
  };
  const completeTodo = (id) => {
    dispatch({ type: COMPLETE_TODO, id });
  };
  return (
    <div className="App">
      <h2>Todo Example</h2>
      <form className="input" onSubmit={addTodoItem}>
        <input value={text} onChange={(e) => setText(e.target.value)} />
        <button disabled={text.length === 0} type="submit">+</button>
      </form>
      <div className="todos">
        {state.map((todo) => (
          <div key={todo.id} className="todoItem">
            <p className="">{todo.completed ? <del>{todo.text}</del> : todo.text}</p>
            <div className="actionType">
              <span onClick={() => removeTodo(todo.id)}>✕</span>
              <span onClick={() => completeTodo(todo.id)}>✓</span>
            </div>
          </div>
        ))}
      </div>
    </div>
  );
}

In the above code, we can see that useReducer takes the reducer function and initialState as a parameter then it returns state and dispatch.

When someone types some text and clicks on + sign, then inside the addTodoItem function dispatch function will be called and it contains 3 parameters those are type (ADD_TODO), id and text. dispatch will trigger reducer function and based on type reducer function will add a new todo item and return new state.

dispatch({ type: ADD_TODO, id: newId, text: text });

When someone clicks on ✕ the sign, then another dispatch function will be called, this time type will be REMOVE_TODO, and based on type and id, the reducer function removes the specific item and will return new state.

dispatch({ type: REMOVE_TODO, id });

When someone clicks on ✓ then dispatch function will trigger reducer with action type COMPLETE_TODO, then reducer will update that object based on id and return new state.

dispatch({ type: COMPLETE_TODO, id });

Let's put some CSS in index.css file,

body {
  margin: 0;
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Roboto', 'Oxygen',
    'Ubuntu', 'Cantarell', 'Fira Sans', 'Droid Sans', 'Helvetica Neue',
    sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

code {
  font-family: source-code-pro, Menlo, Monaco, Consolas, 'Courier New',
    monospace;
}

.App {
  width: 205px;
  margin: auto;
}

.todoItem {
  width: 100%;
  float: left;
  border-bottom: 1px solid;
}

.todoItem p {
  float: left;
}

.actionType {
  float: right;
  margin-top: 15px;
}

If you want to download the full demo project then click here Demo git.

That's all for today, next, we will learn about react useContext hook and how to use with useReducer.

See ya.

Linked List Javascript. Easier than you think.

Abdullah al Mubin — Sun, 09 Jul 2023 04:56:11 +0000

Thinking about data structure, let's take a closer look at Linked List.

Linked list is one of the most popular and efficient data structures. Basically, Linked List is a collection of "nodes", each node contain data, next and previous, basically next refers to next node and previous refers to the previous node.

We can say that, array and linked list is similar. but in array, elements are stored in a specific location or index.

On the other hand, in Linked List everything works as a separate object. Each element (node) contain few things, data, link to the next node, link to the previous node.

Types of Linked List:
There are three types of linked list,

1. Singly Linked List: Each node contains data and a pointer to the next node. Basically its unidirectional.

Analyzing the above image, it start with Head, so Head is the entry point. If a Linked list is empty then the Head will be null. So Head reference to the first node and Last node points to the null.

const linkedList = {
    head: {
        value: 5
        next: {
            value: 7                                             
            next: {
                value: 2
                next: {
                    value: 15
                    next: null  
                    }
                }
            }
        }
    }
};

Basic example,

// class of node
class ListNode {
    constructor(data) {
        this.data = data
        this.next = null                
    }
}

/* LindedList class. remember, if the head node is not passed then head will be null */
class LinkedList {
    constructor(head = null) {
        this.head = head
    }
}

/* lets create some nodes */

let node1 = new ListNode(5) // data will be 5
let node2 = new ListNode(7) // data will be 7
let node3 = new ListNode(2) //  data will be 2
let node4 = new ListNode(15) // data will be 15

node1.next = node2 // points to the node2
node2.next = node3 // points to the node2
node3.next = node4

let list = new LinkedList(node1) // Linked List completed

Advantage and Uses of Singly Linked List

- Dynamic data structure: Memory is dynamically allocated to the linked List. easily we can add or remove an element. We don't need to think about initial size.
- Implementation: Other data structure can be easily implemented here such as Queues and Stacks.
- Versatility: Lined list can be used to implement a wide range of data structures, such as stacks, queues, graphs, truees and has tables.

Disadvantage of Singly Linked List

- Memoray usage: We need to store address of the next data, so it takes more memory.
- Accessing an element: Its impossible to access any element directly. If we need to find nth value, then we need to traverse until nth element found.
- Reverse traversal: It impossible for the Singly linked List. Because we don't have the memory address of the previous pointer.
- More complex implementation: Similar to Array, Its implementation is very complex. We need to understand dynamic memory location and pointer manipulation.
- Lack of cache locality: It may not take advantage of the caching mechanisms in modern processors. Its slower in performance.

2. Doubly Linked List: Each node contains two pointers one for next node and one for previous node.

in the above image, we understand that,

prev: refers to the previous node
data: data item
next: address to the next node

below image shows us representation of doubly Linked list, Here each node contain next _and _prev to point next node and prev node

Basic example

class ListNode  {
    constructor(value) {
        this.value = value;
        this.next = null;
        this.previous = null;
    }
}

class DoublyLinkedList {
    constructor(value) {
        this.head = {
            value: value,
            next: null,
            previous: null
        };
        this.length = 0;
        this.tail = this.head;
    }

    // Insert node at end of the list
    add(newNode) {
        this.tail.next = newNode;
        newNode.previous = this.tail;
        this.tail = newNode;
        this.length++;
    }

    printList() {
        let current = this.head;
        let result = [];
        while (current !== null) {
            result.push(current.value);
            current = current.next;
        }
        console.log(result.join(' '));
        return this;
    }
}

let numList = new DoublyLinkedList();
numList.add(new ListNode (12));
numList.add(new ListNode (13));
numList.add(new ListNode (14));
numList.add(new ListNode (15));
numList.add(new ListNode (16));
numList.add(new ListNode (17));
numList.printList();
console.log(numList)
console.log(numList.head)

Advantage of Doubly Linked List:

- Reversing: Reversing the doubly linked list is very easy.
-Traversal: The traversal of this doubly linked list is bidirectional which is not possible in a singly linked list.
-Deletion: Deletion of nodes is easy as compared to a Singly Linked List.

Disadvantage of Doubly Linked List:

It uses extra memory when compared to the array and singly linked list.
Traversing a doubly linked list can be slower than traversing a singly linked list
Implementing and maintaining doubly linked lists can be more complex than singly linked lists.

Uses of Doubly Linked List:

- Navigation Systems: It is used in the navigation systems where front and back navigation is required.
- Undo and Redo: It is also used by various applications to implement undo and redo functionality.
- MRU/LRU: Doubly Linked List is also used in constructing MRU/LRU (Most/least recently used) cache.
- Thread Scheduler: Also in many operating systems, the thread scheduler(the thing that chooses what process needs to run at which time) maintains a doubly-linked list of all processes running at that time.
- Browser: next and previous page.
- Image viewer: next and previous image

Implementing **Graph **algorithms

3. Circular Linked Lists: Its different than others, its last node points to the first nor or any other node before it.
It has two types,

Circular Singly Linked List
Circular Doubly Linked List

We will learn Circular Linked List in the next. that's it for today. See yaaa.

Forem: Abdullah al Mubin

The Diet Your App Deserves: Tree Shaking vs Dead Code Elimination

Table of Contents

The Problem: Bloated Bundles

Real-World Scenario: The Overloaded App

What gets shipped?

Result

Dead Code Elimination (DCE): The Surgeon

What it does

Example

Another Example

Analogy

What DCE Targets

Tree Shaking: The Gardener

What it does

Example

Analogy

Key Idea

Why ES Modules Matter

Why?

CommonJS (bad for tree shaking)

ES Modules (good)

Key Differences

How to Make Your Code Shakeable

1. Avoid Side Effects

Good

2. Use Named Exports

3. Import Only What You Need

Real Impact

Mental Model

Final Thoughts

What About You?

Stop Making Users Wait: Streaming SSR Explained with a Real-World Example

Table of Contents

The Problem: The All-or-Nothing Bottleneck

Real-Life Analogy

What Happens?

Same Problem in SSR

Result

Real-World Scenario: Product Page Loading

The Problem

The Solution: Streaming SSR & Suspense

How the Page Loads in Chunks

Chunk 1: Layout (Instant)

Chunk 2: Product Info

Chunk 3: Heavy Data

Result

Code Example (Next.js + Suspense)

What’s Happening Here?

What “Streaming” Actually Means

Under the Hood

Why This Is a Game Changer

Faster First Paint

Better Perceived Performance

Better SEO

Selective Hydration

Reduced TTFB Impact

Mental Model

Final Thoughts

What About You?

Beyond SSR vs SSG: Partial Prerendering (PPR) Explained with a Real-World Story

Table of Contents

The Problem: Blank Screen vs Spinner Hell

❌ SSR (The Waiting Game)

❌ CSR (Spinner Chaos)

The Idea: The Swiss Cheese Model

What Happens?

Real-World Scenario: Buying Concert Tickets

What Loads Instantly (Static Shell)

What Loads Dynamically (The “Holes”)

What You Experience

How PPR Actually Works

Code Example (Next.js + Suspense)

What’s Happening Here?

Why PPR is a Game Changer

Instant First Paint

Better SEO

No Layout Shift

Better Perceived Performance

Mental Model