DEV Community: Kashaf Abdullah

Mentora Loop — Building Platform: Everything You Need to Build, Teach, and Learn

Kashaf Abdullah — Sat, 22 Aug 2026 20:05:23 +0000

🎯 What Is This Platform?

This is a complete online management system that brings together Admins (owners), Teachers, and Students — all in one place.

What Can Be Taught?

Anything you can teach, you can teach here!

How People Join

Step 1: Student or Teacher signs up with name, CNIC, phone, email, and documents.

Step 2: Admin receives notification of new registration.

Step 3: Admin reviews documents and approves the account (just like confirming fee payment).

Step 4: User gets access to their dashboard.

📚 Core Features

1. Account & Approval System

2. Class Management

Admin creates classes, assigns teachers, and adds students. Teachers can also create their own classes. Works for ANY subject.

3. Live Classes

One-click Google Meet integration. Teachers start live classes instantly. Session history logs start time, end time, and attendance.

4. Test Bank

Teachers create tests manually or by uploading Excel files. Each test gets a unique access code. Students enter the code and take the test with a live timer.

5. Content Library

Teachers upload recorded lectures (real videos) and notes. Admin approves everything before students can see it.

6. Results & Gradebook

Teachers record marks. Students view results and can comment or ask questions.

7. Communication Tools

Group chats, direct messaging, announcements, and notifications with bell icon.

8. Calendar

Month-view calendar showing all classes and tests.

9. Payment Tracking

Admin manually logs student fees and teacher payouts.

10. Demand-Driven Classes

Students request new classes. Popular requests become vacancies. Teachers apply. Admin finalizes.

11. Analytics Dashboard

Charts and reports for everyone.

12. Public Profiles

Shareable profile links showing only safe information.

🔄 What Each User Does

Admin (Owner):

Approves all new users
Creates classes and assigns teachers
Adds/removes students from classes
Monitors all live classes
Approves all content
Tracks all payments
Creates group chats and announcements
Reviews student class requests

Teacher:

Creates their own classes
Uploads recorded lectures and notes
Conducts live classes
Builds tests (manual or Excel)
Shares access codes with students
Records results
Responds to student questions
Applies to teach new classes

Student:

Enrolls in classes
Views "My Classes" page
Attends live classes
Watches recorded lectures
Reads notes
Takes tests using access codes
Views results
Requests new classes
Chats with teachers and classmates

✅ Who Can Use This Platform?

ANY skill can be taught here!

Academic subjects (Math, Science, English, History)
Programming (Python, JavaScript, Web Development)
Languages (English, Urdu, Arabic)
Arts & Crafts
Music & Instruments
Test Preparation (SAT, GRE, CSS)
Professional Skills
And anything else you can teach!

🚀 Why Choose This Platform?

Feature	Benefit
All-in-One	Everything works together
Easy to Use	No technical skills needed
Secure	Private info protected
Flexible	Works for ANY subject
Scalable	Start small, grow big
Complete Control	Admin owns everything
Real-Time Communication	Chats and messages
Data-Driven	Analytics for everyone
Demand-Based	Students tell you what they want

🔗 Connect With Us

Facebook: facebook.com/mentoraloop
Instagram: instagram.com/mentoraloop
LinkedIn: linkedin.com/company/mentoraloop

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

Found this helpful? Leave a ❤️ and bookmark it for later!

Let's discuss in the comments: What features would you add to this platform? What subject would you teach?

What Data Structure Does Chrome Use for "Reopen Closed Tab"?

Kashaf Abdullah — Sun, 16 Aug 2026 18:58:17 +0000

Have you ever accidentally closed a browser tab and immediately thought

"Oh no! I needed that tab!" 😭

Luckily, Chrome gives us Ctrl + Shift + T — or the "Reopen Closed Tab" option — to bring it back.

But have you ever wondered what happens behind the scenes?

This simple browser feature is actually a great example of a fundamental Data Structure: the Stack.

🧠 The Interview Question

Imagine you're in a technical interview and the interviewer asks:

"You accidentally closed a browser tab. Chrome restores it instantly using 'Reopen Closed Tab'. Which data structure would you use to design this feature?"

The answer is:

👉 Stack

More specifically, a Stack follows the LIFO principle:

LIFO = Last In, First Out

And that's exactly how recently closed tabs can be modeled.

📚 What Is a Stack?

A stack is a linear data structure where elements are added and removed from the same end.

Think about a stack of plates 🍽️.

If you place plates one on top of another:

        ┌───────────┐
        │  Plate 3  │ ← Last added
        ├───────────┤
        │  Plate 2  │
        ├───────────┤
        │  Plate 1  │ ← First added
        └───────────┘

plaintext

Which plate will you remove first?

Plate 3, because it was the last one added.

That's LIFO — Last In, First Out.

🌐 Applying the Stack to Browser Tabs

Let's say you have these tabs open:

Google → YouTube → GitHub → Gmail

plaintext

Now you start closing them.

First:

Close Gmail

plaintext

The closed-tab stack becomes:

Top
 ↓
[Gmail]

plaintext

Then:

Close GitHub

plaintext

Now:

Top
 ↓
[GitHub]
[Gmail]

plaintext

Then:

Close YouTube

plaintext

The stack becomes:

Top
 ↓
[YouTube]
[GitHub]
[Gmail]

plaintext

Now you press:

Ctrl + Shift + T

What should Chrome restore?

YouTube.

Why?

Because YouTube was the last tab you closed.

That's exactly what a stack does.

🔄 Push and Pop

A stack mainly uses two operations:

1. Push

push() adds an element to the top of the stack.

When a user closes a tab:

Closed Tab → push()

plaintext

For example:

push(Gmail)
push(GitHub)
push(YouTube)

plaintext

The stack becomes:

Top
 ↓
YouTube
GitHub
Gmail

plaintext

2. Pop

pop() removes the top element.

When the user selects Reopen Closed Tab:

pop()

plaintext

The result is:

YouTube

plaintext

The stack then becomes:

Top
 ↓
GitHub
Gmail

plaintext

If the user presses Ctrl + Shift + T again:

pop() → GitHub

plaintext

And again:

pop() → Gmail

javascript

So the tabs are restored in the reverse order in which they were closed.

💻 How Would We Design It?

We can model this behavior using a simple JavaScript class:

class ClosedTabs {
    constructor() {
        this.stack = [];
    }

    closeTab(tab) {
        this.stack.push(tab);
    }

    reopenTab() {
        if (this.stack.length === 0) {
            return null;
        }

        return this.stack.pop();
    }
}

Let's use it:

const closedTabs = new ClosedTabs();

closedTabs.closeTab("Gmail");
closedTabs.closeTab("GitHub");
closedTabs.closeTab("YouTube");

console.log(closedTabs.reopenTab());
// YouTube

console.log(closedTabs.reopenTab());
// GitHub

console.log(closedTabs.reopenTab());
// Gmail

The output is:

YouTube
GitHub
Gmail

Exactly what we would expect from a LIFO structure.

🗂️ But We Wouldn't Store Only the Tab Name

In a real browser, restoring a tab involves much more information than its title.

A closed-tab object could conceptually contain:

