Forem: Jack Pritom Soren

RxJS in Angular — Chapter 6 | Error Handling — Building Apps That Don't Break

Jack Pritom Soren — Fri, 10 Apr 2026 05:24:20 +0000

"Error Handling — Building Apps That Don't Break"

👋 Welcome to Chapter 6!

You've built beautiful features using Observables. But what happens when the internet goes down? What if the API server crashes? What if the user has no signal?

In the real world, things go wrong. All the time.

This chapter teaches you how to handle errors gracefully — so your app stays alive even when everything around it falls apart.

💥 What Happens When an Observable Errors?

When an Observable encounters an error, it:

Emits the error to the error handler in subscribe
Stops completely — no more values, ever

this.http.get('/api/users').subscribe({
  next: (users) => { this.users = users; },
  error: (err) => {
    // ❌ Error happened here
    // The Observable is now dead. It will never emit again.
    console.error(err);
  },
  complete: () => {
    // This will NOT be called if there was an error
  }
});

The problem? If you handle errors only in subscribe, you can't retry, you can't provide fallback data, and you can't do complex error logic.

That's where catchError and retry come in.

🥅 `catchError` — Catch it Before it Reaches subscribe

catchError goes inside pipe() and intercepts errors before they reach subscribe. It gives you a chance to:

Provide fallback data so the app keeps working
Rethrow the error if you want subscribe to handle it
Log the error and recover

import { catchError } from 'rxjs/operators';
import { of, EMPTY, throwError } from 'rxjs';

this.http.get<User[]>('/api/users')
  .pipe(
    catchError(error => {
      console.error('API failed:', error);

      // Option 1: Return fallback data — app keeps working
      return of([]);  // Return empty array

      // Option 2: Return EMPTY — complete without any value
      // return EMPTY;

      // Option 3: Re-throw — let subscribe handle it
      // return throwError(() => error);
    })
  )
  .subscribe(users => {
    // If API failed, users = [] (empty array from fallback)
    // App still works!
    this.users = users;
  });

🏗️ Real-World Pattern — Service with Error Handling

user.service.ts

import { Injectable } from '@angular/core';
import { HttpClient, HttpErrorResponse } from '@angular/common/http';
import { Observable, throwError } from 'rxjs';
import { catchError, tap } from 'rxjs/operators';

@Injectable({ providedIn: 'root' })
export class UserService {

  constructor(private http: HttpClient) {}

  getUsers(): Observable<User[]> {
    return this.http.get<User[]>('/api/users')
      .pipe(
        catchError(this.handleError)
      );
  }

  getUserById(id: number): Observable<User> {
    return this.http.get<User>(`/api/users/${id}`)
      .pipe(
        catchError(this.handleError)
      );
  }

  // Centralized error handler — reused across all methods
  private handleError(error: HttpErrorResponse): Observable<never> {

    let userFriendlyMessage = 'Something went wrong. Please try again.';

    if (error.status === 0) {
      // Network error (no internet, server unreachable)
      userFriendlyMessage = 'No internet connection. Please check your network.';
    } else if (error.status === 404) {
      userFriendlyMessage = 'The requested data was not found.';
    } else if (error.status === 401) {
      userFriendlyMessage = 'You are not authorized. Please log in.';
    } else if (error.status === 403) {
      userFriendlyMessage = 'Access denied. You do not have permission.';
    } else if (error.status === 500) {
      userFriendlyMessage = 'Server error. Please try again later.';
    }

    // Log technical details for developers
    console.error(`HTTP Error ${error.status}:`, error.message);

    // Re-throw with user-friendly message
    return throwError(() => new Error(userFriendlyMessage));
  }
}

users.component.ts

@Component({
  template: `
    <!-- Loading state -->
    <div *ngIf="isLoading" class="loading">
      <div class="spinner"></div>
      Loading users...
    </div>

    <!-- Error state -->
    <div *ngIf="errorMessage" class="error-card">
      <p>⚠️ {{ errorMessage }}</p>
      <button (click)="loadUsers()">Try Again 🔄</button>
    </div>

    <!-- Success state -->
    <div *ngIf="!isLoading && !errorMessage">
      <div *ngFor="let user of users" class="user-card">
        {{ user.name }}
      </div>
    </div>
  `
})
export class UsersComponent implements OnInit {

  users: User[] = [];
  isLoading = false;
  errorMessage = '';

  constructor(private userService: UserService) {}

  ngOnInit(): void {
    this.loadUsers();
  }

  loadUsers(): void {
    this.isLoading = true;
    this.errorMessage = '';

    this.userService.getUsers().subscribe({
      next: (users) => {
        this.users = users;
        this.isLoading = false;
      },
      error: (err) => {
        this.errorMessage = err.message;
        this.isLoading = false;
      }
    });
  }
}

🔄 `retry()` — Automatically Try Again

Sometimes errors are temporary — a brief network hiccup, a server that's momentarily busy. retry() tells the Observable to try again automatically.

import { retry } from 'rxjs/operators';

this.http.get('/api/data')
  .pipe(
    retry(3),       // Try up to 3 times before giving up
    catchError(err => {
      // Only reaches here if all 3 retries fail
      return of({ fallback: true, data: [] });
    })
  )
  .subscribe(data => this.data = data);

Timeline:

Attempt 1 → ❌ fails
Attempt 2 → ❌ fails  
Attempt 3 → ❌ fails
→ catchError takes over → returns fallback data

⏱️ `retryWhen` / `retry` with Delay — Smart Retrying

Retrying immediately might not help. Often you want to wait a bit before retrying. In modern RxJS, you can pass a config to retry:

import { retry, catchError } from 'rxjs/operators';
import { timer } from 'rxjs';

this.http.get('/api/data')
  .pipe(
    retry({
      count: 3,          // Max 3 retries
      delay: 2000        // Wait 2 seconds between each retry
    }),
    catchError(err => {
      console.error('Failed after 3 retries:', err);
      return of([]);
    })
  )
  .subscribe(data => this.data = data);

Exponential Backoff (Advanced) — Wait longer each time

import { retry } from 'rxjs/operators';
import { timer } from 'rxjs';

this.http.get('/api/critical-data')
  .pipe(
    retry({
      count: 4,
      delay: (error, retryCount) => {
        // Wait 1s, then 2s, then 4s, then 8s (exponential)
        const waitMs = Math.pow(2, retryCount) * 1000;
        console.log(`Retry ${retryCount} in ${waitMs}ms`);
        return timer(waitMs);
      }
    }),
    catchError(err => of({ error: true, message: err.message }))
  )
  .subscribe(data => this.data = data);

🔁 `finalize()` — Always Runs, Error or Not

finalize() runs when an Observable completes — whether successfully or with an error. It's like finally in try/catch.

Perfect for: hiding loading spinners

import { finalize } from 'rxjs/operators';

this.isLoading = true;

this.http.get('/api/data')
  .pipe(
    catchError(err => {
      this.error = err.message;
      return EMPTY;
    }),
    finalize(() => {
      // Always runs — success or failure!
      this.isLoading = false;
      console.log('Request complete (success or error)');
    })
  )
  .subscribe(data => this.data = data);

No more duplicating this.isLoading = false in both next and error handlers! 🎉

🌐 Global HTTP Error Handling with Interceptors

In a real app, you don't want to handle auth errors (401) in every single component. Use an HTTP Interceptor to handle errors globally:

auth.interceptor.ts

import { Injectable } from '@angular/core';
import {
  HttpRequest,
  HttpHandler,
  HttpEvent,
  HttpInterceptor,
  HttpErrorResponse
} from '@angular/common/http';
import { Observable, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';
import { Router } from '@angular/router';
import { AuthService } from './auth.service';

@Injectable()
export class AuthInterceptor implements HttpInterceptor {

  constructor(private router: Router, private authService: AuthService) {}

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {

    // Add auth token to every request
    const token = localStorage.getItem('token');
    if (token) {
      request = request.clone({
        setHeaders: { Authorization: `Bearer ${token}` }
      });
    }

    return next.handle(request).pipe(
      catchError((error: HttpErrorResponse) => {

        if (error.status === 401) {
          // Token expired — log out and redirect to login
          this.authService.logout();
          this.router.navigate(['/login']);
        }

        if (error.status === 403) {
          // No permission — redirect to forbidden page
          this.router.navigate(['/forbidden']);
        }

        if (error.status >= 500) {
          // Server error — show a global toast notification
          this.notificationService.showError('Server error. Please try again later.');
        }

        return throwError(() => error);
      })
    );
  }
}

Register it in app.module.ts

@NgModule({
  providers: [
    {
      provide: HTTP_INTERCEPTORS,
      useClass: AuthInterceptor,
      multi: true
    }
  ]
})
export class AppModule {}

Now ALL HTTP errors in your entire app are handled in one place! 🎯

🎨 Real-World Complete Example — Product Page with Full Error Handling

import { Component, OnInit } from '@angular/core';
import { Observable, of } from 'rxjs';
import { catchError, retry, finalize, tap } from 'rxjs/operators';

interface PageState {
  products: Product[];
  isLoading: boolean;
  error: string | null;
}

@Component({
  selector: 'app-product-page',
  template: `
    <ng-container *ngIf="state$ | async as state">

      <!-- Loading -->
      <div *ngIf="state.isLoading" class="loading-container">
        <div class="spinner"></div>
        <p>Loading products...</p>
      </div>

      <!-- Error with retry button -->
      <div *ngIf="state.error && !state.isLoading" class="error-container">
        <h3>😕 Oops! Something went wrong</h3>
        <p>{{ state.error }}</p>
        <button (click)="reload()">🔄 Try Again</button>
      </div>

      <!-- Empty state -->
      <div *ngIf="!state.isLoading && !state.error && state.products.length === 0">
        <p>No products found.</p>
      </div>

      <!-- Product list -->
      <div *ngIf="!state.isLoading && !state.error && state.products.length > 0">
        <div *ngFor="let product of state.products" class="product-card">
          <h3>{{ product.name }}</h3>
          <p>৳{{ product.price }}</p>
        </div>
      </div>

    </ng-container>
  `
})
export class ProductPageComponent implements OnInit {

  state$!: Observable<PageState>;

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    this.load();
  }

  reload(): void {
    this.load();
  }

  private load(): void {
    // Start with loading state
    const initialState: PageState = {
      products: [],
      isLoading: true,
      error: null
    };

    this.state$ = this.productService.getProducts()
      .pipe(
        retry(2),   // Try 2 more times on failure
        tap(products => {
          // Could log analytics here
          console.log(`Loaded ${products.length} products`);
        }),
        map(products => ({
          products,
          isLoading: false,
          error: null
        } as PageState)),
        catchError(err => of({
          products: [],
          isLoading: false,
          error: err.message || 'Failed to load products'
        } as PageState)),
        startWith(initialState)
      );
  }
}

This component handles every possible state: loading, error, empty, and success — all through a single Observable stream! 🏆

🧠 Chapter 6 Summary — What You Learned

When an Observable errors, it stops permanently — no more values
catchError() intercepts errors in the pipe and lets you provide fallback data or rethrow
retry(n) automatically retries the Observable up to N times before giving up
Use retry with a delay config for production-grade retry logic with exponential backoff
finalize() always runs whether the Observable succeeded or failed — perfect for hiding loading spinners
Use HTTP Interceptors to handle common errors (401, 500) globally for the whole app
Pattern: retry → catchError → finalize — this chain covers almost every real-world case

📚 Coming Up in Chapter 7...

We've handled errors. Now let's talk about combining multiple Observables — what if you need data from TWO different APIs at the same time?

Chapter 7 covers forkJoin, combineLatest, zip, and withLatestFrom — the combination operators!

See you in Chapter 7! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 6 of 10

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 5 | Subject, BehaviorSubject & ReplaySubject — The Two-Way Radio

Jack Pritom Soren — Sun, 05 Apr 2026 04:15:45 +0000

"Subject, BehaviorSubject & ReplaySubject — The Two-Way Radio"

👋 Welcome to Chapter 5!

So far, everything we've done has been one-directional: an Observable produces data and you subscribe to receive it.

But what if YOU want to push data into a stream? What if you need to broadcast data to multiple components — like a shared shopping cart?

Enter: Subject 🎙️

📻 The Two-Way Radio Analogy

A regular Observable is like a radio broadcast station:

The station sends signals
You tune in (subscribe) to receive
You can't talk back to the station

A Subject is like a two-way radio:

You can SEND data into it
AND you can RECEIVE data from it
Multiple people can listen to the same channel

This makes Subject perfect for sharing data between components and event broadcasting.

🔴 What is a Subject?

A Subject is both an Observable AND an Observer at the same time.

As an Observable — you can subscribe to it
As an Observer — you can push values into it using .next()

import { Subject } from 'rxjs';

// Create a Subject
const mySubject = new Subject<string>();

// Subscribe to it (like a regular Observable)
mySubject.subscribe(value => console.log('Subscriber A got:', value));
mySubject.subscribe(value => console.log('Subscriber B got:', value));

// Push values INTO it (this is the special part!)
mySubject.next('Hello!');
mySubject.next('How are you?');

// Output:
// Subscriber A got: Hello!
// Subscriber B got: Hello!
// Subscriber A got: How are you?
// Subscriber B got: How are you?

Both subscribers got both values! This is called multicasting — one source, many listeners.

⚠️ Subject's Big Limitation

A regular Subject only delivers values to subscribers that are currently listening.

If you subscribe AFTER a value was emitted, you missed it.

const subject = new Subject<number>();

subject.next(1);  // Emitted before anyone subscribed!
subject.next(2);  // Also emitted before anyone subscribed!

// Subscribe now — too late for 1 and 2
subject.subscribe(v => console.log('Got:', v));

subject.next(3);  // ✅ This one gets received

// Output: Got: 3
// 1 and 2 are gone forever

This is like tuning into a radio broadcast after a song already played. You missed it.

That's why we have BehaviorSubject and ReplaySubject.

🎯 BehaviorSubject — Remembers the Last Value

BehaviorSubject always remembers its latest value and gives it immediately to any new subscriber.

Think of it like a whiteboard 📋 — it always shows the most recent thing written on it, even if you just walked into the room.

Rules of BehaviorSubject:

Must be initialized with a starting value
Always has a current value (accessible via .value)
New subscribers get the current value immediately upon subscribing
Emits new values to all current subscribers

import { BehaviorSubject } from 'rxjs';

