DEV Community: Jack Pritom Soren

RxJS in Angular — Chapter 8 | RxJS + Angular Reactive Forms — Live Validation ও Dynamic Forms

Jack Pritom Soren — Sat, 04 Jul 2026 05:42:49 +0000

"RxJS + Angular Reactive Forms — Live Validation & Dynamic Forms"

👋 Welcome to Chapter 8!

Forms are EVERYWHERE in web apps — login, registration, checkout, search, settings.

Angular's Reactive Forms are powered by RxJS under the hood. Every FormControl has streams you can subscribe to — valueChanges, statusChanges. This unlocks incredibly powerful form behavior that would be painfully difficult to build any other way.

Today we build real, production-quality forms with RxJS superpowers!

🎛️ The Reactive Forms Quick Setup

First, let's make sure we have the right setup:

app.module.ts

import { ReactiveFormsModule } from '@angular/forms';

@NgModule({
  imports: [ReactiveFormsModule]
})
export class AppModule {}

💡 The Key Streams on Every FormControl

Every FormControl, FormGroup, and FormArray has two key Observable streams:

valueChanges — emits every time the value changes
statusChanges — emits every time the validation status changes ('VALID', 'INVALID', 'PENDING', 'DISABLED')

const emailControl = new FormControl('');

// Watch the value
emailControl.valueChanges.subscribe(value => {
  console.log('Email is now:', value);
});

// Watch the validation status
emailControl.statusChanges.subscribe(status => {
  console.log('Status:', status); // 'VALID', 'INVALID', 'PENDING', 'DISABLED'
});

🔍 Real Example 1 — Live Username Availability Check

This is extremely common: as the user types a username, check if it's available.

// register.component.ts
import { Component, OnInit, OnDestroy } from '@angular/core';
import { FormBuilder, FormGroup, Validators, AbstractControl } from '@angular/forms';
import { Subject } from 'rxjs';
import { debounceTime, distinctUntilChanged, switchMap, takeUntil } from 'rxjs/operators';

@Component({
  selector: 'app-register',
  template: `
    <form [formGroup]="registerForm" (ngSubmit)="onSubmit()">

      <div class="field">
        <label>Username</label>
        <input formControlName="username" placeholder="Choose a username" />

        <!-- Checking availability -->
        <span *ngIf="isCheckingUsername" class="checking">
          Checking availability... ⏳
        </span>

        <!-- Available -->
        <span *ngIf="usernameAvailable === true" class="available">
          ✅ Username is available!
        </span>

        <!-- Taken -->
        <span *ngIf="usernameAvailable === false" class="taken">
          ❌ Username is already taken
        </span>

        <!-- Validation errors -->
        <span *ngIf="registerForm.get('username')?.errors?.['required'] &&
                     registerForm.get('username')?.touched">
          Username is required
        </span>
        <span *ngIf="registerForm.get('username')?.errors?.['minlength']">
          At least 3 characters required
        </span>
      </div>

      <div class="field">
        <label>Email</label>
        <input formControlName="email" type="email" placeholder="Enter email" />
        <span *ngIf="registerForm.get('email')?.errors?.['email'] &&
                     registerForm.get('email')?.touched">
          Invalid email address
        </span>
      </div>

      <div class="field">
        <label>Password</label>
        <input formControlName="password" type="password" placeholder="Password" />
        <div class="password-strength" [class]="passwordStrength">
          {{ passwordStrengthLabel }}
        </div>
      </div>

      <div class="field">
        <label>Confirm Password</label>
        <input formControlName="confirmPassword" type="password" />
        <span *ngIf="registerForm.errors?.['passwordMismatch'] &&
                     registerForm.get('confirmPassword')?.touched">
          Passwords do not match
        </span>
      </div>

      <button type="submit" [disabled]="registerForm.invalid || isCheckingUsername">
        Create Account
      </button>

    </form>
  `
})
export class RegisterComponent implements OnInit, OnDestroy {

  registerForm!: FormGroup;
  isCheckingUsername = false;
  usernameAvailable: boolean | null = null;
  passwordStrength = 'weak';
  passwordStrengthLabel = '';

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

  constructor(
    private fb: FormBuilder,
    private authService: AuthService
  ) {}