const tab = {
    url: "https://github.com",
    title: "GitHub",
    scrollPosition: 450,
    history: [
        "https://google.com",
        "https://github.com"
    ],
    timestamp: Date.now()
};

So when the tab is restored, the browser can potentially restore relevant session information as well.

Important: This is a simplified data-structure model. Real browser session restoration is more sophisticated than simply maintaining one JavaScript stack.

⏱️ Time Complexity

One of the biggest advantages of using a stack is that its basic operations are very efficient.

Operation	Complexity
Push	O(1)
Pop	O(1)
Peek	O(1)

So:

Close Tab → O(1)
Reopen Tab → O(1)

That's extremely efficient.

🤔 Why Not a Queue?

A common interview follow-up could be:

"Why not use a Queue?"

A queue follows:

FIFO — First In, First Out

Imagine we close:

Gmail
GitHub
YouTube

A queue would return:

Gmail → GitHub → YouTube

But for a recently closed tab feature, we generally want:

YouTube → GitHub → Gmail

That's LIFO, which makes a stack a natural model.

🧩 Stack vs Queue

STACK
LIFO

Push → [A] [B] [C] ← Pop
                    ↑
                  First out

Whereas:

QUEUE
FIFO

Enqueue → [A] [B] [C] → Dequeue
          ↑               ↑
       First in        First out

This is why the distinction between LIFO and FIFO is so important in Data Structures interviews.

🚀 Real-World Applications of Stacks

The Chrome example isn't the only place where stacks are useful.

Stacks are commonly used in:

↩️ Undo/Redo operations
🌐 Browser navigation
🧮 Expression evaluation
🔄 Function call management
🧩 Backtracking algorithms
📝 Syntax parsing
🔍 Depth-First Search (DFS)
📚 Parentheses matching

For example, when you press Ctrl + Z, previous actions can be modeled using stack-based behavior.

🎯 The Interview Takeaway

If an interviewer asks:

"A user closes several browser tabs and wants to restore the most recently closed tab first. Which data structure would you use?"

Think:

Most Recent → First Restored
        ↓
       LIFO
        ↓
      STACK

The basic design is:

Close Tab
    ↓
  push()
    ↓
Stack
    ↓
  pop()
    ↓
Reopen Tab

💡 Final Thought

Sometimes the best way to understand Data Structures isn't by memorizing definitions.

It's by looking at the software we use every day.

That tiny "Reopen Closed Tab" button is a perfect example of how a fundamental concept like a Stack can help us reason about real-world software behavior.

So next time you accidentally close a tab and press:

Ctrl + Shift + T

remember:

Last closed. First restored. LIFO. Stack. 🚀

And that's Data Structures hiding in plain sight.

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

Found this helpful? Leave a ❤️ and bookmark it for later!

Let's discuss in the comments: Have you ever thought about the data structures behind everyday browser features? What other examples can you think of?

Monolithic vs Microservices Architecture

Kashaf Abdullah — Sun, 21 Jun 2026 19:53:25 +0000

When building software systems, one of the biggest architectural decisions is:

Do you build one big application (Monolithic) or split it into many smaller services (Microservices)?

Think of it like opening a restaurant 🍽️

Monolithic → One large kitchen does everything
Microservices → Multiple specialized kitchens

Monolithic Architecture

A monolithic application is built as a single codebase and deployed as one unit.

Everything lives together:

Authentication
Payments
Orders
Notifications
Database access
Admin panel

Example Structure

App
├── Auth Module
├── Orders Module
├── Payments Module
├── Notifications Module
└── Database

How it works

If you update one feature → usually the entire application is rebuilt and redeployed.

Advantages ✅

Easy to start
Faster development initially
Simpler deployment
Easier local development
Lower infrastructure cost

Disadvantages ❌

Large codebase becomes difficult to maintain
One bug can impact entire system
Scaling means scaling whole app
Slower deployments over time
Team collaboration becomes harder

Real-world Example

Early-stage startup:

Frontend
↓
Single Backend
↓
Database

Microservices Architecture

A microservices architecture breaks the application into small independent services.

Each service:

Has one responsibility
Can be deployed independently
Often owns its own database

Example Structure

API Gateway
↓
┌───────────────┐
│ Auth Service │
└───────────────┘

┌───────────────┐
│ Order Service │
└───────────────┘

┌────────────────┐
│ Payment Service│
└────────────────┘

┌────────────────┐
│ Notification │
└────────────────┘

Services communicate using:

REST APIs
GraphQL
gRPC
Message queues (Kafka, RabbitMQ)

Advantages ✅

Independent deployments
Scale specific services only
Better team ownership
Fault isolation
Technology flexibility

Disadvantages ❌

Higher infrastructure complexity
Distributed debugging
Network latency
DevOps overhead
Monitoring becomes essential

Real-world Example

Large-scale systems:

Mobile App
↓
API Gateway
↓
Multiple Services

Quick Comparison

Feature	Monolithic	Microservices
Codebase	Single	Multiple
Deployment	One deploy	Independent
Scaling	Whole app	Individual services
Complexity	Lower	Higher
Team Size	Small	Medium–Large
Maintenance	Hard at scale	Easier at scale
Cost	Lower initially	Higher initially

When to Choose What?

Choose Monolithic if:

Startup / MVP
Small team (1–10 devs)
Fast shipping matters
Product requirements change often

Choose Microservices if:

Large engineering teams
Millions of users
Independent scaling required
Multiple domains/features

Practical Advice

Many successful companies start with a monolith first and move to microservices only when complexity demands it.

Bad architecture:

Tiny startup → 15 microservices 😵

Better evolution:

Monolith → Modular Monolith → Microservices

That transition usually reduces unnecessary operational complexity early on.

Code Example: Monolithic vs Microservices

Monolithic (Node.js + Express)

const express = require('express');
const app = express();

app.post('/auth/login', (req, res) => {
// Login logic
});

app.post('/orders', (req, res) => {
// Order logic
});

app.post('/payments', (req, res) => {
// Payment logic
});

app.listen(3000);

Microservices (Separate Services)

// Auth Service - port 3001
const authApp = express();
authApp.post('/login', (req, res) => {
// Login logic only
});
authApp.listen(3001);

// Order Service - port 3002
const orderApp = express();
orderApp.post('/orders', (req, res) => {
// Order logic only
});
orderApp.listen(3002);

// Payment Service - port 3003
const paymentApp = express();
paymentApp.post('/payments', (req, res) => {
// Payment logic only
});
paymentApp.listen(3003);

Which One is Right for You?

Factor	Monolithic	Microservices
Team size	1-10 developers	10+ developers
Users	Low to medium	High to very high
Features	Fewer, simpler	Many, complex
Deployment	Rarely	Frequently
Budget	Lower	Higher

Key Takeaway

Start simple. Scale only when needed.

Monolithic is not a mistake — it's a starting point.

Microservices are a solution to scale, not a default choice.

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

What Really Happens When You Hit "Send" on WhatsApp Without Internet?

Kashaf Abdullah — Fri, 19 Jun 2026 18:37:38 +0000

We've all done it.

You type a message, press Send, and suddenly realize… there's no internet.

The message doesn't disappear.
It doesn't fail instantly.
Instead, it patiently waits and then magically gets delivered once the connection returns.