// Must provide an initial value
const userStatus = new BehaviorSubject<string>('offline');

console.log('Current value:', userStatus.value); // 'offline'

// Subscribe now
userStatus.subscribe(status => console.log('Subscriber 1:', status));
// Output immediately: Subscriber 1: offline (gets current value!)

// Update the value
userStatus.next('online');
// Output: Subscriber 1: online

// New subscriber AFTER 'online' was emitted
userStatus.subscribe(status => console.log('Subscriber 2:', status));
// Output immediately: Subscriber 2: online (gets latest value, not 'offline'!)

🛒 Real-World Example — Shopping Cart Service

BehaviorSubject is PERFECT for shared state like a shopping cart:

cart.service.ts

import { Injectable } from '@angular/core';
import { BehaviorSubject, Observable } from 'rxjs';
import { map } from 'rxjs/operators';

export interface CartItem {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

@Injectable({
  providedIn: 'root'
})
export class CartService {

  // BehaviorSubject: starts with empty array
  // Private so only this service can push values
  private cartItemsSubject = new BehaviorSubject<CartItem[]>([]);

  // Public Observable: components can SUBSCRIBE but NOT push values
  // This is the security pattern — expose Observable, not Subject
  cartItems$ = this.cartItemsSubject.asObservable();

  // Derived Observables — automatically calculated from cartItems$
  cartCount$ = this.cartItems$.pipe(
    map(items => items.reduce((total, item) => total + item.quantity, 0))
  );

  cartTotal$ = this.cartItems$.pipe(
    map(items => items.reduce((total, item) => total + (item.price * item.quantity), 0))
  );

  // Add item to cart
  addItem(newItem: CartItem): void {
    const currentItems = this.cartItemsSubject.value; // Get current cart

    const existingItem = currentItems.find(item => item.id === newItem.id);

    if (existingItem) {
      // Item already in cart — increase quantity
      const updated = currentItems.map(item =>
        item.id === newItem.id
          ? { ...item, quantity: item.quantity + 1 }
          : item
      );
      this.cartItemsSubject.next(updated); // Push new value!
    } else {
      // New item — add to cart
      this.cartItemsSubject.next([...currentItems, newItem]);
    }
  }

  // Remove item from cart
  removeItem(itemId: number): void {
    const updated = this.cartItemsSubject.value
      .filter(item => item.id !== itemId);
    this.cartItemsSubject.next(updated);
  }

  // Clear cart
  clearCart(): void {
    this.cartItemsSubject.next([]);
  }
}

cart-icon.component.ts (in the header)

@Component({
  selector: 'app-cart-icon',
  template: `
    <div class="cart-icon">
      🛒
      <span class="badge" *ngIf="(cartService.cartCount$ | async) as count">
        {{ count }}
      </span>
    </div>
  `
})
export class CartIconComponent {
  constructor(public cartService: CartService) {}
  // No ngOnDestroy needed — async pipe handles it!
}

cart-total.component.ts (in the checkout area)

@Component({
  selector: 'app-cart-total',
  template: `
    <div class="cart-summary">
      <p>Items: {{ cartService.cartCount$ | async }}</p>
      <p class="total">Total: ৳{{ cartService.cartTotal$ | async }}</p>
      <button (click)="cartService.clearCart()">Clear Cart 🗑️</button>
    </div>
  `
})
export class CartTotalComponent {
  constructor(public cartService: CartService) {}
}

product-card.component.ts (on product pages)

@Component({
  selector: 'app-product-card',
  template: `
    <div class="card">
      <h3>{{ product.name }}</h3>
      <p>৳{{ product.price }}</p>
      <button (click)="addToCart()">Add to Cart 🛒</button>
    </div>
  `
})
export class ProductCardComponent {
  @Input() product!: CartItem;

  constructor(private cartService: CartService) {}

  addToCart(): void {
    this.cartService.addItem(this.product);
    // The cart icon in the header updates AUTOMATICALLY!
    // The cart total updates AUTOMATICALLY!
    // BehaviorSubject broadcasts to ALL subscribers!
  }
}

When a user adds a product, the cart icon in the header and the total in the checkout area both update instantly — without any EventEmitter, @Input/@Output, or complex communication! 🎉

🔄 ReplaySubject — Remembers Multiple Past Values

ReplaySubject is like a DVR recording 📼 — it saves the last N values and plays them back to any new subscriber.

import { ReplaySubject } from 'rxjs';

// Remember the last 3 values
const replay = new ReplaySubject<number>(3);

replay.next(1);
replay.next(2);
replay.next(3);
replay.next(4);
replay.next(5);

// Subscribe now — gets the last 3 values replayed immediately
replay.subscribe(v => console.log('Got:', v));

// Output:
// Got: 3
// Got: 4
// Got: 5
// (Values 1 and 2 are gone, but 3, 4, 5 are replayed)

Real Use Case — Message History / Notifications

@Injectable({ providedIn: 'root' })
export class NotificationService {

  // Keep the last 5 notifications so late subscribers see recent history
  private notificationsSubject = new ReplaySubject<Notification>(5);

  notifications$ = this.notificationsSubject.asObservable();

  addNotification(message: string, type: 'success' | 'error' | 'info'): void {
    this.notificationsSubject.next({
      id: Date.now(),
      message,
      type,
      timestamp: new Date()
    });
  }
}

Even if a component subscribes after 3 notifications were emitted, it still gets those 3 notifications to display.

📡 AsyncSubject — Only Emits the Last Value on Complete

AsyncSubject only emits the LAST value, and ONLY when .complete() is called.

import { AsyncSubject } from 'rxjs';

const async$ = new AsyncSubject<number>();

async$.subscribe(v => console.log('Got:', v));

async$.next(1);
async$.next(2);
async$.next(3);

// Nothing logged yet...

async$.complete(); // NOW it emits!

// Output: Got: 3 (only the last value!)

This is rarely used but good to know.

🔐 The Security Pattern — Hide Your Subject!

A best practice: never expose a Subject directly to components. Use .asObservable() to expose a read-only view.

// ❌ BAD — any component can push data into this!
userSubject = new BehaviorSubject<User>(null);

// ✅ GOOD — only this service controls the data
private userSubject = new BehaviorSubject<User | null>(null);
user$ = this.userSubject.asObservable(); // Read-only!

// Only this service's methods can change the user
setUser(user: User): void {
  this.userSubject.next(user);
}

🏗️ Real-World Example — Auth Service with BehaviorSubject

This pattern is used in almost every real Angular app:

auth.service.ts

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { BehaviorSubject, Observable } from 'rxjs';
import { tap, map } from 'rxjs/operators';

export interface User {
  id: number;
  name: string;
  email: string;
  role: 'admin' | 'user';
}

@Injectable({ providedIn: 'root' })
export class AuthService {

  private currentUserSubject = new BehaviorSubject<User | null>(null);

  // Read-only public streams
  currentUser$ = this.currentUserSubject.asObservable();
  isLoggedIn$ = this.currentUser$.pipe(map(user => user !== null));
  isAdmin$ = this.currentUser$.pipe(map(user => user?.role === 'admin'));

  constructor(private http: HttpClient) {
    // Restore user from localStorage on app start
    const savedUser = localStorage.getItem('currentUser');
    if (savedUser) {
      this.currentUserSubject.next(JSON.parse(savedUser));
    }
  }

  login(email: string, password: string): Observable<User> {
    return this.http.post<User>('/api/login', { email, password })
      .pipe(
        tap(user => {
          localStorage.setItem('currentUser', JSON.stringify(user));
          this.currentUserSubject.next(user); // 📡 Broadcast to all listeners!
        })
      );
  }

  logout(): void {
    localStorage.removeItem('currentUser');
    this.currentUserSubject.next(null); // 📡 Broadcast logout to all!
  }

  get currentUser(): User | null {
    return this.currentUserSubject.value; // Synchronous access
  }
}

nav.component.ts

@Component({
  template: `
    <nav>
      <a routerLink="/">Home</a>
      <a routerLink="/products">Products</a>

      <!-- Only show if logged in -->
      <a *ngIf="authService.isLoggedIn$ | async" routerLink="/profile">
        Profile
      </a>

      <!-- Only show if admin -->
      <a *ngIf="authService.isAdmin$ | async" routerLink="/admin">
        Admin Panel
      </a>

      <span *ngIf="authService.currentUser$ | async as user">
        Hello, {{ user.name }}!
      </span>

      <button *ngIf="authService.isLoggedIn$ | async" (click)="logout()">
        Logout
      </button>
    </nav>
  `
})
export class NavComponent {
  constructor(public authService: AuthService) {}

  logout(): void {
    this.authService.logout();
    // Nav updates automatically because BehaviorSubject broadcast the change!
  }
}

When the user logs in, the navigation bar, user profile page, and admin section all update automatically and simultaneously — no complex event passing needed!

🧠 Choosing the Right Subject

Use Subject when:

You just need to broadcast events (button clicks, action triggers)
Late subscribers don't need previous values
Example: Notification popup triggers

Use BehaviorSubject when:

Shared state that always has a current value
New subscribers should get the current state immediately
Example: Shopping cart, auth state, theme preference, language selection

Use ReplaySubject when:

New subscribers need to see recent history
Example: Chat messages, audit log, recent notifications

🧠 Chapter 5 Summary — What You Learned

Subject is both Observable and Observer — you can push data into it AND subscribe to it
Subject only delivers to current subscribers — late subscribers miss old values
BehaviorSubject always has a current value and gives it to new subscribers immediately — perfect for shared state
ReplaySubject remembers the last N values and replays them to late subscribers
Use .asObservable() to hide the Subject and expose a read-only stream
BehaviorSubject is used in almost every real Angular app for auth state, cart, settings, etc.

📚 Coming Up in Chapter 6...

We've covered the core building blocks. Now let's tackle a very common real-world challenge:

Error Handling — What do you do when an API fails? How do you show user-friendly errors? How do you retry?

Chapter 6 covers catchError, retry, retryWhen, and best practices for bulletproof Angular apps.

See you in Chapter 6! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 5 of 10

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 4 | switchMap, mergeMap, concatMap — Observables Inside Observables

Jack Pritom Soren — Wed, 01 Apr 2026 16:53:49 +0000

👋 Welcome to Chapter 4!

Buckle up — this is the chapter that trips up even experienced developers. But don't worry. By the end, it will make total sense.

The question today is: What do you do when you have an Observable that produces values… and each value needs to trigger ANOTHER Observable?

Sounds weird? Let's make it concrete.

🤔 The Problem — Observable Inside Observable

Imagine this scenario:

You have a search box. Every time the user types, you want to search the API for results.

The user typing = Observable (stream of text values)
The API call = another Observable

So you have an Observable that needs to trigger another Observable. This is called a higher-order Observable — an Observable of Observables.

// What you WANT to do (but this DOESN'T work properly):
searchInput.valueChanges
  .pipe(
    map(searchTerm => this.http.get(`/api/search?q=${searchTerm}`))
    // ❌ Now you have an Observable of Observables! 😱
    // subscribe would give you Observable objects, not the actual data!
  )
  .subscribe(result => {
    // result is an Observable, not the search results!
    console.log(result); // Observable { ... } ← NOT what we want
  });

To fix this, we need flattening operators — switchMap, mergeMap, and concatMap.

They all do the same basic thing: subscribe to the inner Observable automatically and give you the final result.

But they behave very differently when multiple requests overlap.

🔀 The Three Brothers — An Analogy

Imagine you're asking a waiter to bring you food from 3 different restaurants.

switchMap — "Actually, cancel that last order. I changed my mind, bring me this new one instead."
→ Cancels the previous request when a new one comes in

mergeMap — "Yes, get all three orders! Bring them as they're ready, any order."
→ Runs all requests simultaneously, results come in any order

concatMap — "Wait for the first order to arrive, THEN go get the second one, THEN the third."
→ Runs requests one at a time, in order

🔀 `switchMap` — Cancel the Old, Start the New

switchMap is the most commonly used flattening operator in Angular. Use it when you only care about the most recent request.

Perfect for: Search boxes, autocomplete, navigation triggers

import { switchMap } from 'rxjs/operators';
import { fromEvent } from 'rxjs';

// Every time the user types, CANCEL the old search, start a new one
searchInput.valueChanges
  .pipe(
    debounceTime(300),  // Wait 300ms after typing stops
    switchMap(searchTerm =>
      // switchMap subscribes to the HTTP call automatically
      // If a new value comes in BEFORE this finishes, it CANCELS this request
      this.http.get<Product[]>(`/api/products?search=${searchTerm}`)
    )
  )
  .subscribe(products => {
    this.searchResults = products;  // ✅ Actual products, not an Observable!
  });

Why switchMap here?
User types "iph" → request starts. Then they type "ipho" → cancel the "iph" request and start "ipho". No outdated results! No race conditions!

Full Real-World Search Component

import { Component, OnInit } from '@angular/core';
import { FormControl } from '@angular/forms';
import { Observable } from 'rxjs';
import { debounceTime, distinctUntilChanged, switchMap, startWith } from 'rxjs/operators';

@Component({
  selector: 'app-search',
  template: `
    <input [formControl]="searchControl" placeholder="Search products..." />

    <div *ngIf="isLoading">Searching... 🔍</div>

    <div *ngFor="let product of results$ | async" class="result-item">
      <strong>{{ product.name }}</strong>
      <span>৳{{ product.price }}</span>
    </div>
  `
})
export class SearchComponent implements OnInit {

  searchControl = new FormControl('');
  results$!: Observable<Product[]>;
  isLoading = false;

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    this.results$ = this.searchControl.valueChanges.pipe(
      startWith(''),                          // Start with empty string (show all)
      debounceTime(400),                      // Wait 400ms after typing
      distinctUntilChanged(),                 // Don't search if value didn't change
      switchMap(term => {
        this.isLoading = true;
        return this.productService.search(term || '');
      }),
      tap(() => this.isLoading = false)       // Turn off loading when results arrive
    );
  }
}

⚡ `mergeMap` (aka `flatMap`) — Run Everything Simultaneously

mergeMap starts every new Observable immediately without cancelling old ones. Results come in as they finish — order is not guaranteed.

Perfect for: Parallel uploads, multiple simultaneous requests

import { mergeMap, from } from 'rxjs';

// Upload multiple files AT THE SAME TIME
const files = [file1, file2, file3];