  ngOnInit(): void {
    this.registerForm = this.fb.group({
      username: ['', [Validators.required, Validators.minLength(3)]],
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required, Validators.minLength(8)]],
      confirmPassword: ['', Validators.required]
    }, {
      validators: this.passwordMatchValidator
    });

    // --- RxJS Magic: Username availability check ---
    this.registerForm.get('username')!.valueChanges
      .pipe(
        debounceTime(500),                   // Wait 500ms after typing
        distinctUntilChanged(),              // Don't check if same value
        takeUntil(this.destroy$)
      )
      .subscribe(username => {
        if (username && username.length >= 3) {
          this.isCheckingUsername = true;
          this.usernameAvailable = null;

          this.authService.checkUsername(username)
            .pipe(takeUntil(this.destroy$))
            .subscribe({
              next: (isAvailable) => {
                this.usernameAvailable = isAvailable;
                this.isCheckingUsername = false;
              },
              error: () => {
                this.isCheckingUsername = false;
              }
            });
        } else {
          this.usernameAvailable = null;
        }
      });

    // --- RxJS Magic: Password strength meter ---
    this.registerForm.get('password')!.valueChanges
      .pipe(takeUntil(this.destroy$))
      .subscribe(password => {
        this.updatePasswordStrength(password || '');
      });
  }

  private updatePasswordStrength(password: string): void {
    let score = 0;
    if (password.length >= 8) score++;
    if (/[A-Z]/.test(password)) score++;
    if (/[0-9]/.test(password)) score++;
    if (/[^A-Za-z0-9]/.test(password)) score++;

    if (score <= 1) {
      this.passwordStrength = 'weak';
      this.passwordStrengthLabel = '🔴 Weak';
    } else if (score === 2) {
      this.passwordStrength = 'fair';
      this.passwordStrengthLabel = '🟡 Fair';
    } else if (score === 3) {
      this.passwordStrength = 'good';
      this.passwordStrengthLabel = '🟢 Good';
    } else {
      this.passwordStrength = 'strong';
      this.passwordStrengthLabel = '💪 Strong';
    }
  }

  private passwordMatchValidator(group: AbstractControl) {
    const password = group.get('password')?.value;
    const confirm = group.get('confirmPassword')?.value;
    return password === confirm ? null : { passwordMismatch: true };
  }

  onSubmit(): void {
    if (this.registerForm.valid && this.usernameAvailable) {
      console.log('Register:', this.registerForm.value);
    }
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

🏙️ Real Example 2 — Dependent Dropdowns (Country → City)

When selecting a country should dynamically load cities for that country:

@Component({
  template: `
    <form [formGroup]="addressForm">

      <select formControlName="country">
        <option value="">Select Country</option>
        <option *ngFor="let c of countries" [value]="c.code">
          {{ c.name }}
        </option>
      </select>

      <select formControlName="city">
        <option value="">
          {{ isLoadingCities ? 'Loading cities...' : 'Select City' }}
        </option>
        <option *ngFor="let city of cities" [value]="city.id">
          {{ city.name }}
        </option>
      </select>

    </form>
  `
})
export class AddressFormComponent implements OnInit, OnDestroy {

  addressForm = this.fb.group({
    country: [''],
    city: [{ value: '', disabled: true }]
  });

  countries = [
    { code: 'BD', name: 'Bangladesh' },
    { code: 'IN', name: 'India' },
    { code: 'US', name: 'USA' }
  ];

  cities: any[] = [];
  isLoadingCities = false;

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

  constructor(
    private fb: FormBuilder,
    private locationService: LocationService
  ) {}

  ngOnInit(): void {

    // When country changes — load its cities
    this.addressForm.get('country')!.valueChanges
      .pipe(
        takeUntil(this.destroy$),
        tap(() => {
          // Reset city when country changes
          this.cities = [];
          this.addressForm.get('city')!.disable();
          this.addressForm.get('city')!.setValue('');
          this.isLoadingCities = true;
        }),
        switchMap(countryCode => {
          if (!countryCode) return of([]);
          return this.locationService.getCitiesByCountry(countryCode)
            .pipe(catchError(() => of([])));
        })
      )
      .subscribe(cities => {
        this.cities = cities;
        this.isLoadingCities = false;
        if (cities.length > 0) {
          this.addressForm.get('city')!.enable();
        }
      });
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

When the country changes, the city dropdown automatically:

Resets to empty
Shows "Loading cities..."
Disables itself
Loads new cities from API
Re-enables with new options

All powered by valueChanges + switchMap!

💰 Real Example 3 — Live Price Calculator

A checkout form where the price updates as you change quantity and select options:

@Component({
  template: `
    <form [formGroup]="orderForm">
      <label>Quantity</label>
      <input type="number" formControlName="quantity" min="1">

      <label>Size</label>
      <select formControlName="size">
        <option value="small">Small</option>
        <option value="medium">Medium (+৳200)</option>
        <option value="large">Large (+৳400)</option>
      </select>

      <label>
        <input type="checkbox" formControlName="giftWrap">
        Gift Wrap (+৳50)
      </label>

      <div class="price-summary">
        <p>Base price: ৳{{ basePrice }}</p>
        <p>Total: <strong>৳{{ liveTotal$ | async }}</strong></p>
      </div>
    </form>
  `
})
export class OrderFormComponent implements OnInit {

  basePrice = 500;

  orderForm = this.fb.group({
    quantity: [1],
    size: ['small'],
    giftWrap: [false]
  });

  liveTotal$!: Observable<number>;

  constructor(private fb: FormBuilder) {}

  ngOnInit(): void {
    const sizeAddon: Record<string, number> = {
      small: 0,
      medium: 200,
      large: 400
    };

    // Calculate total every time ANY field changes
    this.liveTotal$ = this.orderForm.valueChanges.pipe(
      startWith(this.orderForm.value),
      map(values => {
        const qty = values.quantity || 1;
        const sizeExtra = sizeAddon[values.size] || 0;
        const giftExtra = values.giftWrap ? 50 : 0;
        return (this.basePrice + sizeExtra + giftExtra) * qty;
      })
    );
  }
}

The total updates instantly as the user changes any field — no button, no event handlers, just pure reactive magic!

🔧 Using `statusChanges` for Async Validators

ngOnInit(): void {
  // React to form validity changes
  this.registerForm.statusChanges
    .pipe(
      distinctUntilChanged(),
      takeUntil(this.destroy$)
    )
    .subscribe(status => {
      // 'VALID', 'INVALID', 'PENDING', 'DISABLED'
      if (status === 'VALID') {
        this.canSubmit = true;
        this.showSuccessHint = true;
      } else {
        this.canSubmit = false;
        this.showSuccessHint = false;
      }
    });
}

🧠 Chapter 8 Summary — What You Learned

FormControl.valueChanges is an Observable — you can use all RxJS operators on it
FormControl.statusChanges tells you when validity changes
Use debounceTime + switchMap for async validation (username check, email uniqueness)
Use valueChanges + switchMap for dependent dropdowns (country → city)
Use valueChanges + map + startWith for live price calculators and previews
Always clean up form subscriptions with takeUntil or async pipe

📚 Coming Up in Chapter 9...

Chapter 9 covers debounceTime, throttleTime, distinctUntilChanged — the timing operators.

These are essential for search boxes, scroll events, resize events, and any situation where you need to control HOW OFTEN your code runs.

See you in Chapter 9! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 8 of 10
Follow me on : Github Linkedin Threads Youtube Channel

What Actually Happens When You Type "What is Python?" Into ChatGPT

Jack Pritom Soren — Thu, 25 Jun 2026 13:36:51 +0000

You type a question. A few seconds later, an answer streams back — fluent, confident,
occasionally wrong. Most developers use this every single day without ever asking what's
actually happening between the keystroke and the response. And honestly, you don't need
to know. Until the day you do — the day your manager says "let's add an AI feature to the
product" and suddenly you're the one who has to build it, not just use it.

That's the moment most engineers hit a wall. Using ChatGPT is trivial. Building on top of
an LLM is a different beast entirely — you're suddenly dealing with API contracts, token
limits, inconsistent outputs, five different providers with five different SDKs, and a
model that occasionally decides your perfectly valid JSON request deserves a poem instead.

This article is the article I wish someone had handed me before I started. We're going to
go top to bottom: what an LLM actually is, what happens behind the scenes when you ask one
a question, why every provider's API feels like a slightly different flavor of the same
headache, and how a framework called LangChain showed up to make that headache
manageable. By the end, you'll understand not just the theory but the actual building
blocks — models, prompts, prompt templates, and structured output — that you'll use to
ship a real AI application.

No math. No model training. This is the practical, application-builder's view of
generative AI — the view from where you, the engineer integrating these models into
products, actually stand.

What We'll Cover

The Three Layers of the Generative AI World
What an LLM Actually Is
What Happens When You Type "What is Python?"
The Provider Problem — Why Every API Feels Different
Enter LangChain: What It Actually Solves
LangChain's Core Components
Prompts, Prompt Templates, and Structured Output
Common Pitfalls When You're Starting Out

Chapter 1: The Three Layers of the Generative AI World

Before touching any code, it helps to mentally split the generative AI landscape into
three layers. Almost every confusion beginners have comes from mixing these up.

Layer 1 — Research. This is where new model architectures get invented. Think of the
teams that publish papers on attention mechanisms, new training techniques, or ways to
make models reason better. This is heavy math, heavy compute, and frankly — most
application developers will never touch this layer, and that's completely fine.

Layer 2 — Foundation Models (the "bedrock"). This is where research turns into
actual trained models — GPT-4, Claude, Gemini, Llama, and so on. These are massive neural
networks trained on enormous amounts of text, trained once (at huge cost), and then
exposed to the world either as downloadable weights or, more commonly, as a hosted
service. You don't train these. You consume them.

Layer 3 — Providers. This is the business layer — companies that take a foundation
model and wrap it in an API you can actually call. OpenAI serves GPT models through their
API. Anthropic serves Claude. Google serves Gemini. Same underlying idea — "send text in,
get text out" — but every provider wraps it differently.

Layer 4 — You. This is where application engineers live. You don't do research. You
don't train models. You take a provider's API, combine it with your product's logic, your
data, your users' inputs, and you build something useful on top — a chatbot, a document
summarizer, an autonomous agent, whatever your product needs.

💡 Pro tip: If you ever feel like you "need to learn machine learning" to build AI
products, you usually don't. You need to learn Layer 4 well — APIs, prompting,
orchestration, and your product domain. ML research skills matter for Layers 1 and 2,
which is a completely different career path.

Here's the mental model as a quick diagram:

[ Research ]  →  [ Foundation Models ]  →  [ Providers ]  →  [ You: the App Builder ]
  (papers,         (GPT-4, Claude,           (OpenAI API,      (your product, your
   training         Gemini — trained          Anthropic API,    business logic, your
   techniques)       once, expensive)         Google API)       users)

Everything in this article lives at Layer 4. That's the layer where LangChain operates,
and it's the layer where most AI Engineering jobs actually sit.

Chapter 2: What an LLM Actually Is

Strip away the hype and an LLM (Large Language Model) is, at its core, a very
sophisticated next-word predictor. That's it. That's the whole trick.

Here's the analogy that actually makes this click: think about your phone's keyboard
autocomplete. You type "I'm running" and it suggests "late." That's a tiny, dumb version
of what an LLM does. Now imagine that same autocomplete, except instead of being trained
on a few thousand text messages, it was trained on a meaningful chunk of the publicly
available internet — books, code, articles, forums, documentation. And instead of
predicting one word ahead with a simple lookup table, it predicts the next word (technically,
the next token — a word piece) using a neural network with billions of parameters that
has learned deep statistical patterns about how language, logic, and even code tend to
flow.

That's it. An LLM doesn't "know" facts the way a database does. It doesn't "look things
up." It generates the statistically most plausible continuation of the text you gave it,
one token at a time, based on patterns absorbed during training.

This explains so much of LLM behavior that confuses beginners:

Why LLMs hallucinate: They're not retrieving facts, they're generating plausible text. If the plausible-sounding continuation happens to be false, the model has no internal alarm bell — it has no concept of "true" vs "false," only "likely" vs "unlikely" given its training.
Why phrasing your prompt differently changes the answer: You're changing the starting point of the prediction, which changes what's statistically "next."
Why longer context helps: More context = more signal for the model to condition its next-token predictions on.

⚠️ Heads up: Treating an LLM as a search engine or a database is the single most
common beginner mistake. It's a text-completion engine with extraordinary pattern
recognition — powerful, but fundamentally different from a system that retrieves
ground-truth facts. This is exactly why techniques like RAG (Retrieval-Augmented
Generation) exist — to bolt real, retrievable facts onto a model that otherwise just
predicts plausible text.

Chapter 3: What Happens When You Type "What is Python?"

Let's make this concrete. You open ChatGPT, type "What is Python?", hit enter. Here's the
actual pipeline, simplified but accurate:

Step 1 — Tokenization. Your text isn't fed to the model as English words. It's broken
into tokens — sub-word chunks. "What is Python?" might become something like
["What", " is", " Python", "?"], each mapped to a numeric ID the model actually
understands. Models don't read letters; they read numbers.

Step 2 — Embedding. Each token ID gets converted into a vector — a long list of
numbers (think hundreds or thousands of dimensions) that represents that token's meaning
in a mathematical space. Tokens with similar meanings end up with mathematically similar
vectors. This is how the model captures meaning, not just spelling.

Step 3 — The Forward Pass (the actual "thinking"). These vectors flow through the
model's neural network layers — for modern LLMs, this is a transformer architecture,
which uses a mechanism called attention to weigh how much every word in your input
should influence every other word. This is the expensive, GPU-hungry computation step.

Step 4 — Next-Token Prediction. The model outputs a probability distribution over its
entire vocabulary — essentially "given everything so far, here's how likely each possible
next token is." Maybe "Python" has a 40% chance of being followed by " is", a 25%
chance of " was", and so on across thousands of candidate tokens.

Step 5 — Sampling. The system picks one token from that distribution (not always the
single most likely one — there's controlled randomness, governed by a setting called
temperature, which is why asking the same question twice can give slightly different
answers).

Step 6 — Repeat. That chosen token gets appended to the input, and the entire process
runs again to predict the next token. This repeats — token by token — until the model
produces a stop signal or hits a length limit.

That's why responses stream in word by word — that's not a UI trick, that's literally
how the generation works under the hood. Every word you see appear is a fresh pass through
billions of parameters.

# A wildly simplified mental model of what's happening — NOT real model code,
# just illustrating the loop structure of autoregressive generation.

prompt_tokens = tokenize("What is Python?")  # Step 1: text -> tokens
generated = prompt_tokens

while not is_stop_token(generated[-1]) and len(generated) < max_length:
    vectors = embed(generated)                 # Step 2: tokens -> meaning vectors
    probabilities = model.forward(vectors)      # Steps 3-4: the transformer "thinks"
    next_token = sample(probabilities, temperature=0.7)  # Step 5: pick next token
    generated.append(next_token)                # Step 6: repeat with new context

response = detokenize(generated)

Every single API call you make to OpenAI, Anthropic, or Google is, underneath all the
infrastructure, running this loop.

Chapter 4: The Provider Problem — Why Every API Feels Different

Once you decide to build something real, you quickly discover that "calling an LLM" isn't
standardized. Here's what that looks like in practice:

OpenAI's chat completion format wraps messages in a messages array with role and
content fields, and you call client.chat.completions.create(...). Anthropic's Claude
API looks similar on the surface but has different parameter names, a different way of
handling system prompts, and different response object structures. Google's Gemini API
differs again — different SDK, different conventions for multi-turn conversation, different
ways of handling function calling.

Now multiply that by the actual problems teams run into:

Switching cost. You build your app on OpenAI, then your company wants to evaluate Claude for better reasoning on a specific task, or Gemini for cost reasons. Now you're rewriting your integration layer from scratch.
Inconsistent output formats. Getting reliable structured JSON out of one provider doesn't mean the same prompting trick works on another. Each model has its own quirks.
No standard for memory. If you want a chatbot that remembers earlier turns in a conversation, you have to manually manage and re-send conversation history — and every provider expects that history shaped slightly differently.
No standard for tools/agents. Letting a model call external functions (e.g., "look up the weather," "query a database") is implemented differently across providers.
Chaining is manual. Real applications rarely call an LLM once. You might retrieve documents, feed them into a prompt, get a response, parse it, feed that into another prompt. Wiring this by hand, per provider, gets messy fast.

This is the exact pain point that gave rise to orchestration frameworks — and the most
widely adopted one is LangChain.

Chapter 5: Enter LangChain — What It Actually Solves

LangChain is a framework that sits between you and the raw LLM provider APIs, giving
you a consistent set of abstractions regardless of which model is powering things
underneath. Think of it less like "a new way to talk to AI" and more like an ORM (like
SQLAlchemy or Prisma) — except instead of abstracting away different SQL databases, it
abstracts away different LLM providers.

The pitch is simple: write your application logic once, swap the underlying model with
minimal code changes. Switch from GPT-4 to Claude to test which gives better results?
In a well-structured LangChain app, that can be close to a one-line change, not a rewrite.

But LangChain solves more than just "different APIs." It gives you standardized,
composable building blocks for the patterns that show up in every real LLM application:
managing prompts as reusable templates, chaining multiple steps together, maintaining
conversation memory, retrieving relevant data before generating a response, and letting
models call external tools as agents.

⚠️ Heads up: LangChain is not magic and it's not the only way to build AI
applications — you can absolutely call provider SDKs directly, and for simple use cases,
that's sometimes the better call (less abstraction overhead, fewer dependencies). Treat
LangChain as a productivity tool for composable, provider-agnostic applications, not
a mandatory layer for every project.

Chapter 6: LangChain's Core Components

LangChain is organized around a handful of core building blocks. If you understand these
six, you understand the framework's mental model.

Models — The interface to the actual LLM. LangChain splits this into a few types:

Chat/Language models — text in, text out (or more precisely, message-in, message-out for chat models). This is your GPT-4, Claude, Gemini connections.
Embedding models — instead of generating text, these convert text into those numeric vectors we discussed in Chapter 3, used for search and retrieval (this is the backbone of RAG systems).
Multimodal models — models that accept more than just text: images, audio, sometimes video, alongside text.

Prompts — The input you construct to send to the model. We'll go deep on this in the
next chapter since it's where most of your day-to-day engineering time actually goes.

Chains — A sequence of calls linked together, where the output of one step becomes the
input of the next. Classic example: take a user's question → retrieve relevant documents →
stuff those documents into a prompt → send to the LLM → parse the response. That's a chain.

Memory — A mechanism for persisting conversation history across multiple turns, so your
chatbot doesn't forget what the user said three messages ago. Without memory, every API
call is stateless — the model has zero awareness of anything outside the current prompt.

Indexes — Structures (usually backed by vector databases) that let you store and
efficiently search large amounts of external data — your documents, your knowledge base —
so the model can retrieve relevant pieces instead of trying to "know" everything.

Agents — The most advanced building block. Instead of you hardcoding the sequence of
steps, an agent uses the LLM itself to decide what action to take next — which tool to
call, in what order — based on the user's request. This is how you get an AI that can
"search the web, then do math, then write a summary" without you scripting that exact flow.

User question
     │
     ▼
[ Prompt Template ]  ← fills in variables (user input, retrieved context, etc.)
     │
     ▼
[ Chat Model ]  ← OpenAI, Claude, Gemini — swappable
     │
     ▼
[ Output Parser ]  ← turns raw text into structured data your app can use
     │
     ▼
Your application logic

That diagram is, roughly, 80% of real-world LangChain usage. The remaining 20% layers in
memory, retrieval, and agentic decision-making on top.

Chapter 7: Prompts, Prompt Templates, and Structured Output

This is the part that actually consumes most of your engineering time once you start
building, so let's slow down here.

Simple Prompts vs. System + User Prompts

The crudest way to prompt a model is a single block of text — you just write what you
want and send it. That works for quick experiments but falls apart fast in production.

Modern chat models instead expect a structured message format, typically split into
roles:

System prompt — instructions that set the model's behavior, persona, and constraints before the conversation starts. Think of it as the model's "job description." ("You are a customer support assistant for a SaaS billing platform. Only answer questions related to billing. Keep responses under 100 words.")
User prompt — the actual input from the end user. ("Why was I charged twice this month?")

Separating these matters enormously. Mixing instructions and user input into one giant
blob makes the model more likely to follow user instructions that override your intended
behavior (a real security concern — this is part of how prompt injection attacks work).
Keeping them separate is both cleaner and safer.

# Simple prompt — works, but rigid and hard to reuse or secure
simple_prompt = "You are a billing assistant. Why was I charged twice?"

# System + User separation — the standard production pattern
messages = [
    {
        "role": "system",
        "content": "You are a customer support assistant for a SaaS billing platform. "
                    "Only answer questions related to billing. Keep responses concise."
    },
    {
        "role": "user",
        "content": "Why was I charged twice this month?"
    }
]

Prompt Templates

Here's a problem you'll hit on day one of building anything real: your system prompt is
mostly static, but parts of it need to change based on context — the user's name, the
retrieved documents, the current date, the product they're asking about. Hardcoding
f-strings everywhere gets messy and error-prone fast, especially once you have dozens of
prompts across your codebase.

Prompt templates solve this by treating prompts like reusable functions with
parameters — define the structure once, fill in the variables at call time.

from langchain.prompts import ChatPromptTemplate

# Define the template ONCE, with placeholders for dynamic values
template = ChatPromptTemplate.from_messages([
    ("system", "You are a support assistant for {product_name}. "
               "Today's date is {current_date}. Be concise and friendly."),
    ("user", "{user_question}")
])

# Reuse it for every request — just swap in the variables
filled_prompt = template.format_messages(
    product_name="Acme Billing",
    current_date="2026-06-21",
    user_question="Why was I charged twice this month?"
)

This isn't just convenience. Templates make prompts testable (you can version them,
diff them, A/B test wording changes), consistent (every call follows the same
structure, reducing weird edge-case outputs), and maintainable (update the template in
one place instead of hunting through scattered strings across your codebase).

💡 Pro tip: Treat your prompt templates the way you'd treat SQL queries or API
contracts — version-controlled, reviewed in pull requests, and tested. A "small" wording
tweak in a system prompt can meaningfully change model behavior in production.

Structured Output

Here's the next wall every builder hits: LLMs naturally produce free-flowing text, but
your application needs data — a JSON object you can parse, validate, and plug into a
database or UI. "Just ask the model to return JSON" sounds simple and, often, isn't — models
sometimes wrap JSON in explanatory prose, use inconsistent field names, or produce
almost-valid-but-broken JSON.

LangChain addresses this with structured output tooling — you define the shape of
data you want (often using a schema, like a Pydantic model in Python), and LangChain
handles instructing the model to conform to it and parsing/validating the result.

from pydantic import BaseModel, Field
from langchain.chat_models import init_chat_model

# Define the EXACT shape of data you want back — not free text
class SupportTicketSummary(BaseModel):
    issue_category: str = Field(description="One of: billing, technical, account, other")
    urgency: str = Field(description="One of: low, medium, high")
    summary: str = Field(description="One sentence summary of the user's issue")

model = init_chat_model("gpt-4", model_provider="openai")

# Bind the schema — the model's response will be coerced into this structure
structured_model = model.with_structured_output(SupportTicketSummary)

result = structured_model.invoke(
    "Why was I charged twice this month? This is really frustrating, "
    "I need this fixed before my card gets declined again."
)

# 'result' is now a validated SupportTicketSummary object, not raw text:
# SupportTicketSummary(
#     issue_category="billing",
#     urgency="high",
#     summary="User was double-charged and needs urgent resolution."
# )

This is the difference between "an AI feature that's a fun demo" and "an AI feature that
reliably feeds your database without crashing on a malformed response." Structured output
is, in practice, one of the highest-leverage things to get right early — almost every real
AI feature eventually needs the model's output to plug into something downstream:
a UI component, a database row, an API call to another system.

Chapter 8: Common Pitfalls When You're Starting Out

A few things that trip up almost everyone in their first few weeks of AI application
development:

Treating the system prompt as a suggestion, not a contract. Vague system prompts ("be helpful") produce inconsistent behavior. Specific, constrained system prompts produce reliable behavior. Be explicit about scope, tone, format, and what the model should refuse to do.
Skipping output validation. Even with structured output tooling, always validate what comes back before trusting it downstream — models can still fail to conform perfectly, especially with complex nested schemas.
Forgetting that "memory" isn't automatic. Without explicit memory handling, every API call is a blank slate. If your chatbot seems to have amnesia, it's because you're not re-sending prior conversation turns.
Over-engineering with agents too early. Agents are powerful but unpredictable and harder to debug than a fixed chain. Start with a simple, deterministic chain. Reach for agents only when the task genuinely requires dynamic decision-making.
Ignoring token costs and limits. Every provider charges per token and enforces context length limits. Long conversation histories, large retrieved documents, and verbose system prompts all add up fast — both in cost and in risk of hitting context limits.

Wrapping Up

If there's one mental model to walk away with, it's this: an LLM is a next-token predictor
wrapped behind a provider's API, and everything you build sits on top of that simple loop.
The real engineering work — the part that actually makes a product good — isn't in the
model itself. It's in how well you structure your prompts, how reliably you turn model
output into usable data, and how thoughtfully you chain steps together to solve an actual
user problem.

LangChain doesn't replace that thinking — it gives you a consistent vocabulary and toolkit
to express it, regardless of which provider's model happens to sit underneath. Learn the
six building blocks — models, prompts, chains, memory, indexes, agents — and you'll find
that almost every AI application you encounter, no matter how complex it looks from the
outside, is built from some combination of these same simple pieces.

The next step from here is hands-on: pick a tiny project — a document Q&A bot, a
structured data extractor from messy text, anything real — and build it with a prompt
template and structured output from the start. That's where this stuff actually clicks.

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 7 | Combining Observables — `forkJoin`, `combineLatest`, `zip` & More

Jack Pritom Soren — Sun, 21 Jun 2026 13:31:12 +0000

"Combining Observables — `forkJoin`, `combineLatest`, `zip` & More"

👋 Welcome to Chapter 7!

Real apps rarely get data from just one place. A product page might need:

The product details (from /api/products/5)
The user's wishlist (from /api/wishlist)
The store's discount config (from /api/config)

How do you handle multiple Observables at the same time?

That's what today's combination operators are for!

🍽️ The Restaurant Kitchen Analogy

Imagine a chef 👨‍🍳 preparing a 3-course meal:

forkJoin — "Start cooking all 3 dishes at the same time. Serve the full meal ONLY when ALL dishes are ready."
→ Wait for ALL to complete, then give you all results together

combineLatest — "Whenever ANY dish is updated, bring out the current status of all dishes."
→ Every time any Observable emits, give you the latest value from all

zip — "Match dish from kitchen 1 with dish from kitchen 2, one pair at a time."
→ Pairs values by position

Let's see each one in detail.

🍴 `forkJoin` — Wait for All, Then Done

forkJoin runs multiple Observables in parallel and waits until all of them complete. Then it emits all the results at once.

Like Promise.all() but for Observables!

Simple Example

import { forkJoin, of } from 'rxjs';
import { delay } from 'rxjs/operators';

forkJoin({
  users: of(['Alice', 'Bob']).pipe(delay(1000)),
  products: of(['Apple', 'Banana']).pipe(delay(500)),
  config: of({ theme: 'dark' }).pipe(delay(200))
}).subscribe(results => {
  console.log(results.users);    // ['Alice', 'Bob']
  console.log(results.products); // ['Apple', 'Banana']
  console.log(results.config);   // { theme: 'dark' }
});
// All three run in PARALLEL. Total wait time = 1000ms (the slowest)
// If it were sequential, total = 1700ms

Real Angular Example — Loading a Dashboard

// dashboard.component.ts
import { Component, OnInit } from '@angular/core';
import { forkJoin } from 'rxjs';

@Component({
  selector: 'app-dashboard',
  template: `
    <div *ngIf="!isLoading">
      <div class="stats-card">
        <h3>Total Users</h3>
        <p>{{ stats?.totalUsers }}</p>
      </div>
      <div class="stats-card">
        <h3>Orders Today</h3>
        <p>{{ stats?.ordersToday }}</p>
      </div>
      <div class="stats-card">
        <h3>Revenue</h3>
        <p>৳{{ stats?.revenue }}</p>
      </div>
      <div class="recent-orders">
        <h3>Recent Orders</h3>
        <div *ngFor="let order of recentOrders">
          {{ order.id }} — {{ order.status }}
        </div>
      </div>
    </div>

    <div *ngIf="isLoading">Loading dashboard... ⏳</div>
    <div *ngIf="error">{{ error }}</div>
  `
})
export class DashboardComponent implements OnInit {

  stats: any = null;
  recentOrders: any[] = [];
  isLoading = true;
  error = '';

  constructor(
    private statsService: StatsService,
    private orderService: OrderService
  ) {}

  ngOnInit(): void {
    // Load BOTH at the same time — wait for both to finish
    forkJoin({
      stats: this.statsService.getDashboardStats(),
      orders: this.orderService.getRecentOrders(5)
    }).subscribe({
      next: ({ stats, orders }) => {
        this.stats = stats;
        this.recentOrders = orders;
        this.isLoading = false;
      },
      error: (err) => {
        this.error = 'Failed to load dashboard data';
        this.isLoading = false;
      }
    });
  }
}

⚠️ Important: forkJoin only works with Observables that COMPLETE!

HttpClient calls complete after one response ✅
BehaviorSubject never completes ❌ (use combineLatest instead)

🔄 `combineLatest` — React to Any Change

combineLatest watches multiple Observables and every time any one of them emits, it gives you the latest values from ALL of them.

It's perfect for filter/search UIs where changing any filter should update the results.

Simple Example

import { combineLatest, BehaviorSubject } from 'rxjs';

const searchTerm$ = new BehaviorSubject<string>('');
const category$ = new BehaviorSubject<string>('all');
const priceMax$ = new BehaviorSubject<number>(1000);

combineLatest([searchTerm$, category$, priceMax$])
  .subscribe(([search, category, maxPrice]) => {
    console.log(`Search: ${search}, Category: ${category}, Max: ${maxPrice}`);
  });

// Output immediately: Search: , Category: all, Max: 1000

searchTerm$.next('phone');
// Output: Search: phone, Category: all, Max: 1000

category$.next('electronics');
// Output: Search: phone, Category: electronics, Max: 1000

priceMax$.next(500);
// Output: Search: phone, Category: electronics, Max: 500

Every time any filter changes, you get all three latest values!

Real Angular Example — Product Filter Page

// product-filter.component.ts
import { Component, OnInit } from '@angular/core';
import { FormControl } from '@angular/forms';
import { combineLatest, Observable } from 'rxjs';
import { map, startWith, debounceTime } from 'rxjs/operators';

@Component({
  selector: 'app-product-filter',
  template: `
    <div class="filters">
      <input [formControl]="searchControl" placeholder="Search...">

      <select [formControl]="categoryControl">
        <option value="all">All Categories</option>
        <option value="electronics">Electronics</option>
        <option value="clothing">Clothing</option>
        <option value="food">Food</option>
      </select>

      <label>Max Price: ৳{{ priceControl.value }}</label>
      <input type="range" [formControl]="priceControl" min="0" max="10000" step="100">
    </div>

    <p>Showing {{ (filteredProducts$ | async)?.length }} products</p>

    <div *ngFor="let product of filteredProducts$ | async" class="product-card">
      <h3>{{ product.name }}</h3>
      <span>৳{{ product.price }}</span>
      <span class="tag">{{ product.category }}</span>
    </div>
  `
})
export class ProductFilterComponent implements OnInit {

  searchControl = new FormControl('');
  categoryControl = new FormControl('all');
  priceControl = new FormControl(10000);

  allProducts: Product[] = [];
  filteredProducts$!: Observable<Product[]>;

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    // First, load all products
    this.productService.getProducts().subscribe(products => {
      this.allProducts = products;
    });

    // Watch all three filters — update results whenever any changes
    this.filteredProducts$ = combineLatest([
      this.searchControl.valueChanges.pipe(startWith(''), debounceTime(300)),
      this.categoryControl.valueChanges.pipe(startWith('all')),
      this.priceControl.valueChanges.pipe(startWith(10000))
    ]).pipe(
      map(([search, category, maxPrice]) => {
        return this.allProducts.filter(product => {

          const matchesSearch = !search ||
            product.name.toLowerCase().includes(search.toLowerCase());

          const matchesCategory = category === 'all' ||
            product.category === category;

          const matchesPrice = product.price <= (maxPrice || 10000);

          return matchesSearch && matchesCategory && matchesPrice;
        });
      })
    );
  }
}

This is real production-grade code! The filter UI updates instantly as the user adjusts any control — no button needed!

🤝 `withLatestFrom` — Use the Latest Value Without Triggering

withLatestFrom is like combineLatest, but it only triggers when the first Observable emits — it just grabs the latest value from the others as a "snapshot".

import { withLatestFrom } from 'rxjs/operators';

// When a button is clicked, grab the current user and filter state
buttonClick$
  .pipe(
    withLatestFrom(currentUser$, activeFilters$)
  )
  .subscribe(([clickEvent, user, filters]) => {
    // Only triggered by clicks, but we have user and filters available
    this.logUserAction(user, filters, 'EXPORT');
  });

Real Example — Save Button with Form State

// When save is clicked, capture the CURRENT form values
this.saveButton.clicks$
  .pipe(
    withLatestFrom(this.form.valueChanges.pipe(startWith(this.form.value)))
  )
  .subscribe(([_, formValues]) => {
    this.save(formValues);
  });

🤐 `zip` — Pair by Position

zip waits for ALL Observables to emit one value, then combines them by position. Like a zipper — left tooth, right tooth, left tooth, right tooth...

import { zip, of } from 'rxjs';

const names$ = of('Alice', 'Bob', 'Charlie');
const scores$ = of(95, 87, 92);
const grades$ = of('A', 'B+', 'A-');

zip(names$, scores$, grades$).subscribe(([name, score, grade]) => {
  console.log(`${name}: ${score} (${grade})`);
});

// Output:
// Alice: 95 (A)
// Bob: 87 (B+)
// Charlie: 92 (A-)

zip is less commonly used in Angular, but handy when you need to pair corresponding items.

🏗️ Full Real-World Example — Product Detail Page

A product detail page often needs data from multiple APIs. Here's the complete pattern:

// product-detail.component.ts
import { Component, OnInit } from '@angular/core';
import { ActivatedRoute } from '@angular/router';
import { forkJoin, combineLatest, Observable, EMPTY } from 'rxjs';
import { switchMap, catchError, map } from 'rxjs/operators';

interface PageData {
  product: Product;
  reviews: Review[];
  isInWishlist: boolean;
  relatedProducts: Product[];
}

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

        <button [class.active]="data.isInWishlist" (click)="toggleWishlist()">
          {{ data.isInWishlist ? '❤️ Wishlisted' : '🤍 Add to Wishlist' }}
        </button>
      </div>

      <section class="reviews">
        <h2>Reviews ({{ data.reviews.length }})</h2>
        <div *ngFor="let review of data.reviews">
          <strong>{{ review.author }}</strong>
          <span>⭐ {{ review.rating }}</span>
          <p>{{ review.comment }}</p>
        </div>
      </section>

      <section class="related">
        <h2>Related Products</h2>
        <div *ngFor="let related of data.relatedProducts" class="mini-card">
          {{ related.name }} — ৳{{ related.price }}
        </div>
      </section>
    </ng-container>

    <div *ngIf="isLoading">Loading... ⏳</div>
    <div *ngIf="errorMessage">{{ errorMessage }}</div>
  `
})
export class ProductDetailComponent implements OnInit {

  pageData$!: Observable<PageData>;
  isLoading = true;
  errorMessage = '';

  constructor(
    private route: ActivatedRoute,
    private productService: ProductService,
    private reviewService: ReviewService,
    private wishlistService: WishlistService
  ) {}

  ngOnInit(): void {

    this.pageData$ = this.route.params.pipe(
      switchMap(params => {
        const id = params['id'];

        // Load ALL data for this product in parallel
        return forkJoin({
          product: this.productService.getProduct(id),
          reviews: this.reviewService.getReviews(id),
          isInWishlist: this.wishlistService.isInWishlist(id),
          relatedProducts: this.productService.getRelated(id)
        });
      }),
      catchError(err => {
        this.errorMessage = 'Failed to load product details';
        this.isLoading = false;
        return EMPTY;
      })
    );

    // Track loading state
    this.pageData$.subscribe(() => {
      this.isLoading = false;
    });
  }

  toggleWishlist(): void {
    // ... toggle logic
  }
}

Everything loads in parallel, the route handles navigation, and errors are caught gracefully — all in one clean stream!

🧠 Choosing the Right Combination Operator

forkJoin — "Load everything once, wait for all to finish, give me all results"
Best for: page initialization, loading multiple API resources at once

combineLatest — "Every time ANYTHING changes, give me all the latest values"
Best for: filter/search UIs, forms with live preview, dashboards with real-time updates

withLatestFrom — "When THIS happens, also give me the latest value of THAT"
Best for: button clicks that need current state, actions that depend on form values

zip — "Match item 1 with item 1, item 2 with item 2..."
Best for: combining two arrays where order corresponds

🧠 Chapter 7 Summary — What You Learned

forkJoin runs multiple Observables in parallel and emits all results when ALL complete — like Promise.all()
combineLatest emits whenever any Observable emits, always giving you the latest from all — perfect for filter UIs
withLatestFrom only triggers from one source, but snapshots the latest value from others
zip pairs values by position from multiple Observables
These operators are essential for building real-world pages that need data from multiple sources

📚 Coming Up in Chapter 8...

One of the most powerful and real-world RxJS patterns in Angular:

Angular Forms + RxJS — how to build reactive forms with live validation, dependent fields, and dynamic behavior using valueChanges, statusChanges, and the operators we've learned!

See you in Chapter 8! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 7 of 10

Follow me on : Github Linkedin Threads Youtube Channel

The JavaScript Event Loop: Why Your Code Doesn't Do What You Think It Does

Jack Pritom Soren — Fri, 15 May 2026 13:00:03 +0000

JavaScript is single-threaded. One thread. One call stack. One thing at a time.

And yet — you've written code that fetches data from an API while animating a loading spinner while handling button clicks while running a countdown timer. How? How does one thread do all of that without freezing?

The answer is the event loop — arguably the most misunderstood piece of the JavaScript runtime. Most developers use it every day without ever truly seeing it. They write setTimeout, Promise.then(), async/await, and fetch() like they're magic spells, and they mostly work — until they don't.

Until you've hit a bug where a setTimeout(..., 0) fires after something it should have fired before. Until a Promise resolves in an order that makes no logical sense to you. Until your UI freezes solid because a loop ran too long. That's when you realize: you've been flying blind.

Understanding the event loop isn't just academic. It's the difference between writing JavaScript that works and writing JavaScript that you understand. It explains why async/await is not the same as threads, why microtasks beat macrotasks, and why your beautiful Promise chain sometimes feels like it has a mind of its own.

This article is the deep dive nobody wrote clearly enough. By the end, you'll be able to look at any piece of async JavaScript and trace — in your head, step by step — exactly what order things will execute and why.

What We'll Cover

The Single-Threaded Reality
The Call Stack — JavaScript's Working Memory
The Web APIs Layer — Where Async Work Actually Happens
The Callback Queue (Macrotask Queue)
The Microtask Queue — The Queue That Jumps the Line
The Event Loop — The Conductor Tying It All Together
setTimeout and setInterval — What They Actually Promise
Promises and the Microtask Queue
async/await — Syntactic Sugar with Real Consequences
Real-World Execution Order Puzzles (With Solutions)
Pitfalls That Will Bite You in Production
Conclusion — The Mental Model You'll Keep Forever

1. The Single-Threaded Reality

Let's start with what "single-threaded" actually means, because it's more nuanced than it sounds.

A thread is a sequence of instructions a CPU can execute. Some languages — Java, Go, C++ — are multi-threaded, meaning they can genuinely run multiple instruction sequences simultaneously on different CPU cores. They share memory, they can race each other, and you need mutexes and semaphores and all sorts of painful synchronization primitives to keep them from stepping on each other.

JavaScript deliberately chose not to do that. One thread. No shared memory races. No deadlocks. No mutexes.

But here's the thing people miss: JavaScript is single-threaded, but the browser (or Node.js) is not. The runtime environment — Chrome, Firefox, Node — is heavily multi-threaded. It has threads for network I/O, file I/O, timers, rendering, garbage collection, and more. JavaScript itself runs on one thread, but it delegates slow work to those other threads.

The event loop is the mechanism by which results from those other threads get handed back to your JavaScript code, safely, one at a time.

2. The Call Stack — JavaScript's Working Memory

The call stack is where JavaScript tracks what it's currently executing. It's a stack data structure — last in, first out — and every time you call a function, a new stack frame gets pushed on top. When the function returns, that frame gets popped off.

function greet(name) {
    return `Hello, ${name}!`;         // 3. This executes, returns
}

function main() {
    const message = greet("Fatima");  // 2. greet() is pushed onto stack
    console.log(message);             // 4. console.log is pushed, executes, pops
}

main();                               // 1. main() is pushed onto stack

Execution trace:

[] → [main] → [main, greet] → [main] → [main, console.log] → [main] → []

The call stack is synchronous and blocking. If you put a while(true) loop in there, the stack never clears. Nothing else runs. Your UI freezes. The browser tab hangs.

This is why long-running synchronous operations are the enemy. They hold the stack hostage.

3. The Web APIs Layer — Where Async Work Actually Happens

When you call fetch(), setTimeout(), addEventListener(), or fs.readFile() — you are not running JavaScript. You're calling into the Web APIs layer (in the browser) or the Node.js C++ APIs layer.

Think of it like handing off a task to a dedicated department:

"Go make this HTTP request. Come back when you have a response."
"Set a timer for 500ms. Come back when it fires."
"Watch this DOM element for a click. Come back when it happens."

JavaScript doesn't wait. It just hands off the task, registers a callback, and moves on. The API does the work — off the main thread, in the background — and when it's done, it puts your callback in a queue.

console.log("1 — Starting");

// This call goes to the Timer Web API.
// JavaScript does NOT wait here. It just registers the callback and moves on.
setTimeout(() => {
    console.log("3 — Timer fired");
}, 1000);

console.log("2 — Already past the setTimeout");

// Output:
// 1 — Starting
// 2 — Already past the setTimeout
// (1 second later...)
// 3 — Timer fired

JavaScript handed the timer to the browser, said "call me back in 1000ms," and kept running. That's non-blocking I/O in a nutshell.

4. The Callback Queue (Macrotask Queue)

When an async operation completes — a timer fires, a network response arrives, a click event triggers — the callback associated with it gets placed in the callback queue (also called the macrotask queue or task queue).

This queue holds tasks waiting for their turn to run. They can't jump onto the call stack directly. They have to wait.

Common sources of macrotasks:

setTimeout callbacks
setInterval callbacks
I/O callbacks (file reads, network responses in Node.js)
UI event handlers (click, keydown, scroll)
postMessage callbacks
setImmediate (Node.js only)

The queue is processed one task at a time. Each task runs to completion — no interruption. If a task takes 500ms, the browser is locked for 500ms. This is why you'll sometimes see the browser devtools warn about "long tasks."

5. The Microtask Queue — The Queue That Jumps the Line

Here's where most developers' mental models break down.

There are two queues, not one. The second is the microtask queue, and it has priority over the callback queue. Every single time.

Sources of microtasks:

Promise.then() / Promise.catch() / Promise.finally() callbacks
queueMicrotask()
MutationObserver callbacks
await (under the hood, it's a promise)

The rule is this: after every task completes (or after the initial script finishes), the entire microtask queue is drained before the next macrotask runs.

Not one microtask. All of them. And if a microtask schedules another microtask, that one runs too, before any macrotask.

console.log("1 — Script start");

setTimeout(() => console.log("5 — setTimeout"), 0);  // Macrotask

Promise.resolve()
    .then(() => console.log("3 — Promise 1"))         // Microtask
    .then(() => console.log("4 — Promise 2"));        // Microtask (scheduled by microtask)

console.log("2 — Script end");

// Output:
// 1 — Script start
// 2 — Script end
// 3 — Promise 1
// 4 — Promise 2
// 5 — setTimeout

Even though setTimeout was registered before the Promise chain, it fires after both promise callbacks. The entire microtask queue empties first.

6. The Event Loop — The Conductor Tying It All Together

The event loop is the algorithm that orchestrates all of this. Here it is, in pseudocode:

while (true) {
    // 1. Run the current task (or the initial script)
    executeCurrentTask();

    // 2. Drain the entire microtask queue
    while (microtaskQueue.isNotEmpty()) {
        microtaskQueue.dequeue().execute();
        // Note: if this microtask adds more microtasks, those run too
    }

    // 3. Maybe render (browser decides, typically ~60fps)
    if (renderingNeeded) {
        render();
    }

    // 4. Pick the next macrotask from the callback queue
    if (callbackQueue.isNotEmpty()) {
        currentTask = callbackQueue.dequeue();
    }
}

The loop is always watching. When the call stack is empty and there are tasks waiting, it picks the next one and runs it. But it always drains microtasks first.

Here's the full picture as a diagram:

┌─────────────────────────────────────────────────┐
│                 Your JS Code                    │
│                  Call Stack                     │
└────────────────────┬────────────────────────────┘
                     │
           calls Web APIs / Node APIs
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│            Web APIs / C++ APIs                  │
│   (setTimeout, fetch, fs.readFile, events...)   │
└──────┬──────────────────────┬───────────────────┘
       │                      │
       ▼                      ▼
┌─────────────┐      ┌──────────────────┐
│  Microtask  │      │  Callback Queue  │
│    Queue    │      │  (Macrotask Q.)  │
│  (Promises) │      │  (setTimeout,    │
│             │      │   I/O, events)   │
└──────┬──────┘      └────────┬─────────┘
       │                      │
       └──────────┬───────────┘
                  │
                  ▼
           ┌──────────────┐
           │  Event Loop  │ ◄── "Is the stack empty?
           │              │      Drain microtasks.
           └──────────────┘      Then run next macrotask."

7. `setTimeout` and `setInterval` — What They Actually Promise

setTimeout(fn, delay) does not guarantee your callback runs after exactly delay milliseconds. It guarantees the callback will be added to the macrotask queue no sooner than delay milliseconds from now.

If the call stack is busy, the callback waits — no matter how long.

const start = Date.now();

// This timer should fire after 100ms.
setTimeout(() => {
    // In reality, this will log something much larger than 100.
    console.log(`Fired after ${Date.now() - start}ms`);
}, 100);

// This synchronous loop blocks the call stack for ~500ms.
// The setTimeout callback is in the queue, but it can't run yet.
const blockUntil = Date.now() + 500;
while (Date.now() < blockUntil) {
    // spinning — this is exactly the kind of code that freezes UIs
}

// Output: something like "Fired after 502ms" — not 100ms

setTimeout(..., 0) is often used as a trick to defer code to the next iteration of the event loop — but it's still a macrotask, so it yields to all pending microtasks first.

8. Promises and the Microtask Queue

Every .then(), .catch(), and .finally() callback is a microtask. This is baked into the Promise specification — not a browser decision.

console.log("start");

const p = new Promise((resolve) => {
    // The executor function runs SYNCHRONOUSLY, right now.
    console.log("inside Promise constructor");
    resolve("done");
});

p.then((value) => {
    // This runs as a MICROTASK — after the current synchronous code finishes.
    console.log("then:", value);
});

console.log("end");

// Output:
// start
// inside Promise constructor
// end
// then: done

The Promise constructor runs synchronously. The .then() callback does not — it queues as a microtask and runs after the current call stack empties.

This surprises a lot of developers. They expect the .then() to run right after resolve(). It doesn't. It politely waits its turn.

9. `async/await` — Syntactic Sugar with Real Consequences

async/await is beautiful syntax. But it's crucial to understand what it compiles to, because the semantics are the same as Promises — just dressed up.

// This async function...
async function fetchUser(id) {
    const response = await fetch(`/api/users/${id}`);
    const user = await response.json();
    return user;
}

// ...is roughly equivalent to this Promise chain:
function fetchUser(id) {
    return fetch(`/api/users/${id}`)
        .then(response => response.json())
        .then(user => user);
}

Every await is a suspension point. When you await something, the async function pauses and hands control back to the caller. The code after the await is scheduled as a microtask to run when the awaited Promise resolves.

async function main() {
    console.log("1 — before await");

    await Promise.resolve();  // Suspends here. Resumes as microtask.

    console.log("3 — after await");  // Runs as microtask
}

main();
console.log("2 — after calling main()");

// Output:
// 1 — before await
// 2 — after calling main()
// 3 — after await

When main() hits the await, it suspends. JavaScript keeps running synchronously past the main() call and logs "2". Then the microtask runs and logs "3".

async/await does not make code run on a different thread. It's still single-threaded. It just makes asynchronous code look synchronous while still yielding the call stack between operations.

10. Real-World Execution Order Puzzles

Let's put it all together. Work through these before peeking at the answers.

Puzzle 1

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve().then(() => {
    console.log("C");
    setTimeout(() => console.log("D"), 0);
});

console.log("E");

Answer

A
E
C
B
D

Why:

A — synchronous
setTimeout B → macrotask queue
Promise → microtask queue
E — synchronous
Call stack empty → drain microtasks: C logs, setTimeout D → macrotask queue
No more microtasks → run next macrotask: B
No more microtasks → run next macrotask: D

Puzzle 2

async function alpha() {
    console.log("alpha 1");
    await null;
    console.log("alpha 2");
}

async function beta() {
    console.log("beta 1");
    await null;
    console.log("beta 2");
}

console.log("start");
alpha();
beta();
console.log("end");

Answer

start
alpha 1
beta 1
end
alpha 2
beta 2

Why:

start — sync
alpha() runs: logs alpha 1, hits await, suspends → schedules microtask
beta() runs: logs beta 1, hits await, suspends → schedules microtask
end — sync
Call stack empty → drain microtasks: alpha 2, then beta 2

11. Pitfalls That Will Bite You in Production

Starving the render with too many microtasks

Because microtasks all run before the browser gets a chance to render, an infinite microtask loop will lock up the UI just as badly as a synchronous loop — possibly worse, because it looks like async code.

// ❌ Don't do this — infinite microtask loop, browser never renders
function infiniteMicrotasks() {
    Promise.resolve().then(infiniteMicrotasks);
}
infiniteMicrotasks();

// ✅ If you need to yield to rendering, use setTimeout or requestAnimationFrame
function yieldToRender(fn) {
    requestAnimationFrame(fn);  // Runs after the next render frame
}

Unhandled Promise rejections are silent killers

// ❌ This rejection is unhandled. In older Node versions it silently fails.
//    In modern Node, it crashes the process.
async function riskyOperation() {
    throw new Error("Something went wrong");
}

riskyOperation(); // Missing await AND missing .catch()

// ✅ Always handle rejections
riskyOperation().catch(err => console.error("Caught:", err));

// ✅ Or use try/catch with await
try {
    await riskyOperation();
} catch (err) {
    console.error("Caught:", err);
}

`await` inside loops — sequential vs parallel

const userIds = [1, 2, 3, 4, 5];

// ❌ Sequential — each fetch waits for the previous to finish.
//    Total time: sum of all request times. Slow.
async function fetchSequential(ids) {
    const results = [];
    for (const id of ids) {
        const user = await fetchUser(id);  // Waits here before next iteration
        results.push(user);
    }
    return results;
}

// ✅ Parallel — all requests fire at once.
//    Total time: slowest single request. Fast.
async function fetchParallel(ids) {
    const promises = ids.map(id => fetchUser(id));  // Fire all, don't await yet
    return await Promise.all(promises);              // Wait for all to complete
}

The `forEach` async trap

const data = [1, 2, 3];

// ❌ forEach doesn't await async callbacks. It fires them all and moves on.
//    "Done" prints before any of the async work finishes.
data.forEach(async (item) => {
    await processItem(item);
});
console.log("Done");  // Prints immediately — not actually done

// ✅ Use for...of when you need to await inside a loop
for (const item of data) {
    await processItem(item);
}
console.log("Done");  // Now actually done

12. Conclusion — The Mental Model You'll Keep Forever

Here's the mental model, distilled:

JavaScript has one thread, one call stack. It can only do one thing at a time. Async operations — timers, network calls, I/O — get delegated to the browser/Node runtime, which handles them off the main thread. When they complete, callbacks get queued.

Two queues exist. The microtask queue (Promises, await) and the macrotask queue (setTimeout, I/O, events). After every task — including the initial script — the entire microtask queue drains before the next macrotask runs.

async/await is Promises in a costume. Beautiful, readable, but the same underlying semantics. Every await suspends the function and schedules the rest as a microtask.

Once this model clicks, async JavaScript stops being magic. You can trace any execution order in your head. You know why setTimeout(..., 0) doesn't always mean "immediately." You know why a Promise resolves after your synchronous code. You know why that forEach with await inside was never actually doing what you thought.

The event loop is the heartbeat of JavaScript. Understanding it doesn't just make you better at debugging async bugs — it makes you better at writing async code in the first place. You start structuring things around how JavaScript actually works, rather than how you wish it worked.

Go write something async. Then trace through it mentally. If you get the order right — you've got it.

Further reading: MDN's Concurrency model and the event loop, Jake Archibald's classic talk "In The Loop" (JSConf Asia), and the WHATWG HTML spec on the event loop processing model if you really want to go deep.

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

DEV Community: Jack Pritom Soren

RxJS in Angular — Chapter 8 | RxJS + Angular Reactive Forms — Live Validation ও Dynamic Forms

"RxJS + Angular Reactive Forms — Live Validation & Dynamic Forms"

👋 Welcome to Chapter 8!

🎛️ The Reactive Forms Quick Setup

app.module.ts

💡 The Key Streams on Every FormControl

🔍 Real Example 1 — Live Username Availability Check

🏙️ Real Example 2 — Dependent Dropdowns (Country → City)

💰 Real Example 3 — Live Price Calculator

🔧 Using statusChanges for Async Validators

🧠 Chapter 8 Summary — What You Learned

📚 Coming Up in Chapter 9...

What Actually Happens When You Type "What is Python?" Into ChatGPT

What We'll Cover

Chapter 1: The Three Layers of the Generative AI World

Chapter 2: What an LLM Actually Is

Chapter 3: What Happens When You Type "What is Python?"

Chapter 4: The Provider Problem — Why Every API Feels Different

Chapter 5: Enter LangChain — What It Actually Solves

Chapter 6: LangChain's Core Components

Chapter 7: Prompts, Prompt Templates, and Structured Output

Simple Prompts vs. System + User Prompts

Prompt Templates

Structured Output

Chapter 8: Common Pitfalls When You're Starting Out

Wrapping Up

RxJS in Angular — Chapter 7 | Combining Observables — `forkJoin`, `combineLatest`, `zip` & More

"Combining Observables — forkJoin, combineLatest, zip & More"

👋 Welcome to Chapter 7!

🍽️ The Restaurant Kitchen Analogy

🍴 forkJoin — Wait for All, Then Done

Simple Example

Real Angular Example — Loading a Dashboard

🔄 combineLatest — React to Any Change

Simple Example

Real Angular Example — Product Filter Page

🤝 withLatestFrom — Use the Latest Value Without Triggering

Real Example — Save Button with Form State

🤐 zip — Pair by Position

🏗️ Full Real-World Example — Product Detail Page

🧠 Choosing the Right Combination Operator

🧠 Chapter 7 Summary — What You Learned

📚 Coming Up in Chapter 8...

The JavaScript Event Loop: Why Your Code Doesn't Do What You Think It Does

What We'll Cover

1. The Single-Threaded Reality

2. The Call Stack — JavaScript's Working Memory

3. The Web APIs Layer — Where Async Work Actually Happens

4. The Callback Queue (Macrotask Queue)

5. The Microtask Queue — The Queue That Jumps the Line

6. The Event Loop — The Conductor Tying It All Together

7. setTimeout and setInterval — What They Actually Promise

8. Promises and the Microtask Queue

9. async/await — Syntactic Sugar with Real Consequences

10. Real-World Execution Order Puzzles

Puzzle 1

Puzzle 2

11. Pitfalls That Will Bite You in Production

Starving the render with too many microtasks

Unhandled Promise rejections are silent killers

await inside loops — sequential vs parallel

The forEach async trap

12. Conclusion — The Mental Model You'll Keep Forever

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

🔧 Using `statusChanges` for Async Validators

"Combining Observables — `forkJoin`, `combineLatest`, `zip` & More"

🍴 `forkJoin` — Wait for All, Then Done

🔄 `combineLatest` — React to Any Change

🤝 `withLatestFrom` — Use the Latest Value Without Triggering

🤐 `zip` — Pair by Position

7. `setTimeout` and `setInterval` — What They Actually Promise

9. `async/await` — Syntactic Sugar with Real Consequences

`await` inside loops — sequential vs parallel

The `forEach` async trap

🥅 `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