But what's actually happening behind the scenes?

The answer is: a surprisingly sophisticated distributed system starts working the moment you hit Send.

Let's break it down.

Step 1: Your Message Gets Stored Locally

The moment you press Send, WhatsApp doesn't immediately depend on the internet.

Your message is first stored locally on your device and marked as pending.

That's why even when you're offline, the message still appears inside your chat.

Conceptually:
User → Send
↓
Local Storage
Status = Pending

text

This local-first behavior improves reliability and user experience.

Step 2: The Message Enters an Outgoing Queue

Once stored locally, the app places the message into an outgoing queue.

Think of a queue like a waiting line.

If internet isn't available:

Message remains queued
Order is preserved
App waits instead of failing

Queues are one of the most important reliability patterns in modern systems.

Step 3: Connectivity Monitoring Starts

While the message waits, the app continuously listens for connectivity changes using operating system network signals.

The goal: Send instantly when a usable connection becomes available.

No manual retry needed.

Step 4: Retry Mechanism Kicks In

As soon as internet returns:

App detects connectivity
Pending messages are retried automatically
Messages leave the queue in order

This retry layer makes messaging feel seamless.

Without retries, users would constantly resend messages manually.

Step 5: End-to-End Encryption Happens

Before the message leaves your device, it is encrypted.

This means:

Sender can read it
Receiver can read it
Intermediate systems cannot read message content

Encryption protects privacy while the message travels across networks.

Step 6: Persistent Connections Reduce Latency

Messaging apps avoid opening a brand-new network connection for every message.

Instead, they maintain persistent connections whenever possible.

Benefits:

Faster delivery
Lower overhead
Reduced battery usage
Better real-time performance

This is one reason messages often appear to arrive instantly.

Step 7: Backend Infrastructure Handles Scale

Once the encrypted message reaches backend systems:

Load balancers distribute traffic
Messaging services process requests
Internal buffering and asynchronous processing help absorb spikes

Why? Imagine millions of users sending messages simultaneously.

Without buffering and distributed processing, systems would overload.

Step 8: Offline Recipient? Store and Deliver Later

If the receiver is offline:

Message waits temporarily
Delivery happens when receiver reconnects

That's why messaging feels reliable even across unstable networks.

Understanding WhatsApp Status Icons

Icon	Meaning
⏰	Waiting to send
✓	Server received the message
✓✓	Recipient device received it
Blue ✓✓	Recipient opened/read it (if enabled)

Complete Flow Diagram

User presses Send
│
▼
Message stored locally (Pending)
│
▼
Message added to outgoing queue
│
▼
Is internet available? ───No───▶ Wait, monitor connectivity
│ Yes │
▼ ▼
Encrypt message Internet returns
│ │
▼ ▼
Send via persistent Retry message automatically
connection to backend │
│ │
▼ ▼
Backend processes Message delivered
and routes message
│
▼
Receiver gets message

text

Code Example: Simple Offline Message Queue

// Simple offline message queue simulation
class MessageQueue {
  constructor() {
    this.queue = [];
    this.isOnline = navigator.onLine;
    this.setupListeners();
  }

  setupListeners() {
    window.addEventListener('online', () => {
      this.isOnline = true;
      this.processQueue();
    });

    window.addEventListener('offline', () => {
      this.isOnline = false;
    });
  }

  sendMessage(message) {
    this.queue.push({
      ...message,
      status: 'pending'
    });

    if (this.isOnline) {
      this.processQueue();
    }
  }

  async processQueue() {
    while (this.queue.length > 0 && this.isOnline) {
      const message = this.queue[0];
      try {
        await this.uploadToServer(message);
        this.queue.shift();
        console.log('✅ Message delivered:', message.id);
      } catch (error) {
        console.log('❌ Delivery failed, retrying later');
        break;
      }
    }
  }

  async uploadToServer(message) {
    // Simulate API call
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        if (Math.random() > 0.1) {
          resolve({ success: true });
        } else {
          reject(new Error('Network error'));
        }
      }, 1000);
    });
  }
}

// Usage
const queue = new MessageQueue();
queue.sendMessage({ id: 1, text: 'Hello World' });

Why This Design Matters

Feature	Benefit
Local-first storage	Messages don't disappear
Queues	Preserves order and reliability
Retry mechanism	No manual resend needed
Encryption	Protects privacy
Persistent connections	Fast delivery
Buffering	Handles massive scale

Final Thoughts

Sending a message feels simple.

But behind one tap exists a complete distributed architecture:

Local persistence
Retry mechanisms
Queue-based delivery
Persistent connections
Encryption
Load balancing
Real-time synchronization

All of this works together so users experience one thing:

Tap Send → Message Delivered.

And most people never notice the engineering behind it.

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

Accidentally Pushed a `.env` Secret to a Public GitHub Repo? Here's What to Do

Kashaf Abdullah — Thu, 18 Jun 2026 19:48:55 +0000

Exposing secrets in a public GitHub repository is a real production emergency. Public repositories are continuously scanned by automated bots, and leaked credentials can be discovered within minutes.

If this happens, act immediately.

1. Assess the Impact Immediately

Start by identifying exactly what was exposed.

Questions to ask:

Were API keys leaked?
Did database credentials appear in the repository?
Were cloud credentials exposed (AWS, GCP, Azure)?
Did payment gateway secrets become public?
Were JWT signing keys included?
Were admin or service tokens exposed?

The faster you understand the scope, the faster you can contain the issue.

2. Revoke and Rotate All Exposed Secrets

Deleting the file is not enough.

Assume any exposed credential has already been copied and rotate it immediately.

Generate new credentials for:

API keys
Database passwords
Access tokens
Cloud credentials
Authentication secrets
Webhook secrets

After rotation, update all environments and redeploy applications so production stops using old credentials.

3. Remove Secrets from Git History

Removing the .env file in a new commit does not erase it from earlier commits.

Clean repository history using tools such as:

git filter-repo
BFG Repo Cleaner

Once cleaned:

Force-push the updated history
Ask collaborators to re-clone or reset local repositories if necessary

Remember: history cleanup improves hygiene, but secret rotation is the actual remediation.

4. Investigate for Suspicious Activity

Review logs to determine whether exposed credentials were abused.

Check:

Cloud audit logs
Database access history
API request logs
Authentication events
Billing and usage anomalies

Look for unusual activity after the exposure timestamp.

5. Notify the Team and Stakeholders

Security incidents should be communicated clearly.

Inform relevant stakeholders such as:

Engineering teams
Security teams
Project owners
Management (if required)

Document:

What happened
What was exposed
Actions taken
Current status

Transparency helps teams respond faster and improve future processes.

6. Prevent It from Happening Again

Once the incident is resolved, strengthen your workflow.

Recommended safeguards:

Enable GitHub Secret Scanning
Add .env files to .gitignore
Use pre-commit secret detection
Add CI/CD security checks
Store secrets in dedicated secret managers
Follow least-privilege access principles

The goal isn't only fixing the leak — it's making sure the next one never happens.

Quick Checklist

Step	Action	Status
1	Assess the impact	☐
2	Revoke and rotate secrets	☐
3	Remove secrets from Git history	☐
4	Investigate for suspicious activity	☐
5	Notify team and stakeholders	☐
6	Prevent it from happening again	☐