from(files)  // from() converts an array to an Observable
  .pipe(
    mergeMap(file => this.uploadService.upload(file))
    // All 3 uploads start at the same time!
    // Results come in as each one finishes
  )
  .subscribe(uploadResult => {
    console.log('Upload complete:', uploadResult.fileName);
  });

Real Example — Load User Profiles in Parallel

// You have an array of user IDs, and want to load all profiles at once
const userIds = [1, 2, 3, 4, 5];

from(userIds)
  .pipe(
    mergeMap(id => this.http.get<User>(`/api/users/${id}`))
    // All 5 HTTP calls fire simultaneously!
  )
  .subscribe(user => {
    this.users.push(user);
    // Users appear as they load — might be out of order (5 before 3, etc.)
  });

⚠️ Warning: mergeMap can overwhelm your server if you have too many items. Use mergeMap(fn, 3) to limit concurrent requests to 3 at a time.

🚶 `concatMap` — One at a Time, In Order

concatMap waits for each Observable to complete before starting the next one. Results are always in order.

Perfect for: Sequential operations, guaranteed ordering

import { concatMap, from } from 'rxjs';

// Process steps one at a time, in order
const steps = ['step1', 'step2', 'step3'];

from(steps)
  .pipe(
    concatMap(step => this.processStep(step))
    // step1 must complete before step2 starts
    // step2 must complete before step3 starts
  )
  .subscribe(result => {
    console.log('Step completed:', result);
  });

Real Example — Onboarding Steps in Order

// After registration, run these steps IN ORDER:
// 1. Create user account
// 2. Send welcome email  
// 3. Set up default preferences

this.registrationService.register(formData)
  .pipe(
    concatMap(user => this.emailService.sendWelcome(user.email)),
    concatMap(() => this.prefService.setupDefaults())
  )
  .subscribe(() => {
    this.router.navigate(['/dashboard']);
  });

Here, the email is sent only after account creation succeeds. Preferences are set only after the email is sent. Perfect ordering! ✅

🆚 Side-by-Side Comparison

Let's say you click a button 3 times quickly (A, B, C), and each click triggers an API call.

Click A starts → [Request A takes 3 seconds]
Click B starts → [Request B takes 1 second]  
Click C starts → [Request C takes 2 seconds]

switchMap — Cancels previous

A starts → B starts (A cancelled) → C starts (B cancelled) → C finishes ✅
You get: only C's result

mergeMap — All run at once

A, B, C all run simultaneously
B finishes first → A finishes → C finishes
You get: B, A, C (out of order!)

concatMap — One at a time in order

A starts → A finishes → B starts → B finishes → C starts → C finishes
You get: A, B, C (in perfect order, but slowest)

🛍️ Complete Real-World Example — Product Detail Page with Related Items

This example uses switchMap to load a product, then mergeMap to load related items in parallel:

product-detail.component.ts

import { Component, OnInit } from '@angular/core';
import { ActivatedRoute } from '@angular/router';
import { Observable, EMPTY } from 'rxjs';
import { switchMap, mergeMap, toArray, catchError } from 'rxjs/operators';
import { from } from 'rxjs';

@Component({
  selector: 'app-product-detail',
  template: `
    <div *ngIf="product$ | async as product">
      <h1>{{ product.name }}</h1>
      <p>{{ product.description }}</p>
      <p class="price">৳{{ product.price }}</p>

      <h2>Related Products</h2>
      <div *ngFor="let related of relatedProducts$ | async">
        {{ related.name }} — ৳{{ related.price }}
      </div>
    </div>
  `
})
export class ProductDetailComponent implements OnInit {

  product$!: Observable<Product>;
  relatedProducts$!: Observable<Product[]>;

  constructor(
    private route: ActivatedRoute,
    private productService: ProductService
  ) {}

  ngOnInit(): void {

    // switchMap: When the route param changes, cancel old request, load new product
    this.product$ = this.route.params.pipe(
      switchMap(params => {
        const productId = params['id'];
        return this.productService.getProduct(productId);
      }),
      catchError(err => {
        console.error('Failed to load product', err);
        return EMPTY; // Return empty Observable on error
      })
    );

    // Load related products in parallel using mergeMap
    this.relatedProducts$ = this.product$.pipe(
      switchMap(product =>
        // Get all related IDs and load them simultaneously
        from(product.relatedIds).pipe(
          mergeMap(id => this.productService.getProduct(id)),
          toArray()  // Collect all results into one array
        )
      )
    );
  }
}

🚦 Route-Based Loading with switchMap

One of the most common real-world uses of switchMap in Angular is loading data based on route parameters:

@Component({ ... })
export class UserProfileComponent implements OnInit {

  user$!: Observable<User>;
  posts$!: Observable<Post[]>;

  constructor(
    private route: ActivatedRoute,
    private userService: UserService
  ) {}

  ngOnInit(): void {
    // Every time the URL changes (e.g., /users/1 → /users/2)
    // switchMap cancels the old request and starts a new one
    this.user$ = this.route.paramMap.pipe(
      switchMap(params => {
        const userId = params.get('id')!;
        return this.userService.getUser(userId);
      })
    );

    // Load user's posts whenever the user changes
    this.posts$ = this.user$.pipe(
      switchMap(user => this.userService.getPosts(user.id))
    );
  }
}

This is incredibly elegant! When the user navigates to /users/3, the old request for /users/2 gets automatically cancelled. No stale data. ✨

🧠 Quick Decision Guide

Use switchMap when:

Search box / autocomplete
Loading data from route params
You only care about the latest request
Cancelling outdated requests is desirable

Use mergeMap when:

Parallel uploads
Loading multiple independent items simultaneously
Order doesn't matter
You want maximum speed

Use concatMap when:

Steps must happen in order
Sequential processing
Like a queue — first in, first out

🧠 Chapter 4 Summary — What You Learned

Sometimes you need an Observable that triggers another Observable — called a higher-order Observable
switchMap — cancels the previous inner Observable when a new one starts (best for search)
mergeMap — runs all inner Observables simultaneously (best for parallel tasks)
concatMap — runs inner Observables one at a time in order (best for sequential steps)
switchMap is the most commonly used in Angular — especially for HTTP + route params
All three operators automatically subscribe to the inner Observable and give you the unwrapped result

📚 Coming Up in Chapter 5...

We've covered transformation operators. Now let's learn about Subject — the two-way radio of RxJS.

A Subject is an Observable that you can manually push values into. It's essential for sharing data between components and services!