Final Thought

Secret exposure incidents happen even to experienced teams. What matters most is how quickly you detect, rotate, contain, and improve your process afterward.

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

Found this helpful? Leave a ❤️ and bookmark it for later!

Let's discuss in the comments: Have you ever accidentally leaked secrets? What steps did you take?

How URL Shorteners Generate Unique Links Instantly

Kashaf Abdullah — Tue, 02 Jun 2026 19:01:06 +0000

How URL Shorteners Generate Unique Links

Every day, millions of people share links using services like TinyURL, Bitly, and Rebrandly. Instead of sharing a long and messy URL, these platforms convert it into a short, clean link that is easier to remember and share.

But have you ever wondered how these services generate unique short links almost instantly?

Let's break it down.

What Is a URL Shortener?

A URL shortener is a service that converts a long URL into a much shorter one.

For example:

Original URL: https://example.com/blog/how-url-shorteners-generate-unique-links-instantly

Short URL: https://short.ly/aB3xYz

When someone visits the short URL, they are automatically redirected to the original destination.

The real challenge is ensuring that every short link is unique and generated in milliseconds.

Step 1: Store the Original URL

When a user submits a URL, the system first saves it in a database.

Example:

ID	Long URL
1001	https://example.com/blog/how-url-shorteners-generate-unique-links-instantly

At this point, the database has assigned a unique ID to the URL.

Step 2: Convert the ID Into a Short Code

Most URL shorteners don't expose database IDs directly.

Instead, they convert the numeric ID into a shorter representation using Base62 encoding.

Base62 uses:

Numbers: 0–9
Lowercase letters: a–z
Uppercase letters: A–Z

This gives a total of 62 possible characters.

Examples:

ID	Base62 Code
1001	g9
500000	28CG
10000000	FXsk

The final shortened URL becomes: https://short.ly/g9

Because the database ID is already unique, the generated short code is automatically unique as well.

Why Base62?

Imagine storing URLs as plain numbers: https://short.ly/1001

This works, but it becomes longer as IDs grow.

Base62 compresses large numbers into fewer characters, making links shorter and more user-friendly.

Number	Base62
1001	g9
500,000	28CG
10,000,000	FXsk

This is why most URL shortening services use some form of Base62 encoding.

Alternative Approach: Random Code Generation

Some systems generate random strings instead of converting IDs.

Example: aB3xYz

The system checks whether the code already exists:

If it doesn't exist → code is saved
If it already exists → another code is generated

Pseudo-code:
do {
code = generateRandomString(6);
} while (codeExists(code));

save(code);

This approach works well for smaller systems but may require additional collision checks at scale.

How Redirection Works

When a user visits: https://short.ly/g9

The server looks up the short code in the database:

SELECT long_url
FROM urls
WHERE short_code = 'g9';

Result: https://example.com/blog/how-url-shorteners-generate-unique-links-instantly

The server then responds with an HTTP redirect:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/blog/how-url-shorteners-generate-unique-links-instantly

The browser automatically opens the original URL.

How Large Platforms Handle Millions of Links

Services like Bitly process enormous volumes of traffic every day. To maintain speed and uniqueness, they often:

Distribute ID ranges across multiple servers

Cache frequently accessed URLs

Use load balancers

Store mappings in highly optimized databases

Generate IDs using distributed ID systems

This ensures that links remain unique even when millions of URLs are created every day.

Final Thoughts

URL shorteners appear simple from the outside, but they solve an interesting engineering challenge: generating unique, compact links instantly while supporting massive scale.

The most common approach is surprisingly straightforward:

Store the original URL

Generate a unique database ID

Convert the ID into a Base62 string

Return the shortened URL

Redirect users back to the original URL when accessed

This combination of simplicity, speed, and scalability is what makes modern URL shortening services so effective.

How Instagram Stories disappear After Exactly 24 Hours ? Who's Counting

Kashaf Abdullah — Fri, 29 May 2026 19:31:10 +0000

1. What is happening (core idea)

When you post a story:

Instagram saves the time you posted it
Then it has a rule: show only for 24 hours
So it never "counts time" — it just compares times.

2. Like you're 5 years old

Imagine:

You put a sticker on a board at 10 AM
The rule is: "remove it after 1 day"

Now whenever someone looks at the board:

If sticker is less than 1 day old → show it
If older → don't show it

Nobody is counting seconds. They just check the time.

3. Engineer-level (simple version)

When story is uploaded:

Server stores:
created_at = time of upload

When feed is requested:

Server runs a filter:
if (now - created_at < 24 hours) {
return story;
}

So:
👉 Only fresh stories are returned
👉 Old stories are automatically ignored

4. Important clarification

"The mobile app doesn't decide anything"

Meaning:

Your phone is NOT responsible for hiding stories
Instagram server decides everything
So even if you change your phone time → nothing changes

5. What is cleanup job?

After stories expire:

They are already hidden instantly
Later, a background system deletes them permanently

Think of it like:

"First hide the item from shop shelf, then later throw it away from storage."

6. Why these design choices exist

Server-side control → prevents cheating
UTC time → same for all countries
No device dependency → consistent for everyone
Lazy deletion → saves system resources

One-line interview answer

"Instagram stories expire using server-side TTL based on created_at timestamp; the backend filters out items older than 24 hours during feed queries, and later background jobs clean up expired data."

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

Found this helpful? Leave a ❤️ and bookmark it for later!

Internal vs External Load Balancer: Key Differences Explained

Kashaf Abdullah — Mon, 18 May 2026 18:35:54 +0000

The Core Difference in One Sentence

External (Internet facing) Load Balancer: Balances traffic coming from the public internet to resources inside your private network.

Internal (Private) Load Balancer: Balances traffic coming from inside your private network to other resources also inside your private network.

External (Internet Facing) Load Balancer

How it works

It has a public IP address and is accessible from the internet. Clients (users, mobile apps, external APIs) send requests to this public IP, and the load balancer distributes those requests to backend servers (like web servers or application servers) inside your Virtual Private Cloud (VPC).

Common Use Cases

Hosting a public website or e-commerce site
Exposing a public REST API to external developers
Serving a mobile app's backend

Example

Users in different countries typing https://yourapp.com → DNS resolves to a public load balancer IP → Load balancer forwards requests to healthy web servers in your VPC.

Security Note

External load balancers often sit at the "edge" and are paired with security groups, Web Application Firewalls (WAF), and SSL/TLS termination.

Internal (Private) Load Balancer

How it works

It has only a private IP address (no public internet access). It routes traffic within your VPC or data center. Clients are typically other internal services, databases, or application components.

Common Use Cases

Microservices communication: Service A calls Service B internally
Database load balancing: Distributing read queries across database replicas
Internal API gateways: Exposing APIs only to other internal apps
Tiered architectures: Web tier (external LB) → App tier (internal LB) → Database tier

Example

Your internal order processing service needs to call the inventory service. An internal load balancer sits in front of three inventory service instances, distributing requests and hiding failures — all without ever being reachable from the internet.

Side by Side Comparison

Feature	External Load Balancer	Internal Load Balancer
IP Address	Public IP	Private IP only
Internet Access	Yes, accessible from internet	No, not accessible from internet
Traffic Source	External users, mobile apps, third-party APIs	Internal services, microservices, databases
Typical Use	Public websites, external APIs	Internal microservices, database clustering
Security	Requires WAF, SSL/TLS, DDoS protection	Only internal security groups needed
DNS	Public DNS name	Private DNS name
Subnet	Public subnet	Private subnet

Real World Architecture Example

        Internet user
              │
              ▼
    ┌─────────────────────┐
    │ External Load       │  (public IP, in public subnet)
    │ Balancer            │
    └─────────────────────┘
              │
              ▼
    ┌─────────────────────┐
    │ Web servers         │  (in private subnet)
    └─────────────────────┘
              │
              ▼
    ┌─────────────────────┐
    │ Internal Load       │  (private IP only, in private subnet)
    │ Balancer            │
    └─────────────────────┘
              │
              ▼
    ┌─────────────────────┐
    │ Application servers │  (in private subnet)
    │ + Database replicas │
    └─────────────────────┘

The External LB handles raw HTTPS from users
The Internal LB distributes API calls from web servers to app servers — never exposed to the internet

Code Example: AWS Load Balancers

External Load Balancer (Public)

// AWS CDK - External Application Load Balancer
import * as elbv2 from 'aws-cdk-lib/aws-elasticloadbalancingv2';

const externalLB = new elbv2.ApplicationLoadBalancer(this, 'ExternalLB', {
  vpc: vpc,
  internetFacing: true,  // External - public IP
  loadBalancerName: 'public-web-lb'
});

// Add listener for HTTPS traffic
externalLB.addListener('HTTPS', {
  port: 443,
  certificates: [certificate],
  defaultAction: elbv2.ListenerAction.forward([webTargetGroup])
});

Internal Load Balancer (Private)

// AWS CDK - Internal Application Load Balancer
const internalLB = new elbv2.ApplicationLoadBalancer(this, 'InternalLB', {
  vpc: vpc,
  internetFacing: false,  // Internal - private IP only
  loadBalancerName: 'internal-api-lb'
});

// Add listener for internal traffic
internalLB.addListener('HTTP', {
  port: 8080,
  defaultAction: elbv2.ListenerAction.forward([appTargetGroup])
});

When to Use Which?

Choose External Load Balancer when:

Your users are on the public internet
You're hosting a public website or API
Mobile apps need to connect to your backend
You need SSL/TLS termination for external traffic

Choose Internal Load Balancer when:

Services within your network need to communicate
You're implementing microservices architecture
You need database read replica distribution
You want to keep internal traffic private and secure

Common Cloud Provider Names

Provider	External LB Name	Internal LB Name
AWS	Internet-facing ALB/NLB	Internal ALB/NLB
Azure	Public Load Balancer	Internal Load Balancer
GCP	External HTTP(S) LB	Internal TCP/UDP LB

Key Takeaway

Type	Traffic Source	Accessibility
External	Public traffic from outside your network	Internet accessible
Internal	Private traffic from inside your network	Only within VPC

Choose External when your users are on the internet.

Choose Internal when services within your network need to talk to each other reliably at scale.

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

Understanding AI Memory: Short-Term vs Long-Term Explained

Kashaf Abdullah — Sat, 16 May 2026 12:13:25 +0000

Introduction

Artificial Intelligence (AI) is becoming smarter every day, but one of the most important concepts behind its intelligence is memory.

Just like humans, AI systems also rely on memory to process information, make decisions, and generate responses. But how does AI actually "remember" things?

In simple terms, AI memory can be divided into two main types:

Short-Term Memory
Long-Term Memory

Understanding these two types will help you better grasp how modern AI systems like ChatGPT work.

What is AI Memory?

AI memory refers to how an artificial intelligence system:

Stores information
Uses past data
Maintains context

It plays a key role in making AI responses relevant, accurate, and intelligent.

1. Short-Term Memory (Temporary Memory)

Definition

Short-term memory is the AI's ability to temporarily hold information during an active task or conversation.

How it works

When you interact with an AI:

It keeps track of recent inputs
Maintains context of the conversation
Uses that context to generate better responses

However, this memory is not permanent.

Example

When using ChatGPT:

It remembers your previous messages in the same chat
It responds based on that context
But once the session ends, the memory is gone

Key Features

Temporary
Limited capacity (context window)
Active only during a session
Helps maintain conversation flow

Analogy

Think of short-term memory like a whiteboard:

You write something, use it, and then erase it when done.

2. Long-Term Memory (Stored Knowledge)

Definition

Long-term memory refers to the AI's ability to store and retain knowledge over time.

How it works

AI models are trained on:

Books
Articles
Code
Images

This training helps the AI:

Learn patterns
Understand language
Build knowledge

This knowledge becomes part of its long-term memory.

Example

AI systems developed by OpenAI are trained on large datasets, allowing them to:

Answer questions
Generate content
Understand different topics

Key Features

Long-lasting (persistent knowledge)
Large storage capacity
Built during training phase
Used across all interactions

Analogy

Think of long-term memory like a library:

Information is stored and can be accessed whenever needed.

Quick Comparison Table

Feature	Short-Term Memory	Long-Term Memory
Duration	Temporary	Permanent
Capacity	Limited (context window)	Large (trained data)
Purpose	Maintain conversation flow	Store general knowledge
When used	During active session	Every interaction
Example	ChatGPT remembering previous message	ChatGPT knowing what Python is

Why AI Memory Matters

AI memory is essential because it:

Improves response quality
Maintains context in conversations
Enables learning from large datasets
Makes AI feel more "human-like"

Without memory, AI would:

Forget everything instantly
Give disconnected answers
Fail to understand context

Real-World Applications

AI memory is used in:

Chatbots and virtual assistants
Recommendation systems
Content generation tools
Educational platforms
Customer support automation

Technical Deep Dive: How ChatGPT Handles Memory

Short-Term Memory (Context Window)

# Simplified example of how context window works
conversation_context = [
    {"role": "user", "content": "My name is Kashaf"},
    {"role": "assistant", "content": "Nice to meet you, Kashaf!"},
    {"role": "user", "content": "What's my name?"}
]

# AI uses previous messages to answer
response = ai.generate_response(conversation_context)
# Output: "Your name is Kashaf!"

Long-Term Memory (Training)

# Simplified example of training
training_data = [
    "Python is a programming language",
    "The Earth revolves around the Sun",
    "Water boils at 100 degrees Celsius"
]

# AI learns patterns during training
model.train(training_data)

# Now AI can answer without seeing exact text
response = model.ask("What is Python?")
# Output: "Python is a programming language"

Limitations of Current AI Memory

Short-Term Memory Limitations:

Context window is limited (typically 8k to 128k tokens)
Cannot remember past sessions
Each new chat starts fresh

Long-Term Memory Limitations:

Cannot update knowledge in real-time
Training data has a cutoff date
No memory of individual users

The Future of AI Memory

AI memory is continuously evolving. In the future, we may see:

More personalized AI experiences
Systems that remember users across sessions
Smarter and more context-aware assistants
Real-time learning capabilities
Infinite context windows

Simple Summary