See you in Chapter 5! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 4 of 10

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 3 | pipe()` and Operators — The Superpowers of RxJS

Jack Pritom Soren — Sat, 21 Mar 2026 19:03:10 +0000

"`pipe()` and Operators — The Superpowers of RxJS"

👋 Welcome to Chapter 3!

So far you know:

Observable = a stream of data (Chapter 1)
subscribe = how you receive data (Chapter 2)

Now here's the real magic: What if you want to transform, filter, or modify the data before it reaches you?

That's what pipe() and operators are for!

🍋 Think of it Like Making Lemonade

You have a lemon 🍋 (raw data from an API).

You don't want to eat a raw lemon. You want to:

Squeeze it (transform the data)
Filter out the seeds (filter the data)
Add sugar (modify the data)

That's what pipe() does — it's a processing pipeline that your data flows through before reaching your subscribe().

Observable → [pipe: squeeze → filter → add sugar] → subscribe gets lemonade 🍹

🔧 What is `pipe()`?

pipe() is a method on every Observable. You use it to chain operators together.

someObservable
  .pipe(
    operator1(),
    operator2(),
    operator3()
  )
  .subscribe(result => {
    console.log(result); // result has been processed by all 3 operators
  });

Think of it like an assembly line 🏭:

Raw data comes in on one end
Each operator does its job
Processed data comes out on the other end
subscribe() picks it up

🗺️ Operator #1: `map()` — Transform Your Data

map() takes every value from the Observable and transforms it into something else.

It's exactly like Array.map() — but for streams.

Simple Example:

import { of } from 'rxjs';
import { map } from 'rxjs/operators';

// of() creates an Observable that emits these values one by one
of(1, 2, 3, 4, 5)
  .pipe(
    map(number => number * 10)  // Multiply every number by 10
  )
  .subscribe(result => {
    console.log(result);
  });

// Output:
// 10
// 20
// 30
// 40
// 50

Real Angular Example — Transforming API Response

Imagine the API gives you user data but you only need the name and email:

// user.service.ts
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { map } from 'rxjs/operators';

interface ApiUser {
  id: number;
  name: string;
  username: string;
  email: string;
  phone: string;
  website: string;
  address: object; // We don't need this!
  company: object; // We don't need this either!
}

interface SimpleUser {
  name: string;
  email: string;
}

@Injectable({ providedIn: 'root' })
export class UserService {
  constructor(private http: HttpClient) {}

  // Returns only the fields we need — not the whole messy API response
  getSimpleUsers(): Observable<SimpleUser[]> {
    return this.http.get<ApiUser[]>('https://jsonplaceholder.typicode.com/users')
      .pipe(
        map(users => users.map(user => ({
          name: user.name,
          email: user.email
          // We dropped id, phone, website, address, company
        })))
      );
  }
}

// users.component.ts
@Component({
  template: `
    <div *ngFor="let user of users$ | async">
      <strong>{{ user.name }}</strong> — {{ user.email }}
    </div>
  `
})
export class UsersComponent {
  users$ = this.userService.getSimpleUsers();
  constructor(private userService: UserService) {}
}

The template only sees name and email — clean and simple! 🧹

🔍 Operator #2: `filter()` — Only Let Certain Values Through

filter() is like a bouncer at a club — only values that pass the test get through.

import { of } from 'rxjs';
import { filter } from 'rxjs/operators';

of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
  .pipe(
    filter(number => number % 2 === 0) // Only even numbers
  )
  .subscribe(n => console.log(n));

// Output: 2, 4, 6, 8, 10

Real Angular Example — Filter Active Products

// product.service.ts
getActiveProducts(): Observable<Product[]> {
  return this.http.get<Product[]>('/api/products')
    .pipe(
      map(products => products.filter(p => p.isActive === true))
      // Or using RxJS filter:
      // This filters the ARRAY inside the stream
    );
}

Or if the API emits products one at a time:

// Filter individual emissions
productStream$
  .pipe(
    filter(product => product.price > 0),     // Skip free products
    filter(product => product.stock > 0)      // Skip out-of-stock
  )
  .subscribe(product => {
    this.availableProducts.push(product);
  });

👀 Operator #3: `tap()` — Peek Without Changing Anything

tap() lets you look at the data as it flows through the pipe without modifying it.

It's perfect for debugging or doing side effects (like showing a loading spinner, logging, etc.)

import { of } from 'rxjs';
import { tap, map } from 'rxjs/operators';

of(1, 2, 3)
  .pipe(
    tap(n => console.log('Before map:', n)),  // Peek at raw value
    map(n => n * 10),
    tap(n => console.log('After map:', n))    // Peek at transformed value
  )
  .subscribe(n => console.log('Final:', n));

// Output:
// Before map: 1
// After map: 10
// Final: 10
// Before map: 2
// After map: 20
// Final: 20
// ...

Real Angular Example — Loading State with tap

// user.service.ts
getUsers(): Observable<User[]> {
  return this.http.get<User[]>('/api/users')
    .pipe(
      tap(() => console.log('HTTP request made!')),  // Debugging
      tap(users => console.log(`Received ${users.length} users`))
    );
}

// users.component.ts
@Component({
  template: `
    <div *ngIf="isLoading">Loading... ⏳</div>
    <ul *ngIf="!isLoading">
      <li *ngFor="let user of users">{{ user.name }}</li>
    </ul>
  `
})
export class UsersComponent implements OnInit {
  users: User[] = [];
  isLoading = false;

  ngOnInit() {
    this.isLoading = true;

    this.userService.getUsers()
      .pipe(
        tap(() => {
          // Side effect: set loading to false when data arrives
          this.isLoading = false;
        })
      )
      .subscribe(users => {
        this.users = users;
      });
  }
}

💡 Golden Rule of tap(): It never changes the data. It's just for peeking and side effects.

🔢 Chaining Multiple Operators

The real power is when you chain operators together:

this.http.get<Product[]>('/api/products')
  .pipe(
    tap(() => console.log('Fetching products...')),    // 1. Log it
    map(products => products.filter(p => p.active)),   // 2. Only active
    map(products => products.sort((a, b) =>            // 3. Sort by price
      a.price - b.price
    )),
    tap(products => console.log(`${products.length} products ready`)) // 4. Log result
  )
  .subscribe(products => {
    this.products = products;  // 5. Clean, sorted, active products!
  });

Data flows through each operator like water through filters 💧

🏪 Full Real-World Example — Product Catalog Page

Let's build a complete product catalog that uses pipe, map, filter, and tap:

product.service.ts

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { map, filter, tap } from 'rxjs/operators';

export interface Product {
  id: number;
  name: string;
  price: number;
  category: string;
  inStock: boolean;
  rating: number;
}

@Injectable({ providedIn: 'root' })
export class ProductService {

  constructor(private http: HttpClient) {}

  getFeaturedProducts(): Observable<Product[]> {
    return this.http.get<Product[]>('/api/products')
      .pipe(
        // Step 1: Log for debugging
        tap(products => console.log('Raw data:', products.length, 'items')),

        // Step 2: Only get in-stock products
        map(products => products.filter(p => p.inStock)),

        // Step 3: Only get high-rated products (4 stars and above)
        map(products => products.filter(p => p.rating >= 4)),

        // Step 4: Sort by rating, highest first
        map(products => [...products].sort((a, b) => b.rating - a.rating)),

        // Step 5: Take only top 10
        map(products => products.slice(0, 10)),

        // Step 6: Log final result
        tap(products => console.log('Featured products ready:', products.length))
      );
  }
}

product-catalog.component.ts

import { Component } from '@angular/core';
import { Observable } from 'rxjs';
import { Product, ProductService } from './product.service';

@Component({
  selector: 'app-product-catalog',
  template: `
    <h1>⭐ Featured Products</h1>

    <div class="product-grid">
      <div *ngFor="let product of products$ | async" class="product-card">
        <h3>{{ product.name }}</h3>
        <p class="price">৳{{ product.price }}</p>
        <p class="category">{{ product.category }}</p>
        <div class="rating">
          ⭐ {{ product.rating }}/5
        </div>
        <button>Add to Cart 🛒</button>
      </div>
    </div>

    <p *ngIf="(products$ | async)?.length === 0">
      No featured products available right now.
    </p>
  `
})
export class ProductCatalogComponent {

  products$: Observable<Product[]>;

  constructor(private productService: ProductService) {
    this.products$ = this.productService.getFeaturedProducts();
  }
}

Clean, readable, and all the messy filtering/sorting logic is in the service — not the template!

🧩 More Useful Operators — Quick Overview

Here are a few more operators you'll use frequently:

`take(n)` — Only Take First N Values

import { interval } from 'rxjs';
import { take } from 'rxjs/operators';

// interval() emits 0, 1, 2, 3... every second FOREVER
// take(5) stops it after 5 values
interval(1000)
  .pipe(take(5))
  .subscribe(n => console.log(n));
// Output: 0, 1, 2, 3, 4 (then automatically completes!)

`distinctUntilChanged()` — Skip Duplicate Values

import { of } from 'rxjs';
import { distinctUntilChanged } from 'rxjs/operators';

// Great for search inputs — don't search if the value hasn't changed
of('apple', 'apple', 'banana', 'banana', 'cherry')
  .pipe(distinctUntilChanged())
  .subscribe(v => console.log(v));
// Output: apple, banana, cherry (duplicates skipped!)

`debounceTime()` — Wait Before Processing

import { debounceTime } from 'rxjs/operators';

// Wait 300ms after the last keystroke before searching
searchInput.valueChanges
  .pipe(debounceTime(300))
  .subscribe(value => this.search(value));

`catchError()` — Handle Errors Gracefully

import { catchError } from 'rxjs/operators';
import { of } from 'rxjs';

this.http.get('/api/users')
  .pipe(
    catchError(error => {
      console.error('API failed:', error);
      return of([]); // Return empty array instead of crashing
    })
  )
  .subscribe(users => this.users = users);

🎯 When to Use What

map() — Anytime you want to transform or reshape data from the API
"I got raw API data, let me turn it into what my component needs"

filter() — When you want to skip certain values
"Only show me products that are in stock"

tap() — For debugging or side effects that shouldn't change data
"Log this, show a spinner, but don't touch the actual data"

take(n) — When you only need the first few values
"I only need the first response, then stop"

catchError() — Always use this for HTTP calls in production apps
"If the API breaks, show a nice message instead of crashing"

🧠 Chapter 3 Summary — What You Learned

pipe() is an assembly line that processes data before it reaches subscribe()
map() transforms every value into something new
filter() lets only certain values through
tap() lets you peek at data or do side effects without changing anything
You can chain multiple operators inside one pipe()
Common patterns: use map() for data transformation, filter() for filtering arrays, tap() for logging and side effects

📚 Coming Up in Chapter 4...

We've covered the basics of operators. Now it's time for one of the most confusing yet important operators in all of RxJS:

switchMap, mergeMap, and concatMap — the "flattening operators" that handle Observables inside Observables.

These are used in almost every real Angular app. Don't miss it!

See you in Chapter 4! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 3 of 10

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 2 | Subscribe & Unsubscribe — The Secret to No Memory Leaks

Jack Pritom Soren — Tue, 17 Mar 2026 06:24:45 +0000

Subscribe & Unsubscribe — The Secret to No Memory Leaks

Newsletter Series: RxJS Deep Dive for Angular Developers
Written so clearly, even a 5th grader can understand it.

👋 Welcome Back!

In Chapter 1, we learned that an Observable is like a water pipe — and subscribe() is how you open the tap to receive data.

But here's the thing nobody tells beginners:

If you forget to CLOSE the tap, water keeps flowing forever — even after you leave the room.

In code, that's called a memory leak. 💧 And it's one of the most common bugs in Angular apps.

Today we're going deep into subscribe() — how it works, all its options, and the right way to unsubscribe to keep your app healthy.

🔁 Quick Recap from Chapter 1

// Open the tap — start receiving data
this.userService.getUsers().subscribe((users) => {
  this.users = users;
});

Simple. But what happens when the component is destroyed? The subscription is still alive! Like a leaking tap 💧

🧠 Understanding Subscriptions — The Full Picture

When you call .subscribe(), it returns a Subscription object.

import { Subscription } from 'rxjs';

const subscription: Subscription = someObservable.subscribe(value => {
  console.log(value);
});

This subscription object is your remote control for the data stream. With it, you can:

Check if it's still active: subscription.closed
Stop receiving data: subscription.unsubscribe()

🍿 Story Time: The Never-Ending Movie

Imagine you went to a cinema 🎬 and started watching a movie. Then you got up and left — but the cinema kept charging you for the seat even though you're gone!

That's a memory leak. The movie (Observable) is still playing (running), and you're still paying (using memory), even though you left (component destroyed).

Unsubscribing is like telling the cinema: "I'm leaving, stop charging me."

🔴 The Problem — Memory Leak in Action

Here's a BAD example that causes a memory leak:

// ❌ BAD — causes memory leak!
@Component({
  selector: 'app-dashboard',
  template: `<p>Dashboard loaded!</p>`
})
export class DashboardComponent implements OnInit {

  constructor(private dataService: DataService) {}

  ngOnInit(): void {
    // This subscription is NEVER cleaned up!
    // Even when the component is destroyed, this keeps running.
    this.dataService.getLiveData().subscribe(data => {
      console.log('New data:', data);
    });
  }
}

When the user navigates away from this component, Angular destroys it. But the subscription to getLiveData() is still alive, still calling the callback, still using memory. If the user navigates back and forth 10 times, there are now 10 subscriptions all running at once! 😱

✅ Fix #1 — Manual Unsubscribe

The most basic way: store the subscription and unsubscribe in ngOnDestroy

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';

@Component({
  selector: 'app-dashboard',
  template: `<p>Dashboard: {{ latestData }}</p>`
})
export class DashboardComponent implements OnInit, OnDestroy {

  latestData: any;

  // Store the subscription so we can cancel it later
  private dataSubscription: Subscription = new Subscription();

  constructor(private dataService: DataService) {}

  ngOnInit(): void {
    // Start the subscription and SAVE it
    this.dataSubscription = this.dataService.getLiveData().subscribe(data => {
      this.latestData = data;
    });
  }

  ngOnDestroy(): void {
    // ✅ Component is being destroyed — CANCEL the subscription!
    this.dataSubscription.unsubscribe();
    console.log('Subscription cleaned up!');
  }
}

✅ Fix #2 — Managing Multiple Subscriptions

What if you have 3 different subscriptions? You can use one Subscription object to manage all of them using .add():

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';

@Component({
  selector: 'app-dashboard',
  template: `...`
})
export class DashboardComponent implements OnInit, OnDestroy {

  // One Subscription object to rule them all
  private subscriptions = new Subscription();

  ngOnInit(): void {

    // Add subscription 1
    this.subscriptions.add(
      this.userService.getUsers().subscribe(users => {
        this.users = users;
      })
    );

    // Add subscription 2
    this.subscriptions.add(
      this.productService.getProducts().subscribe(products => {
        this.products = products;
      })
    );

    // Add subscription 3
    this.subscriptions.add(
      this.notificationService.getAlerts().subscribe(alerts => {
        this.alerts = alerts;
      })
    );
  }

  ngOnDestroy(): void {
    // ✅ One line cancels ALL subscriptions
    this.subscriptions.unsubscribe();
  }
}

✅ Fix #3 — The Angular Way: `async` Pipe (Recommended!)

Angular has a magical pipe called async that automatically subscribes AND unsubscribes for you!

No need to manually call .subscribe() or .unsubscribe() at all!

import { Component } from '@angular/core';
import { Observable } from 'rxjs';

@Component({
  selector: 'app-users',
  template: `
    <!-- async pipe handles subscribe AND unsubscribe automatically! -->
    <ul>
      <li *ngFor="let user of users$ | async">
        {{ user.name }}
      </li>
    </ul>

    <!-- Show loading -->
    <p *ngIf="(users$ | async) === null">Loading... ⏳</p>
  `
})
export class UsersComponent {

  // Note the $ suffix — convention for Observables
  users$: Observable<User[]>;

  constructor(private userService: UserService) {
    // Just assign the Observable — don't subscribe!
    this.users$ = this.userService.getUsers();
  }

  // No ngOnDestroy needed! async pipe handles cleanup.
}

💡 Pro Tip: In Angular, variables that hold Observables are usually named with a $ at the end (like users$, data$). It's just a convention — it tells other developers "hey, this is an Observable!"

✅ Fix #4 — `takeUntil` Pattern (Advanced but Powerful)

This is the pattern used in large Angular applications. You create a special "destroy signal" Subject (we'll cover Subject later), and use takeUntil to automatically unsubscribe from everything when the component dies.

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';

@Component({
  selector: 'app-dashboard',
  template: `...`
})
export class DashboardComponent implements OnInit, OnDestroy {

  // This is our "destroy signal"
  private destroy$ = new Subject<void>();

  ngOnInit(): void {

    // takeUntil(this.destroy$) means:
    // "Keep subscribing UNTIL destroy$ emits a value"
    this.userService.getUsers()
      .pipe(takeUntil(this.destroy$))
      .subscribe(users => {
        this.users = users;
      });

    this.productService.getProducts()
      .pipe(takeUntil(this.destroy$))
      .subscribe(products => {
        this.products = products;
      });
  }

  ngOnDestroy(): void {
    // 🔔 Fire the destroy signal — ALL subscriptions with takeUntil cancel
    this.destroy$.next();
    this.destroy$.complete();
  }
}

📋 The Full Subscribe Syntax — All Options

.subscribe() can take a full object with three handlers:

someObservable.subscribe({
  next: (value) => {
    // ✅ Called every time a new value arrives
    console.log('Got value:', value);
  },
  error: (err) => {
    // ❌ Called if something goes wrong
    console.error('Something broke:', err);
    // Note: After an error, the Observable STOPS.
    // complete() will NOT be called after error()
  },
  complete: () => {
    // 🏁 Called when the Observable says it's done
    // This is NOT called if there was an error
    console.log('Stream finished!');
  }
});

Or the shorthand (just pass a function for next):

// Short version — only handles next values
someObservable.subscribe(value => {
  console.log(value);
});

🛍️ Real World Example — E-commerce Cart Watcher

In a real e-commerce app, you might want to watch the shopping cart for changes:

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';
import { CartService } from './cart.service';

@Component({
  selector: 'app-cart-icon',
  template: `
    <div class="cart-icon">
      🛒 <span class="badge">{{ cartCount }}</span>
    </div>
  `
})
export class CartIconComponent implements OnInit, OnDestroy {

  cartCount = 0;
  private cartSub: Subscription = new Subscription();

  constructor(private cartService: CartService) {}

  ngOnInit(): void {
    // Watch the cart — update count whenever cart changes
    this.cartSub = this.cartService.cartItems$.subscribe(items => {
      this.cartCount = items.length;
    });
  }

  ngOnDestroy(): void {
    // Clean up when header component is removed
    this.cartSub.unsubscribe();
  }
}

🔍 When Do You NOT Need to Unsubscribe?

Great question! Some Observables complete themselves automatically and don't need unsubscribing:

HTTP Requests — they emit once and complete

// ✅ Safe — HTTP observables complete after one response
this.http.get('/api/users').subscribe(data => { ... });
// No need to unsubscribe — it completes on its own!

Finite Observables — they have a natural end

// ✅ Safe — of() completes immediately
of(1, 2, 3).subscribe(n => console.log(n));

You DO need to unsubscribe from:

interval() — ticks forever
fromEvent() — fires on every click/keypress forever
Custom Observables that never complete
BehaviorSubject / Subject streams from services

🧪 Full Real-World Component Example

Here's a real-world notification bell component that handles everything properly:

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
import { NotificationService } from './notification.service';

interface Notification {
  id: number;
  message: string;
  isRead: boolean;
}

@Component({
  selector: 'app-notification-bell',
  template: `
    <div class="bell-wrapper">
      <button (click)="togglePanel()">
        🔔
        <span *ngIf="unreadCount > 0" class="badge">{{ unreadCount }}</span>
      </button>

      <div *ngIf="isPanelOpen" class="notification-panel">
        <h3>Notifications</h3>
        <div *ngFor="let n of notifications"
             [class.unread]="!n.isRead">
          {{ n.message }}
        </div>
        <p *ngIf="notifications.length === 0">No notifications!</p>
      </div>
    </div>
  `
})
export class NotificationBellComponent implements OnInit, OnDestroy {

  notifications: Notification[] = [];
  unreadCount = 0;
  isPanelOpen = false;

  private destroy$ = new Subject<void>();

  constructor(private notifService: NotificationService) {}

  ngOnInit(): void {
    // Subscribe to live notifications — auto-cleanup with takeUntil
    this.notifService.notifications$
      .pipe(takeUntil(this.destroy$))
      .subscribe({
        next: (notifs) => {
          this.notifications = notifs;
          this.unreadCount = notifs.filter(n => !n.isRead).length;
        },
        error: (err) => {
          console.error('Notification error:', err);
        }
      });
  }

  togglePanel(): void {
    this.isPanelOpen = !this.isPanelOpen;
  }

  ngOnDestroy(): void {
    // All subscriptions clean up automatically
    this.destroy$.next();
    this.destroy$.complete();
  }
}

🎯 Which Method Should You Use?

Here's a simple guide:

Use async pipe when you're displaying data directly in the template — it's the cleanest, most Angular-idiomatic way.

Use takeUntil when you have logic inside the subscription that can't go in the template — this is the most popular pattern in large apps.

Use manual Subscription when you need fine-grained control over a specific subscription.

🧠 Chapter 2 Summary — What You Learned

.subscribe() returns a Subscription object
Forgetting to unsubscribe = memory leak — subscriptions keep running even after the component is gone
Use ngOnDestroy() to clean up subscriptions when a component is destroyed
The async pipe is the easiest way — it handles subscribe AND unsubscribe automatically
The takeUntil + Subject pattern is the most popular in large apps
HTTP Observables are safe — they complete themselves after one response
Interval, fromEvent, and Service streams must be manually unsubscribed

📚 Coming Up in Chapter 3...

You know how to subscribe and unsubscribe. Now it's time to learn about pipe() and operators — the superpowers that make RxJS incredibly powerful!

We'll cover map, filter, tap, and more — with real-world examples.

See you in Chapter 3! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 2 of 10

Follow me on : Github Linkedin Threads Youtube Channel

🚀 RxJS in Angular — Chapter 1 | What is RxJS? And What is an Observable?

Jack Pritom Soren — Mon, 16 Mar 2026 06:08:46 +0000

What is RxJS? And What is an Observable?

👋 Welcome to the Series!

Hey there, Angular learner! 👋

You've probably heard words like RxJS, Observable, subscribe, pipe… and thought:

"What is all this? Why does Angular use this? Do I really need this?"

YES. You absolutely need this. And by the end of this series, you will love it.

Let's start from the very beginning — zero assumptions, zero jargon. Just clear, simple, real-world understanding.

🍎 First, Let's Think About a Simple Story

Imagine you ordered a pizza online. 🍕

You placed the order. Now you're just waiting. You didn't stand at the kitchen staring. You went and watched TV. Then, when the pizza arrived, the doorbell rang, and you responded.

That's exactly how RxJS Observables work.

You subscribe to something (like placing an order)
Something happens over time (the pizza is being made)
You react when data arrives (doorbell rings, you get the pizza)

📦 What is RxJS?

RxJS stands for Reactive Extensions for JavaScript.

Think of it as a toolbox 🧰 full of tools to handle:

Data that comes over time (like user typing in a search box)
Data from the internet (like loading users from an API)
Events (like button clicks, form inputs)
Stuff that happens asynchronously (not immediately, but later)

Angular ships with RxJS built in. You don't install it separately. It's already there, waiting for you.

🔭 What is an Observable?

An Observable is like a pipe through which data flows over time.

Let's use another story:

Imagine a water pipe in your house. The water company sends water through the pipe whenever you open the tap. You don't get all the water at once — it flows continuously as long as the tap is open.

An Observable works the same way:

It's a source of data
Data can come one item at a time or many items over time
You have to open the tap (subscribe) to receive water (data)
If you close the tap (unsubscribe), data stops flowing

🧪 Let's See Real Code — Step by Step

Step 1: The Simplest Observable Ever

import { Observable } from 'rxjs';

// Creating an Observable — like setting up a water pipe
const myObservable = new Observable((observer) => {
  observer.next('Hello!');       // Send first value
  observer.next('How are you?'); // Send second value
  observer.next('Bye!');         // Send third value
  observer.complete();           // Done! No more data.
});

What's happening here?

We created an Observable using new Observable(...)
Inside, we have an observer — think of it as the delivery person
observer.next(value) — sends a value down the pipe
observer.complete() — says "I'm done, no more values"

Step 2: Subscribe — Open the Tap!

myObservable.subscribe((value) => {
  console.log('Received:', value);
});

Output:

Received: Hello!
Received: How are you?
Received: Bye!

Until you call .subscribe(), nothing happens. The Observable just sits there. It's lazy! It only starts working when someone subscribes.

💡 Key Insight: Observables are lazy — like a YouTube video that only plays when you press Play.

🅰️ Real Angular Example — HTTP Requests

The most common place you'll see Observables in Angular is with HTTP calls.

When you fetch data from an API, Angular's HttpClient returns an Observable, not just a plain value.

Setting Up (app.module.ts)

import { HttpClientModule } from '@angular/common/http';

@NgModule({
  imports: [HttpClientModule],
  // ...
})
export class AppModule {}

The Service (user.service.ts)

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

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

@Injectable({
  providedIn: 'root'
})
export class UserService {

  private apiUrl = 'https://jsonplaceholder.typicode.com/users';

  constructor(private http: HttpClient) {}

  // This returns an Observable — data will arrive in the future!
  getUsers(): Observable<User[]> {
    return this.http.get<User[]>(this.apiUrl);
    //         ^^^^ This is the Observable. Data isn't here yet!
  }
}

The Component (user-list.component.ts)

import { Component, OnInit } from '@angular/core';
import { UserService, User } from './user.service';

@Component({
  selector: 'app-user-list',
  template: `
    <h2>👥 User List</h2>

    <!-- Show loading message while data is coming -->
    <p *ngIf="isLoading">Loading users... ⏳</p>

    <!-- Show error if something went wrong -->
    <p *ngIf="errorMessage" style="color: red;">{{ errorMessage }}</p>

    <!-- Show users when data arrives -->
    <ul *ngIf="!isLoading">
      <li *ngFor="let user of users">
        {{ user.name }} — {{ user.email }}
      </li>
    </ul>
  `
})
export class UserListComponent implements OnInit {

  users: User[] = [];
  isLoading = true;
  errorMessage = '';

  constructor(private userService: UserService) {}

  ngOnInit(): void {
    // 🔔 HERE is where we SUBSCRIBE — we open the tap!
    this.userService.getUsers().subscribe({
      next: (data) => {
        // ✅ Data arrived! Store it.
        this.users = data;
        this.isLoading = false;
      },
      error: (err) => {
        // ❌ Something went wrong
        this.errorMessage = 'Failed to load users. Try again later.';
        this.isLoading = false;
      },
      complete: () => {
        // 🏁 Observable is done (optional to handle)
        console.log('All users loaded!');
      }
    });
  }
}

🎓 The Three Things an Observable Can Do

When you subscribe, you can listen for three things:

someObservable.subscribe({
  next: (value) => { /* Got a value! */ },
  error: (err)  => { /* Something broke 😱 */ },
  complete: ()  => { /* All done ✅ */ }
});

Think of it like ordering food:

next → "Your food is ready, here it is!" 🍔
error → "Sorry, we're out of that item." ❌
complete → "Your entire order is delivered, we're done!" ✅

🌊 Observable vs Promise — What's the Difference?

You may have used Promises before. Here's a simple comparison:

Promise — delivers one value, one time

// Like getting a single text message
const promise = fetch('/api/user').then(res => res.json());

Observable — can deliver many values over time

// Like getting a WhatsApp conversation — message after message
const observable = this.http.get('/api/users'); // returns Observable

Key differences:

A Promise executes immediately. An Observable is lazy (only runs when subscribed)
A Promise gives you one result. An Observable can give many results
An Observable can be cancelled (unsubscribed). A Promise cannot
Observables have superpowers — you can transform, filter, combine them (coming in later chapters!)

🏗️ Full Working Angular Example

Here's a complete mini-app that shows Observables in action:

user.service.ts

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class UserService {
  constructor(private http: HttpClient) {}

  getUser(id: number): Observable<any> {
    return this.http.get(`https://jsonplaceholder.typicode.com/users/${id}`);
  }
}

profile.component.ts

import { Component, OnInit } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-profile',
  template: `
    <div *ngIf="user">
      <h2>{{ user.name }}</h2>
      <p>Email: {{ user.email }}</p>
      <p>Phone: {{ user.phone }}</p>
      <p>Website: {{ user.website }}</p>
    </div>

    <button (click)="loadUser(1)">Load User 1</button>
    <button (click)="loadUser(2)">Load User 2</button>
  `
})
export class ProfileComponent implements OnInit {
  user: any = null;

  constructor(private userService: UserService) {}

  ngOnInit(): void {
    this.loadUser(1); // Load user 1 by default
  }

  loadUser(id: number): void {
    this.userService.getUser(id).subscribe({
      next: (data) => this.user = data,
      error: (err) => console.error('Error loading user', err)
    });
  }
}

🎯 Real World Usage — Where You'll See Observables Every Day

Here are places you'll use Observables constantly in real Angular apps:

1. HTTP Requests — loading data from APIs

this.http.get('/api/products').subscribe(...)

2. Router Events — detecting when navigation changes

this.router.events.subscribe(event => { ... })

3. Form Value Changes — reacting when a user types

this.myForm.valueChanges.subscribe(value => { ... })

4. Event Streams — button clicks, scroll events

fromEvent(button, 'click').subscribe(() => { ... })

5. Timers — running code every few seconds

interval(3000).subscribe(() => console.log('3 seconds passed!'))

⚠️ Common Mistake: Forgetting to Subscribe

// ❌ WRONG — Nothing happens! You forgot to subscribe!
this.userService.getUsers();

// ✅ CORRECT — Now it works!
this.userService.getUsers().subscribe(data => {
  this.users = data;
});

If you forget to subscribe, the Observable just sits there doing nothing. It's like placing a pizza order but never giving them your address! 🍕

🧠 Chapter 1 Summary — What You Learned

RxJS is a toolbox for handling data that arrives over time
Observable is a stream of data — like a pipe that sends values
You must subscribe to an Observable to receive its data
An Observable can emit next (values), error (problems), or complete (all done)
Angular's HttpClient returns Observables when making API calls
Observables are lazy — they don't do anything until subscribed
Observables are more powerful than Promises — they handle streams, not just single values

📚 Coming Up in Chapter 2...

Now that you know what an Observable is, we're going to learn about subscribe() in detail — including the most important thing beginners miss: how to properly clean up subscriptions to prevent memory leaks!

See you in Chapter 2! 👋

💌 RxJS Deep Dive Newsletter Series | Chapter 1 of 10
Share this with a fellow Angular developer who's confused about RxJS!

Follow me on : Github Linkedin Threads Youtube Channel

CORS: The Silent Guardian You Keep Fighting Against

Jack Pritom Soren — Wed, 11 Mar 2026 03:53:07 +0000

The Story Begins in the Early Web

Picture the early internet. The year is 2005. JavaScript is becoming powerful. Websites are starting to make network requests dynamically using XMLHttpRequest. Developers are excited. And then someone realizes something terrifying.

Imagine you're logged into your online banking portal at https://mybank.com. While that tab is open, you accidentally click a link and land on a malicious page at https://evil-hacker.com. That malicious page runs some JavaScript in the background — silently — and makes a request to https://mybank.com/transfer?amount=10000&to=hacker. Because your browser already has the authentication cookies for mybank.com, the request goes through with your credentials attached.

You just got robbed. Without clicking anything. Without knowing anything. That is the Same-Origin Policy problem that CORS was born to solve.

What Is the Same-Origin Policy (SOP)?

Before understanding CORS, you must understand the wall it's built on top of — the Same-Origin Policy.

The Same-Origin Policy is a fundamental security mechanism built into every web browser. It says:

A web page can only read data from a response if that response comes from the same origin as the page itself.

An "origin" is defined by three things working together:

Protocol + Host + Port

So https://myapp.com:443 is a completely different origin from:

http://myapp.com:443 — different protocol
https://api.myapp.com:443 — different subdomain (different host)
https://myapp.com:3000 — different port
https://anotherapp.com:443 — different domain entirely

The browser enforces this silently and aggressively. If you're on https://myapp.com and your JavaScript tries to read a response from https://api.myapp.com, the browser will block the response from being read by your JavaScript code. The request still goes out — the server still processes it — but the browser throws the data in the trash before your code can see it.

This is brilliant for security. It stops the bank robbery scenario completely. But it creates an enormous problem for modern web development.

The Modern Web's Problem: We Need Cross-Origin Requests

Modern applications are built on separation. Your frontend lives at https://myapp.com. Your API lives at https://api.myapp.com. Your auth server lives at https://auth.myapp.com. Your CDN is at https://cdn.cloudflare.com. You're calling third-party APIs like Stripe, Twilio, Google Maps.

Every single one of these is a cross-origin request.

The Same-Origin Policy, if left completely unmodified, would make modern web applications completely impossible. You couldn't build a React frontend that talks to a Node.js API. You couldn't integrate any third-party service. The entire microservices ecosystem would collapse.

The web needed a way to relax the Same-Origin Policy in a controlled, secure, explicit manner. That solution is CORS — Cross-Origin Resource Sharing.

What Is CORS, Actually?

CORS is not a security threat. CORS is not a bug. CORS is the solution.

CORS is a system — defined by the W3C and implemented by browsers — that allows servers to explicitly declare which outside origins are permitted to read their responses.

It works through a set of HTTP headers. The server uses these headers to tell the browser:

"Hey browser, I trust https://myapp.com. If a JavaScript request comes from there, go ahead and let the code read my response."

Without these headers, the browser defaults to the Same-Origin Policy — block everything from outside origins. With these headers, the server grants specific, explicit permission.

The key insight: CORS is enforced by the browser, not the server. The server doesn't block anything. The browser does. This is why CORS errors don't appear in Postman, curl, or server-to-server requests. Those tools don't implement the browser's Same-Origin Policy. Only browsers do.

The CORS Flow: What Actually Happens

Simple Requests

Some requests are classified as "simple" — they use common methods (GET, POST, HEAD) and only standard headers. For these, the browser sends the request directly with an Origin header:

GET /api/users HTTP/1.1
Host: api.myapp.com
Origin: https://myapp.com

The server responds with:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://myapp.com
Content-Type: application/json

The browser looks at Access-Control-Allow-Origin. If it matches the requesting origin (or is a wildcard *), the browser allows the JavaScript to read the response. If it's missing or doesn't match — the browser discards the response and throws a CORS error in the console. The request still happened. The data came back. But your JavaScript never sees it.

Preflight Requests — The Real Complexity

For anything more complex — PUT, DELETE, PATCH methods, custom headers like Authorization, Content-Type: application/json — the browser doesn't send the actual request first. It sends a preflight — an OPTIONS request — to ask the server for permission before sending the real request.

OPTIONS /api/users/123 HTTP/1.1
Host: api.myapp.com
Origin: https://myapp.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Authorization, Content-Type

The browser is essentially saying: "Hey, I have a client who wants to send a DELETE request with Authorization and Content-Type headers. Is that okay with you?"

The server must respond to this preflight with permission headers:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 86400

Only after the preflight succeeds does the browser send the real request. If the preflight fails, the real request never gets sent.

Access-Control-Max-Age tells the browser how long it can cache this preflight response (in seconds) so it doesn't need to send a new OPTIONS request every single time.

The Most Important CORS Headers Explained

`Access-Control-Allow-Origin`

This is the core header. It tells the browser which origin is allowed to read the response.

Access-Control-Allow-Origin: * means any origin can read this response (fine for public APIs, dangerous for authenticated endpoints).

Access-Control-Allow-Origin: https://myapp.com means only this specific origin can read it.

Critical gotcha: You cannot use * together with Access-Control-Allow-Credentials: true. It's either a wildcard (no credentials) or a specific origin (with credentials). The browser enforces this.

`Access-Control-Allow-Methods`

Lists which HTTP methods are permitted for cross-origin requests.

Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS

`Access-Control-Allow-Headers`

Lists which request headers the client is allowed to send.

Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With

`Access-Control-Allow-Credentials`

When set to true, this tells the browser that cross-origin requests can include cookies, HTTP authentication, and client-side SSL certificates.