Type	What it does	Example
Short-Term Memory	Remembers current conversation	ChatGPT remembering what you just said
Long-Term Memory	Stores general knowledge	ChatGPT knowing facts about the world

In simple terms:

Short-term memory helps AI remember the present.

Long-term memory helps AI learn from the past.

Together, they make AI systems more powerful, useful, and human-like.

Key Takeaways

AI memory has two types: Short-term and Long-term
Short-term memory is temporary and session-based
Long-term memory comes from training on large datasets
Both types work together to make AI intelligent
AI memory is still evolving and improving

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

Aur blogs ki link bhejte raho! 🚀

Webhook vs WebSocket Explained in Simple Terms

Kashaf Abdullah — Fri, 15 May 2026 19:30:03 +0000

🪝 Webhook (Event-based, one-way)

What it is:

A webhook is a way for one system to automatically send data to another system when something happens.

You don't ask for data – it is pushed to you.

How it works:

You give your API endpoint (URL) to another service
That service watches for events
When an event happens → it sends an HTTP POST request to your URL

Example using Stripe:

1. A user completes a payment
2. Stripe sends a webhook to your server
3. Your server updates the order status → "Paid"

Key Characteristics:

One-way communication
Triggered only when an event happens
Uses normal HTTP (usually POST)
No permanent connection

When to use:

Payment notifications
GitHub push events
Form submissions
Third-party integrations

🔌 WebSocket (Real-time, two-way)

What it is:

A WebSocket creates a continuous, open connection between client and server, allowing instant two-way communication.

Both sides can send data anytime.

How it works:

Client sends a request (HTTP)
Connection is upgraded to WebSocket
Connection stays open
Data flows back and forth instantly

Example using WhatsApp:

1. You send a message
2. The other person receives it instantly
3. They reply → you get it immediately

Key Characteristics:

Two-way communication (full duplex)
Real-time (low latency)
Persistent connection
Uses ws:// or wss:// protocol

When to use:

Chat applications
Live notifications
Multiplayer games
Live dashboards (stocks, analytics)

Quick Comparison Table

Feature	Webhook	WebSocket
Direction	One-way	Two-way
Connection	Temporary	Persistent
Latency	Delayed	Real-time
Protocol	HTTP/HTTPS	ws/wss
Use case	Event notifications	Live interaction

Code Example: Webhook (Node.js)

// Receiving a webhook
app.post('/webhook', (req, res) => {
  const event = req.body;

  if (event.type === 'payment.succeeded') {
    console.log(`Payment received: ${event.amount}`);
    updateOrderStatus('paid');
  }

  res.sendStatus(200);
});

Code Example: WebSocket (Node.js with Socket.io)

// Server side
io.on('connection', (socket) => {
  console.log('User connected');

  socket.on('chat message', (msg) => {
    io.emit('chat message', msg); // Broadcast to all
  });
});

// Client side
socket.emit('chat message', 'Hello everyone!');
socket.on('chat message', (msg) => {
  console.log('Message received:', msg);
});

Simple Analogy

Webhook is like Email:

You send a message
The other person receives it
Conversation ends there (unless they reply separately)

WebSocket is like Phone Call:

You dial and connect
Both can talk anytime
Connection stays open until someone hangs up

Final Understanding

Use this	When you need
Webhook	Just need to be notified when something happens
WebSocket	Need live, real-time interaction both ways

Which One Should You Choose?

Choose Webhook if:

You need one-way notifications
Event happens occasionally
Low latency is not critical
Example: Payment confirmation, email notifications

Choose WebSocket if:

You need two-way real-time communication
Users expect instant updates
Data flows continuously
Example: Live chat, gaming, stock prices

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

Software Design Patterns

Kashaf Abdullah — Sun, 10 May 2026 18:30:37 +0000

Introduction

Design patterns are proven solutions to common software design problems. They represent best practices evolved over time by experienced developers. Think of them as blueprints you can customize to solve recurring design problems in your code.

Part 1: CREATIONAL PATTERNS

Focus: Object creation mechanisms

1. Factory Method

Problem: Create objects without specifying exact class

Use when: Object type decided at runtime

// Product classes
class Car {
  drive() { console.log("Driving car"); }
}

class Bike {
  ride() { console.log("Riding bike"); }
}

// Factory
class VehicleFactory {
  static create(type) {
    if (type === "car") return new Car();
    if (type === "bike") return new Bike();
  }
}

// Usage
const myCar = VehicleFactory.create("car");
myCar.drive(); // Driving car

2. Abstract Factory

Problem: Create families of related objects

Use when: System needs to be independent of how products are created

// Abstract products
class WinButton { render() { return "Windows Button"; } }
class MacButton { render() { return "Mac Button"; } }

// Abstract factory
class UIFactory {
  static getFactory(os) {
    if (os === "win") return new WinFactory();
    return new MacFactory();
  }
}

class WinFactory {
  createButton() { return new WinButton(); }
}

// Usage
const factory = UIFactory.getFactory("win");
const button = factory.createButton();
console.log(button.render()); // Windows Button

3. Singleton

Problem: Ensure only one instance exists

Use when: Need single point of control (database connection, config)

class Database {
  constructor() {
    if (Database.instance) return Database.instance;
    this.connection = "Connected to DB";
    Database.instance = this;
  }

  query(sql) { console.log(`Executing: ${sql}`); }
}

// Usage
const db1 = new Database();
const db2 = new Database();
console.log(db1 === db2); // true

4. Prototype

Problem: Create objects by cloning existing ones

Use when: Object creation is expensive

const carPrototype = {
  wheels: 4,
  start() { console.log("Engine started"); },
  clone() { return Object.create(this); }
};

// Usage
const sportsCar = carPrototype.clone();
sportsCar.color = "red";
sportsCar.start(); // Engine started

5. Builder

Problem: Construct complex objects step by step

Use when: Object has many optional parts

class Computer {
  constructor() {
    this.parts = [];
  }
}

class ComputerBuilder {
  constructor() {
    this.parts = [];
  }

  addCPU() { this.parts.push("Intel i7"); return this; }
  addRAM() { this.parts.push("16GB DDR4"); return this; }
  addSSD() { this.parts.push("512GB NVMe"); return this; }
  build() { return this.parts; }
}

// Usage
const gamingPC = new ComputerBuilder()
  .addCPU()
  .addRAM()
  .addSSD()
  .build();

console.log(gamingPC); // ["Intel i7", "16GB DDR4", "512GB NVMe"]

Part 2: STRUCTURAL PATTERNS

Focus: Class and object composition

6. Adapter

Problem: Make incompatible interfaces work together

Use when: Need to integrate old code with new system

// Old system
class OldAPI {
  getUserData() { return { name: "John", age: 30 }; }
}

// New expected format
class UserAdapter {
  constructor(oldAPI) { 
    this.oldAPI = oldAPI; 
  }

  getUser() {
    const data = this.oldAPI.getUserData();
    return `${data.name} is ${data.age} years old`;
  }
}

// Usage
const oldAPI = new OldAPI();
const adapter = new UserAdapter(oldAPI);
console.log(adapter.getUser()); // John is 30 years old

7. Bridge

Problem: Separate abstraction from implementation

Use when: Want to avoid permanent binding between abstraction and implementation

// Implementation
class LEDTV { on() { console.log("LED TV ON"); } }
class OLEDTV { on() { console.log("OLED TV ON"); } }

// Abstraction
class Remote {
  constructor(tv) { this.tv = tv; }
  powerOn() { this.tv.on(); }
}

// Usage
const ledTV = new LEDTV();
const remote = new Remote(ledTV);
remote.powerOn(); // LED TV ON

8. Composite

Problem: Treat individual and group objects uniformly

Use when: Need tree structure of objects

class File {
  constructor(name) { this.name = name; }
  display() { console.log(`File: ${this.name}`); }
}

class Folder {
  constructor(name) {
    this.name = name;
    this.children = [];
  }

  add(item) { this.children.push(item); }

  display() {
    console.log(`Folder: ${this.name}`);
    this.children.forEach(child => child.display());
  }
}

// Usage
const file1 = new File("doc.txt");
const file2 = new File("image.jpg");
const folder = new Folder("Documents");

folder.add(file1);
folder.add(file2);
folder.display();

9. Decorator

Problem: Add behavior dynamically without modifying class

Use when: Need to extend functionality at runtime

class Coffee {
  cost() { return 5; }
  description() { return "Coffee"; }
}

class MilkDecorator {
  constructor(coffee) { this.coffee = coffee; }
  cost() { return this.coffee.cost() + 2; }
  description() { return this.coffee.description() + ", Milk"; }
}

// Usage
let myCoffee = new Coffee();
myCoffee = new MilkDecorator(myCoffee);
console.log(myCoffee.description()); // Coffee, Milk
console.log(myCoffee.cost()); // 7

10. Facade

Problem: Provide simple interface to complex subsystem

Use when: Want to hide system complexity

// Complex subsystems
class CPU { freeze() { console.log("CPU frozen"); } }
class Memory { load() { console.log("Memory loaded"); } }
class HardDrive { read() { console.log("Hard drive reading"); } }

// Facade
class Computer {
  constructor() {
    this.cpu = new CPU();
    this.memory = new Memory();
    this.hdd = new HardDrive();
  }

  start() {
    this.cpu.freeze();
    this.memory.load();
    this.hdd.read();
    console.log("Computer started!");
  }
}

// Usage
const pc = new Computer();
pc.start(); // Clean, simple interface

11. Flyweight

Problem: Share objects to support large numbers efficiently

Use when: Many similar objects, memory is concern

// Shared object
class Character {
  constructor(char) { this.char = char; }
  display(x, y) { console.log(`'${this.char}' at (${x},${y})`); }
}

// Factory
class CharacterFactory {
  constructor() { this.chars = {}; }

  get(char) {
    if (!this.chars[char]) {
      this.chars[char] = new Character(char);
    }
    return this.chars[char];
  }
}

// Usage
const factory = new CharacterFactory();
const a1 = factory.get('A');
const a2 = factory.get('A');
console.log(a1 === a2); // true (same object)

12. Proxy

Problem: Control access to object

Use when: Need lazy loading, access control, logging

class RealImage {
  constructor(filename) {
    this.filename = filename;
    this.loadFromDisk();
  }

  loadFromDisk() { console.log(`Loading ${this.filename}`); }
  display() { console.log(`Displaying ${this.filename}`); }
}

class ProxyImage {
  constructor(filename) {
    this.filename = filename;
    this.realImage = null;
  }

  display() {
    if (!this.realImage) {
      this.realImage = new RealImage(this.filename);
    }
    this.realImage.display();
  }
}

// Usage
const image = new ProxyImage("photo.jpg");
image.display(); // Loads and displays
image.display(); // Only displays (already loaded)

Part 3: BEHAVIORAL PATTERNS

Focus: Object communication and responsibility

13. Command

Problem: Encapsulate request as object

Use when: Need to parameterize, queue, or log requests

class Light {
  on() { console.log("Light ON"); }
  off() { console.log("Light OFF"); }
}

class Command {
  constructor(receiver) { this.receiver = receiver; }
  execute() {}
}

class LightOnCommand extends Command {
  execute() { this.receiver.on(); }
}

class Remote {
  setCommand(cmd) { this.command = cmd; }
  press() { this.command.execute(); }
}

// Usage
const light = new Light();
const onCommand = new LightOnCommand(light);
const remote = new Remote();

remote.setCommand(onCommand);
remote.press(); // Light ON

14. Iterator

Problem: Access elements sequentially without exposing structure

Use when: Need to traverse collection

class Playlist {
  constructor() { this.songs = []; }

  add(song) { this.songs.push(song); }

  [Symbol.iterator]() {
    let index = 0;
    let songs = this.songs;

    return {
      next() {
        if (index < songs.length) {
          return { value: songs[index++], done: false };
        }
        return { done: true };
      }
    };
  }
}

// Usage
const playlist = new Playlist();
playlist.add("Song 1");
playlist.add("Song 2");

for (let song of playlist) {
  console.log(song); // Song 1, Song 2
}

15. Mediator

Problem: Reduce direct communication between objects

Use when: Many-to-many communication needed

class ChatRoom {
  constructor() { this.users = []; }

  add(user) {
    this.users.push(user);
    user.room = this;
  }

  send(message, from) {
    this.users.forEach(user => {
      if (user !== from) {
        user.receive(message, from.name);
      }
    });
  }
}

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

  send(message) { this.room.send(message, this); }

  receive(message, from) {
    console.log(`${this.name} got: "${message}" from ${from}`);
  }
}

// Usage
const room = new ChatRoom();
const ali = new User("Ali");
const ahmed = new User("Ahmed");

room.add(ali);
room.add(ahmed);
ali.send("Hello!"); // Ahmed got: "Hello!" from Ali

16. Memento

Problem: Save and restore object state

Use when: Need undo/redo functionality

class Editor {
  constructor() { this.content = ""; }

  write(text) { this.content += text; }
  save() { return new Memento(this.content); }
  restore(m) { this.content = m.content; }
}

class Memento {
  constructor(content) { this.content = content; }
}

// Usage
const editor = new Editor();
editor.write("Hello ");
const saved = editor.save();
editor.write("World");

console.log(editor.content); // Hello World

editor.restore(saved);
console.log(editor.content); // Hello

17. Observer

Problem: Notify multiple objects about state changes

Use when: One-to-many dependency needed

class NewsChannel {
  constructor() {
    this.subscribers = [];
    this.news = "";
  }

  subscribe(sub) { this.subscribers.push(sub); }

  setNews(news) {
    this.news = news;
    this.notify();
  }

  notify() {
    this.subscribers.forEach(sub => sub.update(this.news));
  }
}

class Subscriber {
  constructor(name) { this.name = name; }
  update(news) { console.log(`${this.name} got news: ${news}`); }
}

// Usage
const channel = new NewsChannel();
const ali = new Subscriber("Ali");

channel.subscribe(ali);
channel.setNews("Breaking: Design Patterns!");
// Ali got news: Breaking: Design Patterns!

18. State

Problem: Change behavior based on internal state

Use when: Object has many states with different behaviors

class TrafficLight {
  constructor() { this.state = new RedState(); }