Access-Control-Allow-Credentials: true

When you use this, Access-Control-Allow-Origin must be a specific origin — not *. The browser will reject the response otherwise.

`Access-Control-Expose-Headers`

By default, JavaScript can only read a few "safe" response headers. If you want to expose custom headers (like a pagination token or rate limit info) to the client-side JavaScript, you must explicitly expose them.

Access-Control-Expose-Headers: X-Total-Count, X-Rate-Limit-Remaining

`Access-Control-Max-Age`

How many seconds the browser should cache the preflight response. Reduces unnecessary OPTIONS requests.

Access-Control-Max-Age: 3600

When Does the CORS Error Actually Happen?

The error appears in your browser console when:

Scenario 1 — Missing CORS headers entirely. Your server doesn't send any Access-Control-Allow-Origin header. The browser sees nothing and blocks the response.

Scenario 2 — Wrong origin in the header. Your server sends Access-Control-Allow-Origin: https://myapp.com but the request comes from https://localhost:3000 during development. Mismatch. Blocked.

Scenario 3 — Preflight fails. Your DELETE or PUT request requires a preflight. Your server doesn't handle OPTIONS requests and returns a 404 or 405. The real request never fires.

Scenario 4 — Credentials mismatch. You're sending credentials: 'include' in your fetch call (to send cookies), but your server either has Access-Control-Allow-Origin: * or doesn't have Access-Control-Allow-Credentials: true. Blocked.

Scenario 5 — Header not in allowed list. You're sending a custom header like X-Custom-Token but the server's Access-Control-Allow-Headers doesn't include it. Blocked.

Solving CORS in Express.js (Node.js)

The fastest and most reliable way is using the cors npm package.

Install the Package

npm install cors

Basic Setup — Allow Everything (Development Only)

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

const app = express();

// Allow ALL origins — use only in development
app.use(cors());

app.get('/api/data', (req, res) => {
  res.json({ message: 'Hello from the API' });
});

app.listen(5000);

This is fine for local development but never use this in production on an authenticated API. Anyone from any origin can access your endpoints.

Production Setup — Specific Origins

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

const app = express();

const corsOptions = {
  origin: 'https://myapp.com',       // Only allow this origin
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,                  // Allow cookies and auth headers
  maxAge: 86400                       // Cache preflight for 24 hours
};

app.use(cors(corsOptions));

Production Setup — Multiple Allowed Origins

Most real apps need to allow multiple origins — production, staging, maybe a mobile app domain.

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

const app = express();

const allowedOrigins = [
  'https://myapp.com',
  'https://staging.myapp.com',
  'https://admin.myapp.com'
];

const corsOptions = {
  origin: function (origin, callback) {
    // Allow requests with no origin (like mobile apps, Postman, curl)
    if (!origin) return callback(null, true);

    if (allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error(`CORS policy: Origin ${origin} is not allowed`));
    }
  },
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization', 'X-Requested-With'],
  credentials: true,
  maxAge: 86400
};

app.use(cors(corsOptions));

Environment-Aware CORS Configuration

Load allowed origins from environment variables so you don't hardcode them:

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

const app = express();

// In .env file: ALLOWED_ORIGINS=https://myapp.com,https://staging.myapp.com
const allowedOrigins = process.env.ALLOWED_ORIGINS
  ? process.env.ALLOWED_ORIGINS.split(',').map(o => o.trim())
  : ['http://localhost:3000'];

const corsOptions = {
  origin: function (origin, callback) {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  maxAge: 3600
};

app.use(cors(corsOptions));

// This is CRITICAL — explicitly handle preflight OPTIONS requests
app.options('*', cors(corsOptions));

The app.options('*', cors(corsOptions)) line is important. It ensures that all preflight requests across all routes are properly handled before the route-specific middleware runs.

Route-Specific CORS

Sometimes different routes need different CORS policies — a public /api/public endpoint can allow all origins while /api/admin should be restricted.

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

const app = express();

const publicCors = cors({ origin: '*' });

const privateCors = cors({
  origin: 'https://admin.myapp.com',
  credentials: true
});

// Public endpoint — anyone can call this
app.get('/api/public/products', publicCors, (req, res) => {
  res.json({ products: [] });
});

// Private endpoint — only admin dashboard can call this
app.get('/api/admin/users', privateCors, (req, res) => {
  res.json({ users: [] });
});

Manual CORS Without the Package

If you want full control without a library:

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

app.use((req, res, next) => {
  const origin = req.headers.origin;
  const allowedOrigins = ['https://myapp.com', 'http://localhost:3000'];

  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
  }

  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, PATCH, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  res.setHeader('Access-Control-Allow-Credentials', 'true');
  res.setHeader('Access-Control-Max-Age', '86400');

  // Handle preflight
  if (req.method === 'OPTIONS') {
    return res.status(204).end();
  }

  next();
});

Solving CORS in Spring Boot (Java)

Spring Boot gives you several clean ways to configure CORS, ranging from a single annotation on a controller to a global configuration that covers your entire API.

Method 1 — `@CrossOrigin` Annotation on a Controller

The simplest approach. Add the annotation directly to a controller or a specific method.

import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/users")
@CrossOrigin(origins = "https://myapp.com")
public class UserController {

    @GetMapping
    public List<User> getAllUsers() {
        return userService.findAll();
    }

    // Only this specific method allows a different origin
    @GetMapping("/public")
    @CrossOrigin(origins = "*")
    public List<User> getPublicUsers() {
        return userService.findPublic();
    }
}

You can customize it further:

@CrossOrigin(
    origins = {"https://myapp.com", "https://staging.myapp.com"},
    methods = {RequestMethod.GET, RequestMethod.POST, RequestMethod.PUT, RequestMethod.DELETE},
    allowedHeaders = {"Content-Type", "Authorization"},
    allowCredentials = "true",
    maxAge = 3600
)

This approach is fine for small APIs but gets repetitive fast — you'd need to add it to every controller.

Method 2 — Global CORS with `WebMvcConfigurer`

This is the recommended approach for most Spring Boot applications. Define CORS in one place, apply it everywhere.

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")       // Apply to all routes under /api/
            .allowedOrigins(
                "https://myapp.com",
                "https://staging.myapp.com"
            )
            .allowedMethods("GET", "POST", "PUT", "DELETE", "PATCH", "OPTIONS")
            .allowedHeaders("Content-Type", "Authorization", "X-Requested-With")
            .allowCredentials(true)
            .maxAge(3600);
    }
}

To load origins from environment variables (the production-ready approach):

import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Value("${app.cors.allowed-origins}")
    private String[] allowedOrigins;

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
            .allowedOrigins(allowedOrigins)
            .allowedMethods("GET", "POST", "PUT", "DELETE", "PATCH", "OPTIONS")
            .allowedHeaders("*")
            .allowCredentials(true)
            .maxAge(86400);
    }
}

In application.properties:

app.cors.allowed-origins=https://myapp.com,https://staging.myapp.com

In application.yml:

app:
  cors:
    allowed-origins:
      - https://myapp.com
      - https://staging.myapp.com

Method 3 — CORS with Spring Security (The Critical One)

This is the most important one to get right. If your application uses Spring Security, you must configure CORS through Spring Security — not just through WebMvcConfigurer. If you don't, Spring Security's filter chain will reject cross-origin requests before they even reach your CORS configuration.

The wrong way (extremely common mistake):