  change() {
    this.state.handle();
    this.state = this.state.next();
  }
}

class RedState {
  handle() { console.log("RED: Stop"); }
  next() { return new GreenState(); }
}

class GreenState {
  handle() { console.log("GREEN: Go"); }
  next() { return new YellowState(); }
}

class YellowState {
  handle() { console.log("YELLOW: Wait"); }
  next() { return new RedState(); }
}

// Usage
const light = new TrafficLight();
light.change(); // RED: Stop
light.change(); // GREEN: Go
light.change(); // YELLOW: Wait

19. Strategy

Problem: Select algorithm at runtime

Use when: Multiple algorithms for same task

class Payment {
  constructor(strategy) { this.strategy = strategy; }
  pay(amount) { this.strategy.pay(amount); }
}

class CreditCard {
  pay(amount) { console.log(`Paid $${amount} with Credit Card`); }
}

class PayPal {
  pay(amount) { console.log(`Paid $${amount} with PayPal`); }
}

class Crypto {
  pay(amount) { console.log(`Paid $${amount} with Bitcoin`); }
}

// Usage
const payment = new Payment(new CreditCard());
payment.pay(100); // Paid $100 with Credit Card

payment.strategy = new PayPal();
payment.pay(50); // Paid $50 with PayPal

20. Template Method

Problem: Define skeleton with customizable steps

Use when: Steps are same but implementations differ

class DataProcessor {
  process() {
    this.loadData();
    this.processData();
    this.saveData();
  }

  loadData() { console.log("Loading data..."); }
  saveData() { console.log("Saving data..."); }
}

class CSVProcessor extends DataProcessor {
  processData() { console.log("Processing CSV data"); }
}

class JSONProcessor extends DataProcessor {
  processData() { console.log("Processing JSON data"); }
}

// Usage
const csv = new CSVProcessor();
csv.process(); // Loading > Processing CSV > Saving

21. Visitor

Problem: Add operations to objects without modifying them

Use when: Many unrelated operations on same objects

class Car {
  accept(visitor) { visitor.visitCar(this); }
}

class Bike {
  accept(visitor) { visitor.visitBike(this); }
}

class TaxCalculator {
  visitCar(car) { console.log("Car tax: $200"); }
  visitBike(bike) { console.log("Bike tax: $50"); }
}

class InsuranceCalculator {
  visitCar(car) { console.log("Car insurance: $500"); }
  visitBike(bike) { console.log("Bike insurance: $100"); }
}

// Usage
const car = new Car();
const tax = new TaxCalculator();
car.accept(tax); // Car tax: $200

Quick Reference Table

Need	Pattern
Need one instance only	Singleton
Need to create objects	Factory / Abstract Factory
Need to add features dynamically	Decorator
Need to notify others of changes	Observer
Need to choose algorithm at runtime	Strategy
Need to undo/redo actions	Command / Memento
Need to traverse a collection	Iterator
Need to simplify complex subsystem	Facade
Need to handle many similar objects	Flyweight
Need to control access to object	Proxy

When to Use What?

Need one instance only? → Singleton
Need to create objects? → Factory / Abstract Factory
Need to add features? → Decorator
Need to notify others? → Observer
Need to choose algorithm? → Strategy
Need to undo actions? → Command / Memento
Need to traverse collection? → Iterator
Need to simplify complex system? → Facade

Conclusion

Design patterns are not templates to copy-paste, but guidelines to solve common problems. Master these 23 patterns, and you'll:

Write more maintainable code
Communicate better with other developers
Solve design problems faster
Build more flexible systems

Remember: Don't force patterns where they're not needed. Use them when they genuinely solve a problem! 🎯

Resources

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development

From Raw Text to Formatted Word Doc in Your Drive

Kashaf Abdullah — Sat, 09 May 2026 19:29:04 +0000

Building a Serverless Notes App

I wanted a simple tool where I could paste raw text and have it automatically saved as a formatted Word document in my Google Drive – no server, no database, just a clean React app. That's how Notes to Drive was born.

The Problem

Most note taking apps are either too complex or don't give you Word documents. I wanted something minimal: type text, pick a folder, save as .docx to Drive. Simple. But building it came with some real challenges I didn't expect.

What I Used

The entire app is built with React and Vite.

For generating Word documents inside the browser, I used docx.js loaded via CDN (not npm) because the npm version is Node.js only and crashes in the browser.

To read existing .docx files for the "append" feature, I used mammoth.js, also via CDN.

Authentication and Drive access is handled entirely through Google Identity Services and the Google Drive REST API v3.

Setting Up Google Drive API

This was the trickiest part. Here's what you need to do:

Step 1: Go to Google Cloud Console and create a new project

Step 2: Enable the Google Drive API

Step 3: Set up an OAuth consent screen

Set the app to External

Add your own email as a test user (important – without this you get a 403 error)

Add the scope "drive.file" for uploading and "drive.readonly" for listing folders

Step 4: Create an OAuth 2.0 Client ID under Credentials

Set application type to Web Application

Add your localhost URL – in Vite's case that's http://localhost:5173 (not 3000, which tripped me up initially)

Step 5: Copy the Client ID and store it in a .env file as VITE_GOOGLE_CLIENT_ID

How the App Works

When a user signs in, the app uses Google Identity Services Token Client to get an OAuth access token entirely in the browser – no server callback needed.

It then:

Fetches the user's name from the Google userinfo endpoint

Loads all their Drive folders via the Drive API

The user can:

Select an existing folder from a dropdown

Type a new folder name and create it on the spot

Once a folder is selected, they type a title and their raw text, and hit save.

The Magic: Generating Word Documents

The raw text gets passed to docx.js which builds a proper Word document in memory with:

A heading

A timestamp

Each line of text as a formatted paragraph

Important: Use Packer.toBlob() – not Packer.toBuffer() or Packer.toArrayBuffer(). Both of those fail silently or throw errors in browser environments.

Uploading to Google Drive

The resulting Blob is uploaded to Google Drive using the multipart upload endpoint with FormData:

One part for the file metadata (including the parent folder ID)

One part for the actual file content

For updating existing files, the same endpoint is called with PATCH instead of POST.

The "Append to Existing" Feature

This was tricky. Here's how it works:

Download the selected .docx file from Drive

Extract its text using mammoth.js

Merge it with the new content under a new section heading

Rebuild the full document

Re-upload it to replace the original

Deployment to Netlify

Step 1: Run npm run build

Step 2: Drag the dist folder to Netlify

Step 3: Add VITE_GOOGLE_CLIENT_ID as an environment variable in site settings

Step 4: Go back to Google Cloud Console and add your Netlify URL to the Authorized JavaScript Origins of your OAuth client

Important Note: While the app is in Testing mode on Google Cloud, only emails added as test users can sign in. To make it publicly accessible, you need to publish the app to Production from the OAuth consent screen.

Common Pitfalls I Ran Into

Using localhost:3000 instead of 5173 for Vite

Forgetting to add test users – got 403 error

Using Packer.toBuffer() instead of Packer.toBlob()

Not adding the Netlify URL to Authorized JavaScript Origins

Links

GitHub

Live Demo

Written by Kashaf Abdullah

Software Engineer | MERN Stack | Web Development