// This alone is NOT enough when Spring Security is present
@Override
public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/**").allowedOrigins("*"); // Won't work with Spring Security!
}

The right way — configure CORS at the Security level:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.CorsConfigurationSource;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;

import java.util.Arrays;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .cors(cors -> cors.configurationSource(corsConfigurationSource()))
            .csrf(csrf -> csrf.disable()) // Disable CSRF for stateless REST APIs
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/public/**").permitAll()
                .anyRequest().authenticated()
            );

        return http.build();
    }

    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration configuration = new CorsConfiguration();

        configuration.setAllowedOrigins(Arrays.asList(
            "https://myapp.com",
            "https://staging.myapp.com"
        ));

        configuration.setAllowedMethods(Arrays.asList(
            "GET", "POST", "PUT", "DELETE", "PATCH", "OPTIONS"
        ));

        configuration.setAllowedHeaders(Arrays.asList(
            "Authorization",
            "Content-Type",
            "X-Requested-With",
            "Accept",
            "Origin"
        ));

        configuration.setExposedHeaders(Arrays.asList(
            "X-Total-Count",
            "Authorization"
        ));

        configuration.setAllowCredentials(true);
        configuration.setMaxAge(3600L);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", configuration);

        return source;
    }
}

Using Pattern-Based Origin Matching in Spring Boot

If you need to allow all subdomains of a domain, Spring Boot supports pattern matching:

configuration.setAllowedOriginPatterns(Arrays.asList(
    "https://*.myapp.com",       // Any subdomain of myapp.com
    "http://localhost:[*]"        // Any localhost port (great for dev)
));

Note: Use setAllowedOriginPatterns instead of setAllowedOrigins when using patterns. You cannot mix wildcard * with allowCredentials(true) when using setAllowedOrigins — use allowedOriginPatterns for that combination.

Common Mistakes and How to Avoid Them

Mistake 1 — Thinking CORS is a Server-Side Security Feature

CORS is enforced by the browser. Curl, Postman, and server-to-server calls completely bypass it. If someone bypasses the browser (as any attacker would), CORS provides zero protection. CORS is about protecting the user's browser, not your server. Actual server security (authentication, authorization, rate limiting) must still be implemented independently.

Mistake 2 — Using `*` with Credentials

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

The browser will reject this combination. Always. You must specify an explicit origin when using credentials.

Mistake 3 — Forgetting to Handle OPTIONS Preflight

Your POST, PUT, DELETE requests will fire a preflight OPTIONS request first. If your server doesn't respond correctly to OPTIONS (some servers return 404 or 405 for OPTIONS by default), the real request never goes through. Always make sure OPTIONS is handled at the top of your middleware chain.

Mistake 4 — Proxy in Development, Forgetting for Production

During development, many developers use a proxy (like Vite's proxy config or Create React App's proxy field) to avoid CORS issues. This works because the proxy makes server-to-server calls — no browser CORS. Then they deploy to production, remove the proxy, and suddenly everything breaks because production doesn't have proper CORS headers on the server. Configure CORS properly on the server from day one.

Mistake 5 — Trailing Slashes in Origin

https://myapp.com and https://myapp.com/ are treated differently by some CORS implementations. Browsers send origins without trailing slashes. Make sure your allowed origins list doesn't have trailing slashes.

A Note on CORS and Local Development

During local development, your frontend likely runs on http://localhost:3000 while your backend runs on http://localhost:5000 or http://localhost:8080. These are different origins (different ports), so CORS applies even for localhost.

The cleanest solutions:

Option A — Add http://localhost:3000 to your allowed origins with an environment variable so it's only allowed in development.

Option B — Use a Vite or webpack proxy to have all API requests go through the same origin during development:

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

Option C — Run both frontend and backend under the same origin using nginx in a Docker Compose setup that mirrors production.

The Mental Model That Makes It All Click

Think of CORS like a doorman at an exclusive building. The Same-Origin Policy is the building's default rule: nobody from outside gets in. CORS is the list the doorman checks. If your name (origin) is on the list (the server's Access-Control-Allow-Origin header), you get in. If not, the doorman (browser) turns you away — even if you somehow already received the package (the server responded successfully). The doorman doesn't care what the server wants. The doorman enforces the list.

Your job as a backend developer is to put the right names on the list — specific, trusted origins — and make sure the doorman knows about credentials, allowed methods, and how long to remember the last check.

When done right, CORS is invisible. When done wrong, it's the most maddening error message in frontend development. But now you know the whole story — why it exists, what it protects, how it works, and exactly how to configure it in both Express.js and Spring Boot.

Configure it right once, and you'll never fight it again.

Built with care for developers who've spent too long googling the same error message at 2am.

Follow me on : Github Linkedin Threads Youtube Channel

SSL Certificates Explained: A Deep Dive into Encryption, Attacks, and How HTTPS Secures the Web 🔐

Jack Pritom Soren — Sat, 28 Feb 2026 06:56:32 +0000

When you open a website and see the 🔒 lock icon in your browser, you’re benefiting from SSL/TLS, one of the most important security technologies on the internet.

But why does SSL exist?
What problem did it solve?
Why do we need both symmetric and asymmetric encryption?
And how exactly does SSL protect us from hackers and Man-in-the-Middle attacks?

Let’s break everything down from the ground up.

1. The Original Problem: The Internet Was Not Secure 🌐

The internet was originally designed to share information, not to protect it.

Early protocols like HTTP sent data in plain text.
That means:

Passwords
Credit card numbers
Cookies
API tokens

…were readable by anyone who could intercept the network traffic.

Example:

If you sent this request:

POST /login
username=jack
password=123456

Anyone on the same network (Wi-Fi, ISP, router) could see it as-is.

This led to serious security issues:

Data theft
Account hijacking
Identity fraud

So the core problem was:

How can two parties communicate securely over an insecure network?

2. First Attempt: Symmetric Encryption 🔑

What Is Symmetric Encryption?

In symmetric encryption, the same secret key is used to:

Encrypt data
Decrypt data

Plain Text → (Secret Key) → Encrypted Data
Encrypted Data → (Same Secret Key) → Plain Text

Popular Symmetric Algorithms

AES (Advanced Encryption Standard)
DES (old, insecure now)
ChaCha20

Why Symmetric Encryption Is Fast 🚀

Simple math operations
Very efficient for large data
Used to encrypt actual website traffic

The BIG Problem ❌: Key Sharing

How do the client and server agree on the secret key?

If you send the key over the internet:

Client → "Hey server, here is the secret key"

An attacker can intercept it and now everything is compromised.

So symmetric encryption alone is not enough.

3. Second Attempt: Asymmetric Encryption 🔐

What Is Asymmetric Encryption?

Asymmetric encryption uses two keys:

Public Key → Shared with everyone
Private Key → Kept secret

Encrypted with Public Key → Decrypted with Private Key

How It Solves the Key Sharing Problem

Anyone can encrypt data using the public key
Only the server can decrypt it using its private key

This solves the secure key exchange problem.

Popular Asymmetric Algorithms

RSA
ECC (Elliptic Curve Cryptography)

But There’s a Catch ⚠️

Asymmetric encryption is:

Slow
Computationally expensive
Not suitable for encrypting large data

So now we have:

Symmetric → Fast, but key sharing problem
Asymmetric → Secure key sharing, but slow

4. The Real-World Threat: Man-in-the-Middle (MITM) Attack 🕵️‍♂️

Before SSL, attackers could:

Intercept traffic
Modify requests
Steal credentials

MITM Attack Example

Client wants to connect to example.com
Attacker sits between client and server
Attacker pretends to be the server
Client sends sensitive data
Attacker reads or alters it

Even asymmetric encryption alone is not enough if:

The attacker sends their own public key
The client doesn’t know who to trust

So the question becomes:

How do we verify the server’s identity?

5. Enter SSL/TLS: The Complete Solution 🛡️

SSL (Secure Sockets Layer) — now replaced by TLS (Transport Layer Security) — solves all these problems together.

SSL provides:

Encryption
Authentication
Integrity

6. What Is an SSL Certificate? 📜

An SSL certificate is a digitally signed document that contains:

Domain name (example.com)
Server’s public key
Certificate Authority (CA) signature
Expiry date

Trusted Certificate Authorities (CAs)

Let’s Encrypt
DigiCert
GlobalSign
Cloudflare

Browsers trust these CAs by default.

7. SSL Handshake: Step-by-Step (Very Important) 🔄

This is where everything comes together.

Step 1: Client Hello

The browser sends:

Supported TLS versions
Supported cipher suites
Random number

Step 2: Server Hello

The server responds with:

SSL certificate
Chosen cipher suite
Another random number

Step 3: Certificate Verification ✅

The browser:

Verifies CA signature
Checks domain name
Checks expiration

If this fails → connection is blocked

This step prevents MITM attacks.

Step 4: Key Exchange (Asymmetric Encryption)

The browser:

Generates a symmetric session key
Encrypts it using the server’s public key
Sends it to the server

Only the server can decrypt it using its private key.

Step 5: Secure Communication (Symmetric Encryption)

Now both sides have the same secret key.

From this point:

All data is encrypted using fast symmetric encryption
HTTPS traffic begins

8. Why SSL Uses Both Symmetric & Asymmetric Encryption 🤝

Encryption Type	Purpose
Asymmetric	Secure key exchange
Symmetric	Fast data encryption

SSL smartly combines security + performance.

9. What SSL Protects You From 🔒

Man-in-the-middle attacks
Packet sniffing
Credential theft
Data tampering
Session hijacking

10. What SSL Does NOT Protect You From ⚠️

Server-side bugs
XSS attacks
SQL injection
Stolen passwords from phishing

SSL secures data in transit, not bad code.

11. HTTPS Today: Why It’s Mandatory 🚨

Modern browsers:

Mark HTTP as “Not Secure”
Block insecure cookies
Enforce HTTPS for many APIs

For backend engineers, SSL is non-negotiable.

Final Thoughts 🧠

SSL/TLS is not “just a certificate”.

It is a carefully designed system that:

Solves key exchange
Prevents impersonation
Protects data on hostile networks

Understanding SSL deeply makes you a better backend engineer, not just someone who installs certificates.

Follow me on : Github Linkedin Threads Youtube Channel

The Developer’s Guide to Prompt Engineering for AI Coding Assistants

Jack Pritom Soren — Fri, 27 Feb 2026 16:25:24 +0000

AI coding assistants are no longer a novelty — they’re part of our daily workflow.

They autocomplete functions.
They suggest bug fixes.
They scaffold APIs.
They even generate MVPs.

But here’s the uncomfortable truth:

The quality of AI output depends almost entirely on the quality of your prompt.

A vague request produces generic code.
A precise, structured prompt produces thoughtful, accurate, production-ready solutions.

Prompt engineering isn’t magic.

It’s structured technical thinking made explicit.

In this guide, we’ll break down practical, repeatable prompt patterns for:

Debugging broken code
Refactoring and optimization
Implementing new features
Avoiding common prompting mistakes

Let’s dive in.

Foundations of Effective Code Prompting

Think of an AI coding assistant as a very literal junior developer.

It:

Doesn’t know your architecture.
Doesn’t know your constraints.
Doesn’t know your intent.
Only knows what you tell it.

That changes how you should communicate.

1. Provide Rich Context

Bad:

“Why isn’t my function working?”

Better:

“This JavaScript function should return the sum of an array like [1,2,3] → 6, but it returns NaN. Here’s the code and the exact error. What’s causing it?”

Include:

Language
Framework
Version (if relevant)
Error message
Expected behavior
Actual behavior
Code snippet

Specificity turns guesswork into reasoning.

2. Be Explicit About Your Goal

Don’t say:

“Refactor this.”

Say:

“Refactor this to eliminate duplication and improve performance. Fetch both APIs in parallel, but preserve separate error handling.”

AI cannot optimize for what you don’t define.

3. Break Complex Tasks Into Steps

Don’t generate an entire feature in one prompt.

Instead:

Generate component skeleton.
Add state management.
Integrate API.
Add error handling.
Optimize performance.

You’ll get cleaner output and better control.

4. Include Examples

Example-driven prompts dramatically improve quality.

Instead of:

“Write a price formatter.”

Write:

“Create formatPrice(amount) that converts 2.5 → '$2.50'.”

Examples eliminate ambiguity.

5. Use Role-Based Prompts

Ask AI to “act as”:

A senior React developer
A TypeScript strict-mode expert
A security auditor
A performance engineer

Example:

“Act as a senior Node.js engineer. Review this code for scalability issues.”

This shifts tone and depth significantly.

Prompt Patterns for Debugging

Debugging is one of the highest-ROI uses of AI.

But only if you structure the prompt properly.

❌ Poor Prompt

“Why doesn’t this work?”

AI Response:
Generic guesses. No real diagnosis.

✅ Strong Debug Prompt

Structure it like this:

Context

Language: JavaScript
Framework: Node.js
Function goal: Convert user array into map

Expected

{id: 1} → { "1": {id:1} }

Actual

TypeError: Cannot read property 'id' of undefined

Code

for (let i = 0; i <= users.length; i++) {

Question

What’s causing this bug and how do I fix it?

Now AI can reason about loop bounds and identify the off-by-one error.

The difference is night and day.

Advanced Debugging Prompts

You can also ask AI to:

Walk through code line-by-line
Simulate variable values
Generate edge-case test cases
Act as a code reviewer
Brainstorm possible root causes

Treat it like a collaborative debugging partner.

Prompt Patterns for Refactoring

Refactoring prompts must define what “better” means.

❌ Weak Prompt

“Make this cleaner.”

Too subjective.

✅ Strong Refactor Prompt

Refactor this function to:

Eliminate duplicate fetch logic

Fetch APIs in parallel

Preserve distinct error handling

Improve lookup performance

Provide refactored code and explain your changes.

Now AI has a target.

You’re not asking for vague improvement — you’re defining engineering objectives.

Always Ask for Explanations

When quality matters, add:

“Explain why this approach is better and mention trade-offs.”

This forces deeper reasoning and helps you validate correctness.

Prompting for New Features

Feature generation works best when done incrementally.

Step 1: Ask for a Plan

Outline a plan to implement product search filtering in a React app.

Review it.

Adjust it.

Then move to implementation.

Step 2: Implement in Chunks

Build UI
Add state
Add filtering logic
Add sorting
Add edge-case handling

Each prompt builds on the previous one.

This mirrors real development workflows.

Use Context From Your Codebase

Tell the AI:

“We use Redux.”
“We use App Router.”
“We use TypeScript strict mode.”
“No external libraries allowed.”

Without constraints, AI guesses.

With constraints, AI aligns.

Modern Real-World Example: React Infinite Loop

Weak:

“My useEffect is broken.”

Strong:

“This component re-renders infinitely. Error: Maximum update depth exceeded. Expected behavior: fetch only when userId changes. Here’s the dependency array. What’s wrong?”

Now AI can analyze dependency issues precisely.

Common Prompt Anti-Patterns

1. The Vague Prompt

Fix: Add context and expected outcome.

2. The Overloaded Prompt

Fix: Split into steps.

3. No Clear Question

Fix: Always end with a direct ask.

4. Undefined Success Criteria

Fix: Define what “better” means.

5. Repeating the Same Prompt

Fix: Refine it instead.

Prompt engineering is debugging your instructions.

A Reusable Prompt Template

Here’s a structure that works consistently:

Context:
- Language:
- Framework:
- Constraints:

Problem:
- Expected behavior:
- Actual behavior:
- Error (if any):

Code:
[paste minimal reproducible snippet]

Task:
- What exactly I want
- Constraints
- Ask for explanation if needed

This mirrors how senior engineers communicate technical issues.

The Bigger Picture

AI coding assistants are force multipliers — not replacements for thinking.

The developers who benefit most from AI are the ones who:

Think clearly
Define problems precisely
Understand architecture
Break problems into systems
Critically review output

Prompt engineering is not a hack.

It’s disciplined engineering communication.

And in the AI era, the ability to communicate precisely with machines is becoming as important as writing code itself.

Follow me on : Github Linkedin Threads Youtube Channel

Payment System Design at Scale

Jack Pritom Soren — Sat, 21 Feb 2026 06:52:40 +0000

What really happens when Maria taps “Confirm Ride”?

Maria has an important meeting in 15 minutes.

She doesn’t have cash.

She opens Uber. Requests a ride. Gets dropped off.

The payment? Invisible. Instant. Effortless.

But behind that single tap is one of the most complex distributed systems in modern software.

Today, we’re breaking it down.

Not just “how to charge a card.”

But how to build a secure, reliable, scalable payment system that can process millions of rides per day.

The Illusion of Simplicity

From the user’s perspective:

Trip ends → $20 charged → Done.

From the backend’s perspective:

Securely collect payment details
Avoid storing sensitive card data
Prevent fraud
Handle bank outages
Split money across multiple parties
Maintain financial correctness
Reconcile mismatches
Survive retries and timeouts
Support global scale

This is not a feature.

This is infrastructure.

1️⃣ The First Problem: You Can’t Store Card Data

When a user enters:

Card number
CVV
Expiry

Storing it directly means:

Heavy PCI DSS compliance
Massive breach risk
Legal exposure

So what do modern systems do?

Tokenization.

The mobile app integrates a payment provider SDK (Stripe, Adyen, etc.).

Instead of sending card details to your servers:

The SDK sends card data directly to the provider.
The provider returns a token.
You store only that token.

The token acts as a reusable, scoped permission to charge the card.

If someone steals it?

It’s useless outside your merchant account.

Security solved. (Mostly.)

2️⃣ Authorization vs Capture (Where Things Get Subtle)

When the ride ends, you don’t just “charge.”

You typically:

Step 1: Authorize

Check if the card has funds and lock the amount.

Step 2: Capture

Actually move the money.

Why split it?

Because:

The ride price may change.
You may need to adjust final fare.
You don’t want unpaid rides.

Large systems often authorize early (estimated fare) and capture later (final fare).

Small detail.

Massive architectural impact.

3️⃣ The Money Doesn’t Go Rider → Driver

This is critical.

The rider does NOT pay the driver directly.

Instead:

Rider → Uber Merchant Account → Split →
    → Driver
    → Uber Commission
    → Taxes
    → Fees

Why?

Because:

You need commission control.
You must handle taxes.
You need dispute handling.
You need fraud protection.

Direct peer-to-peer payments would break accounting.

4️⃣ The Hidden Hero: Internal Ledger System

Here’s what most engineers underestimate:

You cannot rely on your payment provider as your source of truth.

You must build your own ledger service.

A simplified double-entry example:

Account	Debit	Credit
Rider	$20
Driver		$15
Platform		$5

Every movement is recorded.

Why double-entry?

Because money cannot disappear.

If debits ≠ credits → something is broken.

At scale, this is the difference between:

“Works fine”
“Lost $3M silently”

5️⃣ Reliability: External Systems Will Fail

Your payment system depends on:

Banks
Card networks
Payment providers
Network calls

All of them fail.

Common nightmare scenario:

Authorization succeeds.
Capture request times out.
You retry.
Customer gets double-charged.

Solution?

Idempotency keys.

Each payment attempt includes a unique key (e.g., ride_id).

If retried, provider recognizes the key and avoids duplicate processing.

Without idempotency?

You will double-charge users.

And you will lose trust.

6️⃣ Smart Retries (Not Blind Retries)

Not all failures are equal.

Error	Retry?
Network timeout	Yes
Rate limit	Yes
Insufficient funds	No
Fraud blocked	No

Blind retries create chaos.

Intelligent retries create resilience.

7️⃣ Fraud Layer (Before Money Moves)

Before charging:

Velocity checks
Device fingerprinting
Location mismatch
Behavioral anomaly detection

Some cases trigger:

3D Secure
OTP verification
Manual review

Payment systems are also fraud systems.

Ignore this, and chargebacks will destroy margins.

8️⃣ Refunds Aren’t Simple

Refunding isn’t “reverse transaction.”

It requires:

Updating internal ledger
Issuing refund request
Adjusting driver balance
Handling payout already completed

Sometimes, the platform absorbs temporary loss.

Complexity compounds over time.

9️⃣ Driver Payouts: A Different System

Charging cards is one system.

Paying drivers is another.

Most platforms:

Aggregate earnings daily
Settle weekly
Offer instant payout (for a fee)

This uses bank rails like ACH/SEPA.

Completely different from card networks.

Two financial systems under one product.

🔟 Reconciliation (Where Adults Work)

Every night:

Pull reports from payment provider
Compare with internal ledger
Identify mismatches

If mismatch:

Flag for review
Trigger investigation

Without reconciliation?

Small inconsistencies compound into millions.

1️⃣1️⃣ Scaling to Millions of Rides

At high scale:

1M+ rides/day
1000+ transactions per second at peak

You need:

Stateless payment services
Event-driven architecture
Message queues (Kafka/PubSub)
Horizontal scaling

Instead of:

Ride → Immediate Charge

You use:

RideCompleted Event → Payment Queue → Worker → Provider

Decoupling prevents cascading failures.

1️⃣2️⃣ Multi-Provider Strategy

Never depend on one payment provider.

You implement:

Primary provider
Secondary fallback

With an abstraction layer:

charge(amount, token)

Underneath, routing logic decides where to send it.

Because outages are not “if.”

They are “when.”

What Looks Simple Is Actually Distributed Finance

A ride payment system is not:

Just API calls
Just token storage
Just Stripe integration

It is:

Distributed systems
Financial accounting
Legal compliance
Fault tolerance
Fraud modeling
Bank integrations
Event-driven infrastructure

That’s why payment infrastructure is one of the hardest backend domains in the world.

Final Thought

When Maria stepped out of that taxi in Prague, she didn’t think about:

Idempotency keys
Double-entry accounting
Multi-provider failover
Fraud scoring
Reconciliation pipelines

She just walked into her meeting.

That’s the goal.

Great engineering makes complexity invisible.

If you’re building systems:

Don’t just design features.

Design for:

Failure
Scale
Auditability
Correctness

Because money systems don’t forgive mistakes.

Follow me on : Github Linkedin Threads Youtube Channel

How Transformers Work Inside an LLM (Step by Step)

Jack Pritom Soren — Mon, 09 Feb 2026 18:36:37 +0000

1️⃣ Big Picture: Where Do Transformers Fit in an LLM?

The full LLM pipeline looks like this:

Input Text
   ↓
Tokenizer
   ↓
Embedding + Positional Encoding
   ↓
🔥 Transformer Blocks (Core Brain)
   ↓
Softmax (Probability)
   ↓
Next Token

👉 The Transformer is the brain of the LLM
👉 All context understanding and relationship modeling happens here

2️⃣ What Happens First When Input Enters the Model?

Example Input

"Today the server is down"

🔹 Step 1: Tokenization

["Today", "the", "server", "is", "down"]

LLMs don’t process words—they process tokens.

🔹 Step 2: Embedding

Each token is converted into a numerical vector:

"server" → [0.32, -1.10, 0.87, ...]

This is a mathematical representation of meaning.

🔹 Step 3: Positional Encoding (Very Important)

Transformers do not understand word order by default.

So position information is added to embeddings.

Example:

Today the server is down
The server is down today

Without positional encoding, these would look identical ❌

3️⃣ What’s Inside a Transformer Block?

A single Transformer block has two main components:

[ Multi-Head Self-Attention ]
            ↓
[ Feed Forward Neural Network ]

LLMs contain many such blocks:

Small models → 12–24 blocks
Large models → 48–96+ blocks

Each block refines the representation further.

4️⃣ Self-Attention: The Core Power of Transformers 🧠

Self-attention means:

To understand one token, the model determines which other tokens are relevant.

Example

Rahim fixed the server because he understands debugging.

The token “he” attends to “Rahim”.

This is how Transformers learn context and relationships.

5️⃣ How Attention Works Internally (Q, K, V)

Each token is transformed into three vectors:

Query (Q): What am I looking for?
Key (K): What information do I contain?
Value (V): What content should be passed forward?

The core calculation:

Attention Score = Q · K

Tokens with higher scores contribute more strongly.

Final output:

Output = weighted sum of V

6️⃣ Why Multi-Head Attention?

One attention mechanism isn’t enough.

Different heads focus on different aspects:

Subject relationships
Time / tense
Cause–effect
Intent

Multi-head attention = multiple perspectives

This makes Transformers extremely powerful.

7️⃣ Masked Self-Attention (Critical for GPT Models)

GPT-style models cannot see future tokens.

Example:

Today the server ___

The token “Today” cannot attend to future tokens.

👉 This is enforced using masked self-attention
👉 The model only looks at past tokens

That’s why LLMs generate text step by step.

8️⃣ Feed Forward Network: Pattern Builder

Attention finds relationships.
The feed forward network:

Learns abstractions
Builds patterns
Extracts deeper meaning

Structure:

Linear → Activation → Linear

But at massive scale.

9️⃣ Residual Connections & Layer Normalization

Deep Transformers can become unstable.

To fix this:

Residual connections preserve information
Layer normalization stabilizes training

Without these, modern LLMs wouldn’t work.

🔟 What Happens After Multiple Transformer Blocks?

After passing through many blocks, tokens become:

More context-aware
More meaningful
More informed

At the final layer:

"server" understands the full sentence context

1️⃣1️⃣ How Is the Next Token Chosen?

Final output flows through:

Linear Layer
   ↓
Softmax

Softmax produces probabilities:

down → 55%
slow → 30%
offline → 10%

The selected token becomes the next output, and the process repeats 🔁

1️⃣2️⃣ One-Line Summary

Transformers process all tokens together,
use attention to understand relationships,
and leverage that context to predict the next token.

1️⃣3️⃣ Why Were Transformers Necessary for LLMs?

Because Transformers provide:

✅ Long-range context understanding
✅ Parallel computation
✅ Strong attention-based modeling
✅ Massive scalability

No previous architecture offered all of these together.

Follow me on : Github Linkedin Threads Youtube Channel

What Existed Before Transformers and Why Responses Are Generated Step by Step

Jack Pritom Soren — Mon, 09 Feb 2026 17:35:57 +0000

Large Language Models (LLMs) like ChatGPT feel almost magical—but under the hood, they are built on clear mathematical and architectural principles.
In this article, we’ll break down how LLMs actually work, why models like ChatGPT weren’t possible before Transformers, and why responses are generated token by token instead of all at once.

The explanation stays simple—but goes deep.

1️⃣ What Is an LLM?

LLM = Large Language Model

An LLM is not a “thinking human” and does not store knowledge like a database.
At its core, it is a large probability engine.

Its single job is:

Given previous words, predict the most likely next word.

Example

"I am eating rice today ..."

Internally, the model calculates probabilities:

eating → 80%
going → 10%
stopped → 5%
sky → 0.0001%

➡️ The highest probability token is “eating”

By repeating this process again and again, the model generates full sentences.

2️⃣ Why Does ChatGPT Respond Gradually Instead of All at Once?

Because an LLM does not know the full answer upfront.

It works token by token.

Example Output

"I can help you"

Internally, generation looks like this:

"I"
"I" → "can"
"I can" → "help"
"I can help" → "you"

Each step uses:

previous tokens + probability calculation → next token

That’s why:

You see text appearing gradually
But internally, the process happens extremely fast (milliseconds)

3️⃣ What Is a Token? (Very Important)

LLMs do not understand words—they understand tokens.

A token can be:

A full word
Part of a word
Punctuation or symbols

Example

"Bangladesh" → ["Bang", "la", "desh"]

This is why concepts like:

Token limit
Context window

exist in LLM systems.

4️⃣ Why Didn’t ChatGPT-Like Models Exist Before Transformers?

This is the most critical question.

What existed before Transformers?

RNN (Recurrent Neural Networks)
LSTM / GRU

Limitations of These Models

❌ Could not remember long contexts
❌ Forgot earlier parts of text
❌ Could not process tokens in parallel (very slow)
❌ Weak understanding of relationships across sentences

Example

I went to school.
I met my friend there.
He told me that ...

Older models often failed to understand who “he” refers to.

5️⃣ What Is a Transformer?

In 2017, Google published a paper titled:

“Attention Is All You Need”

This paper introduced the Transformer architecture, which completely changed NLP and AI.

6️⃣ The Heart of Transformers: Attention 🧠

Attention means:

Determining which words in a sentence are important for understanding another word.

Example

Rahim fixed the server because he understands debugging.

The word “he” attends to “Rahim”.

The model learns this relationship automatically.

Self-Attention

Words inside the same sentence attend to one another to understand context.

7️⃣ How Can Transformers See the Whole Sentence at Once?

Transformers:

Take all tokens at the same time
Compute attention relationships
Use parallel computation (GPU-friendly)

This was impossible with RNN-based architectures.

8️⃣ Transformer Architecture (High-Level)

A Transformer consists of several key components:

🔹 Embedding

Converts tokens into numerical vectors.

🔹 Positional Encoding

Transformers don’t understand word order by default.
Position information is added explicitly.

Without this:

Server is down today
Today the server is down

would look identical to the model.

🔹 Multi-Head Attention

The sentence is analyzed from multiple perspectives:

Subject
Time
Cause–effect
Intent

Each “head” focuses on a different relationship.

🔹 Feed Forward Network

Deep neural layers that learn patterns and abstractions.

Modern models may have 12–96+ Transformer layers.

9️⃣ How Does ChatGPT Learn?

🔸 Step 1: Pretraining

The model trains on massive text data:

Books
Articles
Code
Discussions

The core task:

Predict the next word in this sequence.

Repeated trillions of times.

🔸 Step 2: Fine-Tuning

Human reviewers rank answers as good or bad.

🔸 Step 3: RLHF (Reinforcement Learning from Human Feedback)

Humans provide feedback such as:

Helpful
Incorrect
Unsafe

The model is adjusted accordingly.

🔟 Does ChatGPT Actually “Understand”?

❌ Not like a human
✅ But it understands patterns and relationships extremely well

That’s why:

It can sound confident yet be wrong
It can also provide surprisingly deep explanations

1️⃣1️⃣ LLM from a Backend Perspective

A simplified pipeline:

Input Text
   ↓
Tokenizer
   ↓
Embedding
   ↓
Transformer Layers
   ↓
Softmax (Probability)
   ↓
Next Token
   ↓
Repeat

1️⃣2️⃣ Why Are LLMs So Powerful Today?

Because all of these exist together now:

✅ Transformer architecture
✅ Massive datasets
✅ Large-scale GPU / TPU computing
✅ Improved training techniques

Previously, this combination was not possible.

1️⃣3️⃣ One Line to Remember

ChatGPT is not a knowledge database.
It is a highly advanced next-token prediction engine
powered by Transformers and attention-based context understanding.

Follow me on : Github Linkedin Threads Youtube Channel

Forem: Jack Pritom Soren

RxJS in Angular — Chapter 6 | Error Handling — Building Apps That Don't Break

"Error Handling — Building Apps That Don't Break"

👋 Welcome to Chapter 6!

💥 What Happens When an Observable Errors?

🥅 catchError — Catch it Before it Reaches subscribe

🏗️ Real-World Pattern — Service with Error Handling

user.service.ts

users.component.ts

🔄 retry() — Automatically Try Again

Timeline:

⏱️ retryWhen / retry with Delay — Smart Retrying

Exponential Backoff (Advanced) — Wait longer each time

🔁 finalize() — Always Runs, Error or Not

🌐 Global HTTP Error Handling with Interceptors

auth.interceptor.ts

Register it in app.module.ts

🎨 Real-World Complete Example — Product Page with Full Error Handling

🧠 Chapter 6 Summary — What You Learned

📚 Coming Up in Chapter 7...

RxJS in Angular — Chapter 5 | Subject, BehaviorSubject & ReplaySubject — The Two-Way Radio

"Subject, BehaviorSubject & ReplaySubject — The Two-Way Radio"

👋 Welcome to Chapter 5!

📻 The Two-Way Radio Analogy

🔴 What is a Subject?

⚠️ Subject's Big Limitation

🎯 BehaviorSubject — Remembers the Last Value

Rules of BehaviorSubject:

🛒 Real-World Example — Shopping Cart Service

cart.service.ts

cart-icon.component.ts (in the header)

cart-total.component.ts (in the checkout area)

product-card.component.ts (on product pages)

🔄 ReplaySubject — Remembers Multiple Past Values

Real Use Case — Message History / Notifications

📡 AsyncSubject — Only Emits the Last Value on Complete

🔐 The Security Pattern — Hide Your Subject!

🏗️ Real-World Example — Auth Service with BehaviorSubject

auth.service.ts

nav.component.ts

🧠 Choosing the Right Subject

🧠 Chapter 5 Summary — What You Learned

📚 Coming Up in Chapter 6...

RxJS in Angular — Chapter 4 | switchMap, mergeMap, concatMap — Observables Inside Observables

👋 Welcome to Chapter 4!

🤔 The Problem — Observable Inside Observable

🔀 The Three Brothers — An Analogy

🔀 switchMap — Cancel the Old, Start the New

Perfect for: Search boxes, autocomplete, navigation triggers

Full Real-World Search Component

⚡ mergeMap (aka flatMap) — Run Everything Simultaneously

Perfect for: Parallel uploads, multiple simultaneous requests

Real Example — Load User Profiles in Parallel

🚶 concatMap — One at a Time, In Order

Perfect for: Sequential operations, guaranteed ordering

Real Example — Onboarding Steps in Order

🆚 Side-by-Side Comparison

🛍️ Complete Real-World Example — Product Detail Page with Related Items

product-detail.component.ts

🚦 Route-Based Loading with switchMap

🧠 Quick Decision Guide

🧠 Chapter 4 Summary — What You Learned

📚 Coming Up in Chapter 5...

RxJS in Angular — Chapter 3 | pipe()` and Operators — The Superpowers of RxJS

"pipe() and Operators — The Superpowers of RxJS"

👋 Welcome to Chapter 3!

🍋 Think of it Like Making Lemonade

🔧 What is pipe()?

🗺️ Operator #1: map() — Transform Your Data

Simple Example:

Real Angular Example — Transforming API Response

🔍 Operator #2: filter() — Only Let Certain Values Through

Real Angular Example — Filter Active Products

👀 Operator #3: tap() — Peek Without Changing Anything

Real Angular Example — Loading State with tap

🔢 Chaining Multiple Operators

🏪 Full Real-World Example — Product Catalog Page

product.service.ts

product-catalog.component.ts

🧩 More Useful Operators — Quick Overview

🥅 `catchError` — Catch it Before it Reaches subscribe

🔄 `retry()` — Automatically Try Again

⏱️ `retryWhen` / `retry` with Delay — Smart Retrying

🔁 `finalize()` — Always Runs, Error or Not

🔀 `switchMap` — Cancel the Old, Start the New

⚡ `mergeMap` (aka `flatMap`) — Run Everything Simultaneously

🚶 `concatMap` — One at a Time, In Order

"`pipe()` and Operators — The Superpowers of RxJS"

🔧 What is `pipe()`?

🗺️ Operator #1: `map()` — Transform Your Data

🔍 Operator #2: `filter()` — Only Let Certain Values Through

👀 Operator #3: `tap()` — Peek Without Changing Anything

`take(n)` — Only Take First N Values

`distinctUntilChanged()` — Skip Duplicate Values

`debounceTime()` — Wait Before Processing

`catchError()` — Handle Errors Gracefully

✅ Fix #3 — The Angular Way: `async` Pipe (Recommended!)

✅ Fix #4 — `takeUntil` Pattern (Advanced but Powerful)

`Access-Control-Allow-Origin`

`Access-Control-Allow-Methods`

`Access-Control-Allow-Headers`

`Access-Control-Allow-Credentials`

`Access-Control-Expose-Headers`

`Access-Control-Max-Age`