DEV Community: Jack Pritom Soren

Building AI Agents with LangChain: From Runnables to Production-Ready Tools

Jack Pritom Soren — Sat, 15 Aug 2026 12:27:13 +0000

The Problem We're Solving

You've got a language model that can follow instructions beautifully — it can write code, answer questions, reason through problems. But here's the wall every developer hits: an LLM alone can't actually do anything in the real world.

Your model can tell you what the weather is, but it can't call the weather API. It can explain how to write a database query, but it can't run one against your actual database. It can suggest which tool to use, but it needs you to wire up the logic to actually invoke that tool.

That gap — between what an LLM can decide to do and what it can actually execute — is exactly what LangChain agents bridge. And they do it with elegance: you describe your tools, the agent figures out when to use them, and the framework handles all the plumbing.

But "agents" isn't one thing. It's a stack. And before you can build a production agent that talks to APIs, handles errors, and loops with human feedback, you need to understand Runnables — the fundamental building block that makes everything work.

This guide walks you through that entire stack. By the end, you'll understand not just how to build agents, but why each piece exists and how to compose them for production workloads.

What We'll Cover

Runnables: The Foundation — Understanding the interface that powers everything
Chaining Components — Building your first multi-step workflow
Building a Code Generator — A practical first agent that chains LLM calls
Tools: Teaching Agents to Act — How to give your agent superpowers
Creating Custom Tools — Wrapping your Python code so agents can use it
Tool Binding and Calling — How the model decides which tool to use
The Agent Loop: Execution and Control — Manual agent construction for fine-grained control
Integrating Real APIs — A complete weather agent example
Advanced Patterns and create_agent — Modern LangChain shortcuts and when to use them
Pitfalls and Production Lessons — Common failures and how to avoid them

1. Runnables: The Foundation

Before agents, before tools, before any of the magic — there's Runnable.

If you've used LangChain, you've probably seen this pattern:

from langchain_openai import ChatOpenAI

model = ChatOpenAI(model="gpt-4")
result = model.invoke("What is 2 + 2?")

That invoke() call? That's a Runnable. The model is a Runnable. And understanding what Runnables are is the key to everything that follows.

What is a Runnable?

A Runnable is LangChain's abstraction for anything that takes input, processes it, and returns output. It's a contract that says: "I can be invoked, streamed, batched, or composed with other things."

Think of it like this: if you've ever used Unix pipes (cat file | grep pattern | wc -l), Runnables work the same way. Each pipe operation is independent, but you can compose them. Each step doesn't need to know about the others — it just needs to understand input and output.

Here's the key insight: everything in LangChain is a Runnable. Models, prompt templates, output parsers, tools, chains — they all implement the same interface. That's what makes composition so powerful.

from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

# Each of these is a Runnable
prompt = ChatPromptTemplate.from_template("Tell me a joke about {topic}")
model = ChatOpenAI(model="gpt-4")
parser = StrOutputParser()

# Chain them together using the pipe operator |
# This creates a new Runnable that chains all three
joke_chain = prompt | model | parser

# Now invoke it with input
result = joke_chain.invoke({"topic": "debugging"})
print(result)
# Output: "Why do programmers prefer dark mode? Because light attracts bugs!"

Notice the | operator. That's the pipe — it chains Runnables together. When you invoke the final chain, LangChain automatically:

Passes your input to the first Runnable (prompt)
Takes that output and passes it to the next (model)
Takes that output and passes it to the next (parser)
Returns the final result

This is declarative composition. You describe the flow, LangChain handles the threading.

Why This Matters for Agents

Agents are just more complex Runnable chains. An agent is:

A prompt (Runnable)
A model (Runnable)
A tool executor (Runnable)
Looped until the model says "stop"

Once you get the Runnable pattern, agents become less mysterious. They're just composition taken a step further.

2. Chaining Components

Let's build something slightly more complex — a chain that combines multiple steps.

Suppose you're building a product recommendation system. You need to:

Take a user's preferences
Pass them to an LLM to generate a search query
Use that query to find products
Pass the results back to the LLM to write recommendations

Here's how you'd structure this with Runnables:

from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

# Step 1: Generate a search query from preferences
query_prompt = ChatPromptTemplate.from_template(
    """Given these user preferences, generate a concise search query.

User preferences: {preferences}

Search query:"""
)

model = ChatOpenAI(model="gpt-4")
query_parser = StrOutputParser()

# This chain transforms preferences → search query
search_query_chain = query_prompt | model | query_parser

# Step 2: Mock product search (in reality, this calls an API)
def search_products(query):
    """Simulate a product search. In production, this hits your database."""
    # Pretend we found these products
    return f"Found products matching '{query}': Laptop Pro 15, Gaming Mouse RGB, USB-C Hub"

# Step 3: Generate recommendations from search results
recommendation_prompt = ChatPromptTemplate.from_template(
    """You are a product recommendation expert.

User preferences: {preferences}
Search results: {search_results}

Write a brief recommendation based on these results."""
)

recommendation_chain = recommendation_prompt | model | query_parser

# Now compose the entire flow
from langchain_core.runnables import RunnablePassthrough

# RunnablePassthrough keeps the original input flowing through the chain
full_chain = (
    RunnablePassthrough.assign(search_results=search_query_chain | (lambda q: search_products(q)))
    | recommendation_chain
)

# Execute it
result = full_chain.invoke({"preferences": "I need a laptop for video editing"})
print(result)

This is still just a chain — deterministic, no looping. But notice the pattern: you describe the structure, compose Runnables, and invoke the whole thing. Agents will follow this exact pattern, just with the addition of a loop and the ability to dynamically choose which tool to use.

3. Building a Code Generator: A Practical First Agent

Let's build something that feels agent-like: a chain that generates Python code for a user request, and optionally improves it.

This isn't a full agent yet (no dynamic tool selection), but it demonstrates the chain patterns you'll see in real agents.

from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

model = ChatOpenAI(model="gpt-4")

# Step 1: Generate initial code
code_gen_prompt = ChatPromptTemplate.from_template(
    """You are an expert Python developer.
Generate clean, well-commented Python code for this request.

Request: {request}

Only output the code, no explanations."""
)

# Step 2: Review and improve the code
review_prompt = ChatPromptTemplate.from_template(
    """Review this Python code for:
- Efficiency
- Readability
- Best practices
- Potential bugs

Code:
{code}

Provide the improved code with inline comments explaining any changes."""
)

# Compose into a pipeline
code_gen_chain = code_gen_prompt | model | StrOutputParser()

# This is the key: pass the original request through, while also computing the generated code
code_review_chain = (
    RunnablePassthrough.assign(code=code_gen_chain)
    | review_prompt
    | model
    | StrOutputParser()
)

# Execute
result = code_review_chain.invoke({
    "request": "Write a function that checks if a number is prime"
})

print(result)

Here's what's happening under the hood:

RunnablePassthrough.assign() keeps the original input and adds a new field (code) computed by running code_gen_chain
The enriched input flows to review_prompt
The model reviews the code
The parser returns clean text

This pattern is crucial for agents: at each step, you're enriching the context with new information, and that context flows to the next step.

4. Tools: Teaching Agents to Act

Now we get to the real power. A Tool is how you tell an agent: "Here's something you can do in the real world."

Before we build custom tools, let's understand what a Tool is:

from langchain_core.tools import tool

# Define a tool using the @tool decorator
@tool
def get_current_time() -> str:
    """Get the current date and time.

    This tool is useful when the user asks about the current time,
    date, or needs to schedule something."""
    from datetime import datetime
    return datetime.now().isoformat()

@tool
def calculator(expression: str) -> str:
    """Evaluate a mathematical expression.

    Args:
        expression: A valid Python math expression (e.g., '2 + 2' or 'sqrt(16)')

    This tool is useful for calculations the model should perform precisely."""
    try:
        # Use Python's eval (never do this in production with untrusted input!)
        result = eval(expression)
        return f"Result: {result}"
    except Exception as e:
        return f"Error: {e}"

# Tools are now Runnables
print(get_current_time.invoke({}))
print(calculator.invoke({"expression": "2 ** 10"}))

Notice the docstrings. The docstring is what the LLM sees. It's your API documentation for the model. Good docstrings = good tool usage.

A Tool is:

A callable function
A name (derived from function name)
A description (the docstring)
Input schema (the function parameters)
A Runnable that can be invoked

The model will never see your code. It only sees the tool name, description, and parameter names. So write docstrings like you're explaining it to a non-programmer.

5. Creating Custom Tools

Let's build tools for a practical scenario: an assistant that helps with data analysis.

from langchain_core.tools import tool
import json

# Tool 1: Parse CSV-like data
@tool
def parse_csv_data(data_str: str) -> str:
    """Parse a CSV string into structured data.

    Args:
        data_str: CSV data as a string (comma-separated values)

    Returns JSON representation of the data with column headers and rows.

    Example: If given "name,age\nAlice,30\nBob,25", returns a JSON array.

    Use this when you need to work with CSV data."""
    try:
        lines = data_str.strip().split('\n')
        headers = lines[0].split(',')
        rows = []
        for line in lines[1:]:
            values = line.split(',')
            row = {headers[i]: values[i] for i in range(len(headers))}
            rows.append(row)
        return json.dumps(rows, indent=2)
    except Exception as e:
        return f"Error parsing CSV: {e}"

# Tool 2: Calculate statistics
@tool
def calculate_statistics(numbers_str: str) -> str:
    """Calculate basic statistics (mean, median, std dev, min, max) from a list of numbers.

    Args:
        numbers_str: Space or comma-separated numbers

    Use this when the user asks for statistics or summary data."""
    import statistics
    try:
        # Handle both space and comma separation
        numbers = [float(x) for x in numbers_str.replace(',', ' ').split()]

        return json.dumps({
            "count": len(numbers),
            "mean": statistics.mean(numbers),
            "median": statistics.median(numbers),
            "stdev": statistics.stdev(numbers) if len(numbers) > 1 else 0,
            "min": min(numbers),
            "max": max(numbers)
        }, indent=2)
    except Exception as e:
        return f"Error calculating statistics: {e}"

# Tool 3: Filter data
@tool
def filter_data(json_data: str, field: str, value: str) -> str:
    """Filter a JSON array by matching a field to a value.

    Args:
        json_data: JSON array as a string
        field: The field name to filter by
        value: The value to match

    Returns JSON array containing only matching rows.

    Example: Filter users by age == 30."""
    try:
        data = json.loads(json_data)
        filtered = [row for row in data if str(row.get(field)) == value]
        return json.dumps(filtered, indent=2)
    except Exception as e:
        return f"Error filtering data: {e}"

# Collect tools for the agent
tools = [parse_csv_data, calculate_statistics, filter_data]

Key principles for custom tools:

Docstrings are your API contract — the model only sees the name and docstring, not the code
Keep it simple — tools should do one thing well, not be mini-applications
Handle errors gracefully — return meaningful error messages, not stack traces
Test independently — before adding a tool to an agent, verify it works standalone
Type hints matter — they become part of the tool schema the model sees

6. Tool Binding and Calling

This is where it gets interesting. How does the model know to call a tool? And how do we actually invoke it?

LangChain uses the function calling capability of modern LLMs. Here's the flow:

You give the model a set of tools
The user asks a question
The model sees the user's request and the list of available tools
The model decides: "I should call tool X with these parameters"
LangChain intercepts that decision and actually calls the tool
The result goes back to the model
The model generates a response based on the tool result

Let's see it in action:

from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langchain.tools.render import format_tool_to_openai_function_calls

model = ChatOpenAI(model="gpt-4")

@tool
def multiply(a: int, b: int) -> int:
    """Multiply two numbers together."""
    return a * b

@tool
def add(a: int, b: int) -> int:
    """Add two numbers together."""
    return a + b

tools = [multiply, add]

# Bind tools to the model
# This tells the model: "You have these tools available, and here's how to request them"
model_with_tools = model.bind_tools(tools)

# When we invoke it, the model returns a message with a "tool_call" in it
response = model_with_tools.invoke("What is 5 times 3, plus 7?")

print("Response:", response)
print("Tool calls:", response.tool_calls)

# The response includes:
# - .content: The text response
# - .tool_calls: A list of tool invocations the model decided to make
# Example tool_call:
# {
#     "name": "multiply",
#     "args": {"a": 5, "b": 3},
#     "id": "call_123"
# }

The key moment: when you call invoke(), the model returns immediately with its tool decisions. It doesn't execute the tools. That's your job (or the agent loop's job, which we'll see next).

The model is saying: "Here's what I want to do next." You (the programmer) decide whether to actually do it, error-check it, or modify it based on human feedback.

7. The Agent Loop: Manual Construction

An agent loop is how you handle the back-and-forth between the model and tools. The model decides to call a tool, you execute it, you feed the result back to the model, and repeat until the model says "done."

Here's a manual agent loop — this is the essence of what higher-level abstractions hide:

from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langchain_core.messages import HumanMessage, ToolMessage, AIMessage

# Define tools
@tool
def search_knowledge_base(query: str) -> str:
    """Search the company knowledge base for information.

    Args:
        query: A search query

    Returns relevant documents."""
    # Mock implementation
    if "python" in query.lower():
        return "Document 1: Python Best Practices\nDocument 2: Python Performance Tips"
    return "No documents found"

@tool
def fetch_docs(doc_id: str) -> str:
    """Fetch the full content of a document by ID.

    Args:
        doc_id: The document identifier

    Returns the full document content."""
    docs = {
        "doc1": "Python is a high-level language...",
        "doc2": "Use list comprehensions for performance...",
    }
    return docs.get(doc_id, "Document not found")

tools = [search_knowledge_base, fetch_docs]
model = ChatOpenAI(model="gpt-4")
model_with_tools = model.bind_tools(tools)

# The agent loop
def run_agent_loop(user_input: str, max_iterations: int = 10):
    """
    Run the agent loop until the model stops requesting tools.

    This manually handles:
    - Sending user input to the model
    - Detecting tool calls in the response
    - Executing tools
    - Feeding results back to the model
    - Looping until the model says "done"
    """

    # Start with the user's message
    messages = [HumanMessage(content=user_input)]

    for i in range(max_iterations):
        # Get the model's response (might include tool calls)
        response = model_with_tools.invoke(messages)

        # If the model didn't request any tools, it's done
        if not response.tool_calls:
            return response.content

        # Add the model's response to the message history
        # This is important: the model needs to see its own reasoning
        messages.append(AIMessage(content=response.content, tool_calls=response.tool_calls))

        # Execute each tool call the model requested
        for tool_call in response.tool_calls:
            tool_name = tool_call['name']
            tool_args = tool_call['args']

            # Find the tool and execute it
            tool = next((t for t in tools if t.name == tool_name), None)
            if not tool:
                result = "Error: Tool not found"
            else:
                result = tool.invoke(tool_args)

            # Add the tool result to the message history
            # The model will see what the tool returned
            messages.append(ToolMessage(
                content=result,
                tool_call_id=tool_call['id']
            ))

        print(f"[Iteration {i+1}] Agent decided to call tools. Processing...")

    return "Max iterations reached"

# Run it
result = run_agent_loop("I need to learn about Python performance optimization")
print("Final answer:", result)

Here's what's happening:

Initial input: User message goes into the message list
Model invocation: Call the model with all messages so far
Tool decision: Check if the model decided to use any tools
Tool execution: Actually run the tools and capture results
Feedback loop: Add tool results back to messages so the model sees what happened
Repeat: Next iteration, the model has full context including previous tool results

The message history is the key. Each iteration, you're building a transcript:

Human: [question]
AI: I'll search for information... [tool_call: search]
Tool: [search result]
AI: Now I'll fetch the full document... [tool_call: fetch]
Tool: [document content]
AI: Based on the documents, here's what I found...

This manual loop teaches you what's happening. In production, you'll use LangChain's AgentExecutor or create_agent, which handles this looping for you. But understanding the manual loop is critical — it's where bugs appear, where you need human-in-the-loop intervention, and where you can add monitoring.

8. Integrating Real APIs: A Complete Weather Agent

Let's build something practical: a weather agent that can:

Check current weather in a city
Get a forecast
Suggest activities based on weather

from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
import requests
import json

# Real API tools using OpenWeatherMap API
@tool
def get_current_weather(city: str) -> str:
    """Get the current weather for a city.

    Args:
        city: The city name (e.g., 'London', 'Tokyo')

    Returns weather information including temperature, conditions, and humidity.

    Use this when the user asks about current weather."""
    try:
        # In production, use your actual API key
        api_key = "YOUR_OPENWEATHER_API_KEY"
        url = f"https://api.openweathermap.org/data/2.5/weather?q={city}&appid={api_key}&units=metric"

        response = requests.get(url, timeout=5)
        response.raise_for_status()
        data = response.json()

        return json.dumps({
            "city": data.get('name'),
            "temp": data['main']['temp'],
            "feels_like": data['main']['feels_like'],
            "condition": data['weather'][0]['main'],
            "humidity": data['main']['humidity'],
            "wind_speed": data['wind']['speed']
        })
    except requests.RequestException as e:
        return f"Error fetching weather: {e}"

@tool
def get_weather_forecast(city: str, days: int = 3) -> str:
    """Get weather forecast for a city.

    Args:
        city: The city name
        days: Number of days to forecast (1-5)

    Returns forecast data."""
    try:
        api_key = "YOUR_OPENWEATHER_API_KEY"
        # Using free tier endpoint
        url = f"https://api.openweathermap.org/data/2.5/forecast?q={city}&appid={api_key}&units=metric"
        response = requests.get(url, timeout=5)
        response.raise_for_status()
        data = response.json()

        # Parse into forecast summary
        forecasts = []
        for item in data['list'][::8]:  # Every 8 entries = ~1 day
            forecasts.append({
                "time": item['dt_txt'],
                "temp": item['main']['temp'],
                "condition": item['weather'][0]['main']
            })

        return json.dumps(forecasts[:days])
    except requests.RequestException as e:
        return f"Error fetching forecast: {e}"

@tool
def suggest_activity(weather_condition: str, temperature: float) -> str:
    """Suggest activities based on weather conditions.

    Args:
        weather_condition: Weather type (e.g., 'Sunny', 'Rainy', 'Cloudy')
        temperature: Temperature in Celsius

    Returns activity suggestions appropriate for the weather."""
    suggestions = {
        "Sunny": {
            "hot": "🏖️ Beach, outdoor sports, cycling",
            "warm": "⛳ Golf, hiking, picnic",
            "cool": "🚴 Jogging, sightseeing"
        },
        "Rainy": {
            "hot": "🎬 Indoor activities, museum, shopping",
            "warm": "📚 Reading, indoor sports",
            "cool": "☕ Cozy cafes, bookstores"
        },
        "Cloudy": {
            "hot": "🎮 Outdoor games, park",
            "warm": "🎨 Photography, exploring",
            "cool": "🥾 Hiking, nature walks"
        }
    }

    # Categorize temperature
    temp_cat = "hot" if temperature > 25 else ("warm" if temperature > 15 else "cool")
    weather_suggestions = suggestions.get(weather_condition, suggestions["Cloudy"])

    return weather_suggestions.get(temp_cat, "Indoor activities recommended")

tools = [get_current_weather, get_weather_forecast, suggest_activity]

Now let's build the agent:

from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, ToolMessage, AIMessage

model = ChatOpenAI(model="gpt-4")
model_with_tools = model.bind_tools(tools)

def run_weather_agent(user_input: str, max_iterations: int = 10):
    """Run the weather agent loop."""
    messages = [HumanMessage(content=user_input)]

    for iteration in range(max_iterations):
        response = model_with_tools.invoke(messages)

        # If no tool calls, the model is done
        if not response.tool_calls:
            print(f"\n✅ Agent response:\n{response.content}")
            return response.content

        # Add model's message with tool calls
        messages.append(AIMessage(content=response.content, tool_calls=response.tool_calls))

        # Execute each tool
        for tool_call in response.tool_calls:
            tool_name = tool_call['name']
            tool_args = tool_call['args']

            tool = next((t for t in tools if t.name == tool_name), None)
            if tool:
                print(f"\n🔧 Calling {tool_name} with {tool_args}")
                result = tool.invoke(tool_args)
                print(f"📊 Result: {result[:100]}...")  # Truncate for readability
            else:
                result = "Error: Tool not found"

            messages.append(ToolMessage(
                content=result,
                tool_call_id=tool_call['id']
            ))

    return "Max iterations reached"

# Use it
run_weather_agent("What's the weather like in London? And what activities should I do?")

When you run this, here's what happens:

User asks about weather in London
Agent calls get_current_weather("London")
Agent sees the result (sunny, 18°C)
Agent calls suggest_activity("Sunny", 18)
Agent synthesizes everything into a response

The magic: the agent figured out which tools to call and in what order just by understanding the user's request and the tool descriptions.

9. Advanced Patterns: create_agent and Modern LangChain

Manually writing the loop works, but LangChain has abstractions to make this easier. The most practical one is create_agent (or AgentExecutor).

from langchain_openai import ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from langchain_core.tools import tool

# Define your tools (same as before)
@tool
def get_current_weather(city: str) -> str:
    """Get the current weather for a city."""
    # Implementation...
    pass

tools = [get_current_weather]
model = ChatOpenAI(model="gpt-4")

# Create a system prompt
system_prompt = """You are a helpful weather assistant. 
You have access to weather tools that let you look up current conditions,
forecasts, and suggest activities.

When a user asks about weather:
1. Look up the current weather
2. Provide clear, conversational responses
3. If relevant, suggest activities

Always be friendly and practical."""

# Create the prompt template with a placeholder for agent messages
prompt = ChatPromptTemplate.from_messages([
    ("system", system_prompt),
    ("user", "{input}"),
    MessagesPlaceholder(variable_name="agent_scratchpad"),  # Where tool steps go
])

# Create the agent
agent = create_tool_calling_agent(model, tools, prompt)

# Create an executor (this handles the loop for you)
agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    verbose=True,  # Print each step
    max_iterations=10,
    handle_parsing_errors=True
)

# Run it
result = agent_executor.invoke({
    "input": "What's the weather in Tokyo and what should I do?"
})

print(result["output"])

What changed:

Instead of manually writing the loop, AgentExecutor does it for you
You define the tools and a system prompt
create_tool_calling_agent builds the agent for you
You invoke the executor once and it handles all the looping

This is production code. It handles errors, formats outputs, manages context — all the things you'd have to build manually in the loop.

When to use create_agent:

When you want a standard agent that follows tools until it has an answer
When you want LangChain to manage the message history
Most of the time in production

When to use the manual loop:

When you need custom logic (e.g., human approval after each step)
When you need fine-grained control over what happens between tool calls
When debugging why an agent is making bad tool choices

10. Pitfalls and Production Lessons

You've built agents. Now here's what bites you in production.

Pitfall 1: Ambiguous Tool Descriptions

❌ Bad:

@tool
def process_data(input: str) -> str:
    """Process the input data."""
    pass

The model has no idea what this does. It will guess wrong.

✅ Good:

@tool
def calculate_monthly_revenue(year: int, month: int) -> str:
    """Calculate total revenue for a specific month.

    Args:
        year: The year (e.g., 2024)
        month: The month (1-12)

    Returns the revenue as a formatted string with currency.

    Use this when the user asks about revenue, earnings, or sales for a specific month."""
    pass

Every tool call the model makes comes from the docstring. Spend time there.

Pitfall 2: Tools That Fail Silently or Crash

❌ Bad:

@tool
def fetch_user(user_id: int) -> dict:
    """Fetch a user by ID."""
    response = requests.get(f"https://api.example.com/users/{user_id}")
    return response.json()  # What if user_id doesn't exist? What if network fails?

The agent can't handle errors. The whole chain breaks.

✅ Good:

@tool
def fetch_user(user_id: int) -> str:
    """Fetch a user by ID.

    Returns a JSON string with user details or an error message."""
    try:
        response = requests.get(
            f"https://api.example.com/users/{user_id}",
            timeout=5
        )
        response.raise_for_status()
        return json.dumps(response.json())
    except requests.RequestException as e:
        return f"Error fetching user {user_id}: {e}"
    except Exception as e:
        return f"Unexpected error: {e}"

Always return a string (not objects). Always catch errors. Give the model something to work with.

Pitfall 3: Infinite Loops

An agent can loop forever if:

The model keeps requesting the same tool with the same arguments
A tool never gives the model enough information to decide "I'm done"
The model misunderstands what it's supposed to do

Protection:

agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    max_iterations=10,  # Hard cap — without this, you pay forever
    early_stopping_method="force",  # Stop after max_iterations
    handle_parsing_errors=True
)

Pitfall 4: Tool Hallucination

The model might call a tool that doesn't exist or with completely wrong parameters if:

The tool description is vague
Parameter names don't match what the model expects
The model is confused about what tools are available

Protection:

# Be explicit in tool descriptions
@tool
def search_database(
    query: str, 
    table: str,  # Not "table_name" — name your params clearly
    limit: int = 10
) -> str:
    """Search the database for records.

    Args:
        query: The search term (e.g., "email LIKE 'john%'")
        table: The table name ('users', 'products', 'orders')
        limit: Maximum number of results to return (1-100, default 10)

    This tool searches the database directly."""

Pitfall 5: Trusting External APIs Without Timeout

# ❌ This will hang if the API is slow or dead
response = requests.get(url)

# ✅ Always timeout
response = requests.get(url, timeout=5)

When an API hangs, your agent hangs. Your user waits forever.

Pitfall 6: Not Testing Tools Independently

Before you add a tool to an agent, test it in isolation:

# Test the tool by itself first
result = fetch_user.invoke({"user_id": 123})
print(result)

# Verify it handles errors
result = fetch_user.invoke({"user_id": -1})
print(result)

Agent debugging is hard. Single-tool debugging is easy.

Pitfall 7: Token Bloat from Message History

As an agent loops, its message history grows:

User: [question]
AI: [tool call]
Tool: [large result]
AI: [tool call]
Tool: [large result]
...

After 10 iterations with large API responses, you're sending kilobytes of context to the model. This is slow and expensive.

Protection:

# Summarize or truncate tool results
@tool
def fetch_large_dataset(...) -> str:
    data = get_data()
    # Only return the most relevant fields
    summary = {k: v for k, v in data.items() if k in ['id', 'name', 'status']}
    return json.dumps(summary)

Pitfall 8: Not Monitoring What Tools Are Actually Called

Add logging:

def run_agent_with_logging(user_input, tools, model, max_iterations=10):
    messages = [HumanMessage(content=user_input)]

    for iteration in range(max_iterations):
        response = model_with_tools.invoke(messages)

        if not response.tool_calls:
            return response.content

        messages.append(AIMessage(content=response.content, tool_calls=response.tool_calls))

        for tool_call in response.tool_calls:
            # Log what the agent decided
            print(f"[AGENT LOG] Iteration {iteration+1}: Called {tool_call['name']} with {tool_call['args']}")

            # ... execute tool ...

In production, send this to an observability platform (Datadog, New Relic, etc.). You need to see what your agent is doing.

11. Conclusion

You now understand the entire stack:

Runnables are the abstraction that lets you compose operations
Prompts, models, and parsers chain together via the | operator
Tools are how you give agents agency — they describe what the agent can do
Tool binding lets the model request tool execution
Agent loops (manual or automated) handle the back-and-forth between the model and tools
AgentExecutor and create_agent wrap the loop for production use

The mental model is simple: describe tools, describe what you want, let the LLM decide which tools to use, execute those tools, feed results back, repeat.

The complexity comes in production:

Making tool descriptions so clear the model never misunderstands
Handling errors gracefully so one bad tool call doesn't break the chain
Monitoring what the agent actually does
Managing context so you don't waste tokens on massive message histories

Start with a simple agent — weather, calculator, knowledge-base lookup. Test it thoroughly. Only then add the complexity: human-in-the-loop, custom logic between tool calls, streaming responses.

The agents you build today are just the start. Tomorrow, you'll add:

Retrieval-augmented generation (RAG) for smarter context
Memory systems so agents learn from past conversations
Multi-agent systems where agents delegate to each other
Tool-use patterns that don't exist yet

But all of that builds on what you've learned here. Get Runnables in your bones. Understand the loop. Write clear tool descriptions. Test everything. Then build.

The rest is details.

AI Workflow Orchestration: How AI Agents Can Work Like Your Engineering Team

Jack Pritom Soren — Fri, 14 Aug 2026 05:03:53 +0000

Imagine you are a beginner developer.

You have been asked to build a new feature:

“Add authentication to the application.”

You open your AI coding agent, give it the instruction, and a few moments later it changes ten files.

The code works.

But then you start asking yourself:

Why did it change these files?
Why did it choose this architecture?
Why is authentication implemented this way?
What happens if the database fails?
Is there a security problem?
Will this work when the application grows?

This is one of the biggest problems with AI coding tools.

The AI can generate code very quickly, but writing code is only one part of software engineering.

A senior engineer does much more than coding.

Before implementation, they think about requirements, architecture, failure cases, security, performance, testing, and maintainability.

So instead of using AI as a simple code generator, we can design a workflow where different AI agents perform different engineering responsibilities.

This idea is called AI Workflow Orchestration.

What Is AI Workflow Orchestration?

First, we need to understand the difference between an AI agent and an AI workflow.

A simple AI coding agent looks like this:

User Request
     ↓
    AI
     ↓
   Code

You give the AI a task, and it writes the implementation.

But real software engineering looks more like this:

Requirement
    ↓
Architecture
    ↓
Planning
    ↓
Implementation
    ↓
Testing
    ↓
Security Review
    ↓
Performance Review
    ↓
Code Review
    ↓
Production Review

The idea behind orchestration is simple:

Instead of asking one AI to do everything, give different responsibilities to different agents and create a process connecting them.

This is similar to how a real engineering team works.

Meet ELOS

A useful way to organize this workflow is the Engineering Learning Operating System, or ELOS.

The idea is not to replace the developer with AI.

Instead, AI acts like a virtual engineering team.

You can think of different agents as different roles:

Product Manager
Software Architect
Tech Lead
Backend Engineer
Code Reviewer
Security Engineer
Performance Engineer
QA Engineer
DevOps Engineer
Engineering Mentor

In a real company, these responsibilities may belong to different people.

In an AI workflow, they can be represented by different agents.

But there is one rule that should never change:

AI can help make engineering decisions, but the developer must understand and approve them.

The goal is not simply to produce code.

The goal is to help the developer learn how the code and architecture work.

1. Start With a Mentor Agent

One of the most useful agents for beginners is a Mentor Agent.

Why?

Because a beginner often thinks:

“What code should I write?”

A senior engineer usually starts with a different question:

“What problem are we actually solving?”

Suppose we are building authentication.

Instead of immediately creating an auth.middleware.ts file, the mentor should first explain the problem.

For example:

A user wants to access:

GET /orders

The backend needs to determine:

Who is making this request?

That leads us to a possible flow:

Client
  ↓
Authentication Middleware
  ↓
Controller
  ↓
Service
  ↓
Repository
  ↓
Database

The mentor can then explain why authentication belongs in middleware, why business logic belongs in the service layer, and why database operations belong in the repository layer.

This changes AI from a coding machine into a learning system.

2. Requirements Agent

Now imagine someone says:

“Add user authentication.”

That sounds simple, but it is not a complete requirement.

There are many questions:

How will users log in?

JWT or session?

Will there be access tokens?

Will there be refresh tokens?

Where will tokens be stored?

What happens when a token expires?

What happens with an invalid token?

How will logout work?

Will multiple devices be supported?

Do we need authorization?

A Requirements Agent turns this vague request into something structured.

For example:

Feature:
JWT Authentication

Inputs:
email
password

Outputs:
accessToken
refreshToken

Failure Cases:
invalid credentials
expired token
malformed token
inactive user

Security:
password hashing
token validation
rate limiting

Now the architecture agent has a much clearer problem to solve.

3. Architect Agent

The Architect Agent asks a different question:

“How should this system be designed?”

Instead of immediately writing code, it might propose:

Route
  ↓
Middleware
  ↓
Controller
  ↓
Service
  ↓
Repository
  ↓
Database

Then it should explain the responsibility of each layer.

It can also compare different approaches.

For example:

Option A

Put authentication logic directly inside controllers.

Option B

Create reusable authentication middleware.

Then compare them:

Controller Approach
       ↓
Potential duplication
       ↓
Harder testing
       ↓
Harder maintenance

versus:

Middleware
    ↓
Reusable
    ↓
Centralized
    ↓
Easier testing

The important lesson is that architecture is not just about choosing a pattern.

It is about understanding why one approach is better for a specific problem.

4. Architecture Validator

Here is an important improvement.

Even if the Architect Agent proposes a design, we should not automatically assume the design is correct.

So we introduce an Architecture Validator.

Its job is to challenge the proposed architecture.

It asks questions such as:

What happens with concurrent requests?

What happens if the database fails?

What happens if Redis becomes unavailable?

Can duplicate operations happen?

Is the endpoint idempotent?

Are there authorization gaps?

Will this scale?

Is there unnecessary coupling?

Is there a simpler design?

Think of the two agents like this:

Architect:
“This is my design.”

Validator:
“Now let me try to break your design.”

That is much closer to a real engineering review process.

5. Planner Agent

Once the architecture is approved, we need to turn it into implementation steps.

That is the job of the Planner Agent.

For example:

Step 1
Create JWT service

Step 2
Create authentication middleware

Step 3
Protect required routes

Step 4
Update user repository

Step 5
Add tests

Step 6
Run validation

But there is one important detail.

The planner should also explain why each file needs to change.

For example:

auth.service.ts
→ Business logic

auth.middleware.ts
→ Request authentication

jwt.service.ts
→ Token operations

user.repository.ts
→ Database access

auth.test.ts
→ Behavior verification

Now the developer can see the implementation map before any code is written.

6. Implementation Agent

Only now do we start coding.

The Implementation Agent can handle the actual code changes.

But we should give it an important rule:

Do not casually change the approved architecture.

Suppose the agent discovers a problem during implementation.

It should not silently change the design.

Instead, it can report:

BLOCKED

The current architecture does not support X.

Recommended change:
...

Reason:
...

Impact:
...

Then the architecture can be reviewed again.

This prevents a common AI coding problem:

The AI starts with one plan and quietly changes the architecture while implementing.

7. Failure Agent: Try to Break the Code

Now we reach one of the most interesting parts.

The implementation is finished.

A normal coding workflow might say:

“Done.”

But production engineering does not stop there.

We introduce a Failure Agent.

Its job is simple:

Find ways the implementation could fail.

Imagine we are building a payment system.

The Failure Agent might ask:

What if the user clicks Pay twice?

What if the network times out?

What if payment succeeds but the database update fails?

What if a webhook arrives twice?

What if two workers process the same event?

What if Redis goes down?

What if the database transaction fails?

For example:

Scenario:
User clicks Pay twice.

Expected:
Only one charge.

Potential Problem:
Two payment requests are processed independently.

Possible Solution:
Idempotency key.

The agent is not just reviewing the code.

It is trying to break the system mentally.

8. Parallel Review Agents

After implementation, different agents can inspect the same feature from different perspectives.

For example:

                Implementation
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
      Security    Performance      QA
          │           │           │
          └───────────┼───────────┘
                      ▼
                 Code Review

Security Agent

Looks for things like:

Authentication bugs
Authorization bugs
Injection
Sensitive data exposure
Weak validation
Secrets
Rate limiting problems

Performance Agent

Looks for:

N+1 queries
Missing indexes
Unnecessary API calls
Large payloads
Slow queries
Memory issues
Unnecessary loops
Caching opportunities

QA Agent

Thinks about:

Happy path
Edge cases
Invalid input
Boundary cases
Failure cases
Regression
Concurrency

Code Review Agent

Checks:

Readability
Maintainability
Architecture
Duplication
Complexity
Naming
Tradeoffs

The benefit is simple:

One AI agent may miss something that another perspective catches.

9. Review Aggregator

Now we have another problem.

We may have four reports:

Security Report
Performance Report
QA Report
Code Review

Reading everything manually can become annoying.

So we introduce a Review Aggregator.

It combines all the findings into one prioritized report.

For example:

CRITICAL
1. Authorization vulnerability

HIGH
2. Missing database index

MEDIUM
3. Missing input validation

LOW
4. Naming inconsistency

It can also remove duplicate findings.

Now the developer has one clear review to act on.

10. Automatic Fix and Re-check

Suppose the reviewers identify a missing database index.

The Fix Agent implements the change.

But we should not immediately say:

“Everything is fixed.”

Instead:

Implementation
      ↓
Review
      ↓
Problems Found
      ↓
Fix
      ↓
Re-check

This creates a feedback loop.

If more issues remain:

Fix
 ↓
Review
 ↓
Fix
 ↓
Review

However, we should avoid infinite loops.

For example:

MAX_REVIEW_ITERATIONS = 3

After three automated attempts, human approval becomes necessary.

This gives us an important safety boundary:

Automation can iterate, but humans remain the final gate.

11. Production Review

A feature can pass tests and still fail in production.

That's why we need a Production Review Agent.

It looks beyond the local development environment.

For example:

Logging
Monitoring
Error handling
Database migrations
Rollback
Environment variables
Scaling
Caching
Observability
Deployment
Failure recovery

Imagine your query takes only 5ms locally.

Everything looks perfect.

But production has millions of rows.

Suddenly the same query may behave very differently because production has different:

Data size
Indexes
Concurrency
Network latency
Query plans
CPU
Memory

So:

“Works on localhost” does not automatically mean “works in production.”

12. Reflection Agent

Now comes the most important part for beginners.

Reflection.

The AI should not simply tell you that the feature is complete.

It should ask you to explain it.

For example:

Why is this logic inside the service?

Why is authentication handled by middleware?

What happens during concurrent requests?

What happens if the database fails?

How would you scale this?

What tradeoff did we make?

What would you change six months from now?

This changes the workflow dramatically.

Because now the goal is not:

“Did AI finish the feature?”

The goal becomes:

“Can I explain the feature without depending on AI?”

If you cannot explain it, the feature is not really complete from a learning perspective.

13. Create an Engineering Journal

After every feature, the workflow can generate a small engineering journal.

For example:

Feature

Problem Solved

Architecture

Design Decisions

Tradeoffs

Production Risks

Mistakes Avoided

New Concepts

Knowledge Gaps

Next Topics

Over time, this becomes your personal engineering knowledge base.

Instead of forgetting what you learned after finishing a project, you gradually build a record of your decisions and lessons.

14. But There Is a Hidden Problem: Token Usage

At this point, you might think:

“This sounds great. Let's create 20 agents!”

But there is a problem.

Context and token usage.

Imagine your repository has 500 files.

If every agent receives the entire repository:

Mentor
→ 500 files

Architect
→ 500 files

Planner
→ 500 files

Implementation
→ 500 files

Security
→ 500 files

Performance
→ 500 files

QA
→ 500 files

We are repeatedly sending information that most agents do not need.

This is inefficient and can reduce the quality of the model's attention because relevant information becomes buried inside unnecessary context.

So orchestration is not only about creating agents.

It is also about managing context intelligently.

15. Give Each Agent Only the Context It Needs

One of the easiest optimizations is:

Do not give every agent the entire repository.

For authentication, the Mentor might need:

README
Architecture docs
Relevant auth files
Database schema
API documentation

The Security Agent might need:

Auth middleware
Auth service
User model
Routes
Configuration

The Performance Agent might need:

Relevant queries
Repository
Schema
Indexes
Performance-sensitive services

Each agent receives the minimum useful context.

That makes the workflow both cheaper and cleaner.

16. Pass Artifacts, Not Entire Conversations

Another common mistake is passing one agent's entire conversation to the next agent.

For example:

Mentor Conversation
       ↓
Architect

Architect Conversation
       ↓
Planner

Planner Conversation
       ↓
Implementation

That can waste a lot of context.

Instead, create structured artifacts.

For example:

architecture.md

Containing:

Decision

Components

Data Flow

API Contract

Database Changes

Tradeoffs

Rejected Alternatives

Risks

Now the Planner only needs to read the artifact.

It does not need the entire conversation that created it.

17. Compress Context

Sometimes a conversation becomes very long.

Suppose the Mentor and developer discussed a feature for 20 minutes.

The Planner probably does not need the complete conversation.

A compact summary may be enough:

Feature:
JWT authentication

Requirements:
...

Architecture:
...

Constraints:
...

Decisions:
...

Open Questions:
...

This is called context compression.

The goal is simple:

Keep the information that matters and discard unnecessary conversation history.

18. Use Different Models for Different Tasks

Another optimization is model routing.

Not every task needs the strongest reasoning model.

Conceptually, you could do something like:

Simple classification
        ↓
Small model

Formatting
        ↓
Small model

Test generation
        ↓
Medium model

Architecture
        ↓
Strong reasoning model

Security-critical review
        ↓
Strong model

The important thing is not to blindly choose the cheapest model.

Critical engineering decisions deserve an appropriately capable model.

Cost optimization should never destroy engineering quality.

19. Reuse Stable Project Knowledge

Some project information does not change frequently.

For example:

Coding standards
Architecture principles
Project conventions
Database conventions
API conventions

Instead of explaining these rules in every conversation, store them as reusable project instructions.

For example:

.opencode/

instructions/
    architecture.md
    security.md
    testing.md
    coding-standards.md

Then agents can consistently follow the project's existing rules.

20. Add a Context Manager

As workflows become larger, one more role becomes useful:

Context Manager.

Its job is to decide:

What does this agent actually need?

Which files are relevant?

Which previous decisions matter?

What can be summarized?

What can be discarded?

Think of it as the workflow's context-budget gatekeeper.

Instead of blindly giving every agent everything, it decides what information should actually enter the agent's context.

The Complete Workflow

Now we can put everything together.

                         USER
                           │
                           ▼
                        MENTOR
                           │
                           ▼
                      REQUIREMENTS
                           │
                           ▼
                       ARCHITECT
                           │
                           ▼
                ARCHITECTURE VALIDATOR
                           │
                    ┌──────┴──────┐
                    │             │
                   FAIL          PASS
                    │             │
                    └─── Revise   │
                                  ▼
                               PLANNER
                                  │
                                  ▼
                           CONTEXT MANAGER
                                  │
                                  ▼
                           IMPLEMENTATION
                                  │
                                  ▼
                           FAILURE AGENT
                                  │
                    ┌─────────────┼─────────────┐
                    ▼             ▼             ▼
                SECURITY     PERFORMANCE        QA
                    │             │             │
                    └─────────────┼─────────────┘
                                  ▼
                              CODE REVIEW
                                  │
                                  ▼
                           REVIEW AGGREGATOR
                                  │
                           ┌──────┴──────┐
                           │             │
                          FAIL          PASS
                           │             │
                           ▼             │
                    FIX IMPLEMENTATION  │
                           │             │
                           └──────┐      │
                                  ▼      │
                               RE-CHECK ◄┘
                                  │
                                  ▼
                          PRODUCTION REVIEW
                                  │
                                  ▼
                           HUMAN REVIEW
                                  │
                                  ▼
                              REFLECTION
                                  │
                                  ▼
                          LEARNING SUMMARY
                                  │
                                  ▼
                       ENGINEERING JOURNAL
                                  │
                                  ▼
                                DONE

This is the key idea of ELOS.

The Most Important Rule

After everything we have discussed, one principle matters more than the number of agents.

AI can propose. AI can implement. AI can review. But the engineer must understand and approve.

AI-generated code can look correct.

But:

Looks correct
      ≠
Is correct

That is why the workflow needs a human quality gate.

Ask yourself:

Can I explain this implementation?

If the answer is no:

Don't accept it yet.

If the answer is yes:

Continue.

What Is the Real Goal?

The future of AI-assisted development is not simply:

“AI writes my code.”

A better vision is:

“AI works with me like an engineering team.”

One agent helps understand requirements.

Another designs architecture.

Another challenges the design.

Another implements the feature.

Another tries to break it.

Security checks security.

Performance checks bottlenecks.

QA checks edge cases.

Code review checks maintainability.

Production review checks real-world risks.

And finally, the AI asks you:

“Do you actually understand what we built?”

That is the difference between using AI to generate code and using AI to become a better engineer.

Final Thought

AI should not make you dependent on generated code.

It should make you better at:

thinking, designing, reviewing, debugging, and making engineering decisions.

The ultimate goal is not to build a system where AI can code without you.

The ultimate goal is to build a system where, over time, you become capable of making senior-level engineering decisions yourself.

That is the real purpose of an Engineering Learning Operating System.

RAG Explained: How to Give Your LLM a Memory It Can Actually Trust

Jack Pritom Soren — Sat, 25 Jul 2026 13:12:35 +0000

You're building a chatbot for a company's internal documentation — hundreds of pages of engineering specs, HR policies, product guides. You plug in ChatGPT, write a clean system prompt,launch a demo. Someone asks "What's the reimbursement limit for travel expenses?" and the model confidently answers with a number. The number is wrong. It's not from your docs — it's from the model's general training data, some pattern absorbed from the internet years ago that roughly sounds like a reasonable reimbursement policy.

This is the fundamental problem with raw LLMs in production: they don't know your data. They know what was in their training set — a snapshot of text from months or years ago, with no awareness of your internal docs, your product specs, your latest pricing, your customer records, or anything else that lives inside your organization. And when they don't know something, they don't say "I don't know" — they say something plausible-sounding that might be completely fabricated.

The fix has a name: Retrieval-Augmented Generation, almost universally abbreviated as RAG. The idea is elegant: before asking the model to answer a question, find the relevant pieces of your actual data and hand them to the model as context. Now, instead of guessing, the model is summarizing and reasoning over the real information you provided.

The gap between "RAG sounds simple" and "RAG actually works reliably in production" is where most teams spend weeks of engineering time. Understanding the full pipeline — every
stage, every design decision, every place it quietly breaks — is what this article is about.

What We'll Cover

The RAG Mental Model — Why It Works at All
The Full RAG Development Pipeline (Both Phases)
Document Loaders — Getting Your Data In
Text Splitting and Chunking — The Stage Everyone Underestimates
Embeddings and Vector Stores — Where Your Data Lives at Query Time
Retrievers — Finding the Right Chunks When It Matters
Putting It All Together — A Working RAG Chain
Where RAG Breaks and How to Diagnose It

Chapter 1: The RAG Mental Model — Why It Works at All

Before code, you need the right mental model, because RAG is counterintuitive until it clicks.

Think about how you answer questions as a consultant. If someone asks you a question about a client's contract terms, you don't try to recall everything from memory — you pull up the contract, skim for the relevant section and answer based on what's in front of you. You're not generating from memory; you're reading and summarizing from a source.

RAG turns an LLM into that consultant. You build a system that:

Ingests your documents (PDFs, web pages, databases, whatever) and stores them in a searchable format.
When a user asks a question, retrieves the most relevant pieces of those documents.
Augments the model's prompt with those retrieved pieces.
Lets the model generate an answer based on the context you just handed it. The LLM's role shifts from "know everything" to "read what I gave you and reason over it." That's a job LLMs are genuinely very good at.

Without RAG:
User question  →  LLM (guesses from training data)  →  Response (possibly hallucinated)

With RAG:
User question  →  Retrieve relevant docs  →  LLM (reads your actual docs)  →  Grounded response

This is why RAG is the dominant pattern for enterprise AI applications. It doesn't eliminate the LLM's tendency to hallucinate — but it gives the model true ground to stand on,and makes it much easier to audit: if the answer is wrong, you can trace it back to exactly which chunk was retrieved and why.

The full pipeline has two distinct phases that most beginners conflate into one. Let's separate them.

Chapter 2: The Full RAG Development Pipeline — Two Phases

Almost every RAG confusion I've seen in teams comes from mixing up what happens before a user ever sends a message versus what happens when they do. These are two fundamentally different processes with different triggers, different costs, and different failure modes.

Phase 1 — Indexing (Offline, Runs Once)

This is the preparation phase. You run it ahead of time — sometimes once, sometimes on a schedule, sometimes triggered by new document uploads. It does not happen in response to user queries.

[ Your Raw Documents ]
        │
        ▼
[ Document Loader ]      ← Pull documents in from wherever they live
        │
        ▼
[ Text Splitter ]        ← Break documents into manageable chunks
        │
        ▼
[ Embedding Model ]      ← Convert each chunk into a numeric vector
        │
        ▼
[ Vector Store ]         ← Store vectors + original text in a searchable database

The result: a vector store that contains your entire knowledge base in a format where "find me content similar to this question" is a fast, cheap operation.

Phase 2 — Retrieval + Generation (Online, Runs Per Query)

This is the live path. It runs every time a user sends a message.

[ User Question ]
        │
        ▼
[ Embedding Model ]      ← Convert the question into a vector
        │
        ▼
[ Vector Store Retriever ]  ← Find the chunks most similar to the question
        │
        ▼
[ Prompt Template ]      ← Inject retrieved chunks + question into a prompt
        │
        ▼
[ LLM ]                  ← Generates answer grounded in the retrieved context
        │
        ▼
[ Response to User ]

These two phases have completely different performance characteristics. Indexing is slow and expensive per document but runs offline. Retrieval + generation must be fast — it's the live user experience. Every design decision in RAG falls into one of these two phases. Keep this separation in mind as we go through each component.

Chapter 3: Document Loaders — Getting Your Data In

The first problem in any real RAG system is always the same: your data doesn't live in a clean text file. It lives in PDFs, Word documents, Notion pages, Confluence wikis,Google Drive folders, databases, Slack threads, web pages, and half a dozen other formats
— each requiring different handling to extract usable text.

Document loaders in LangChain are the abstraction that handles this — they give you a consistent load() interface regardless of the source, returning a list of Document objects (each containing a page_content string and a metadata dict).

from langchain_community.document_loaders import (
    PyPDFLoader,         # PDFs — extracts text page by page
    WebBaseLoader,       # Web pages — fetches and strips HTML
    TextLoader,          # Plain .txt files
    CSVLoader,           # Spreadsheets — each row becomes a Document
    UnstructuredWordDocumentLoader,  # .docx files
    NotionDirectoryLoader,           # Exported Notion workspace
)

# Every loader shares the same interface — .load() returns List[Document]

# Load a PDF — returns one Document per page, with page number in metadata
pdf_loader = PyPDFLoader("engineering_spec.pdf")
pdf_docs = pdf_loader.load()
# pdf_docs[0].page_content → "Chapter 1: System Architecture..."
# pdf_docs[0].metadata     → {"source": "engineering_spec.pdf", "page": 0}

# Load a web page — strips HTML, extracts main text content
web_loader = WebBaseLoader("https://docs.mycompany.com/api-reference")
web_docs = web_loader.load()

# Load a CSV — useful for structured data like FAQs or product catalogs
csv_loader = CSVLoader("product_faq.csv", source_column="url")
csv_docs = csv_loader.load()

The metadata dict is not an afterthought — it's critical for production systems. Every document you ingest should carry metadata: its source URL, file name, creation date, author, document type, whatever is relevant. You'll use this metadata later for filtering ("only retrieve from documents tagged HR policy") and for citations in your responses ("according to engineering_spec.pdf, page 12").

# Always inspect what your loader actually produced before moving on.
# Loaders fail silently in surprising ways — PDFs with scanned images return empty
# page_content strings; HTML with JavaScript-rendered content may come back blank.
for doc in pdf_docs[:3]:
    print(f"Content length: {len(doc.page_content)} chars")
    print(f"Metadata: {doc.metadata}")
    print(f"Preview: {doc.page_content[:200]}")
    print("---")

⚠️ Heads up: PDFs are the most common source and the most problematic. Scanned PDFs
(images of text rather than actual text) will return empty strings with most loaders —
you'll need OCR processing before the text is even extractable. Always validate that
your loader is actually getting text, not silence.

Chapter 4: Text Splitting and Chunking — The Stage Everyone Underestimates

Here's where most RAG beginners make their biggest architectural mistake, because this stage looks trivial and isn't.

You have your documents loaded. They might be entire 80-page PDFs or multi-thousand-word web pages. You can't stuff all of that into a prompt — LLMs have context limits, and even if you could, you don't want to. You want to retrieve the specific relevant section, not an entire document.

So you split documents into chunks — smaller pieces of text that can be independently retrieved and included in a prompt. The decisions you make here — how big each chunk is, how they overlap, how they respect the document's natural structure — have a bigger impact on RAG quality than almost any other single variable.

Chunk Size: The Core Trade-off

This is a genuine tension with no universal right answer:

Too small (e.g., 100 tokens): Each chunk has very little context. You might retrieve a sentence that perfectly matches the query but doesn't contain enough surrounding information to answer it meaningfully. The model gets fragments.
Too large (e.g., 2000 tokens): Each chunk contains more context, but semantic similarity search becomes less precise — a chunk about three different topics might score as a moderate match for many queries rather than a strong match for any. You also use more of your LLM's context window per retrieved chunk.
Sweet spot in practice: 200–500 tokens per chunk for most knowledge-base use cases, with experimentation required for your specific content type and query patterns.

Chunk Overlap: Handling Boundary Problems

When you split at token/character boundaries, you'll slice through sentences, sometimes mid-thought. The sentence that contains the key information might end up half in chunk 12 and half in chunk 13, and neither chunk retrieves well. Overlap addresses this by
repeating the last N tokens of each chunk at the start of the next.

from langchain.text_splitter import RecursiveCharacterTextSplitter

# The workhorse of LangChain splitting — tries to split on natural boundaries
# first (paragraphs → sentences → words) before falling back to raw characters.
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,      # Target max characters per chunk
    chunk_overlap=50,    # Last 50 chars of chunk N repeated at start of chunk N+1
    separators=["\n\n", "\n", ". ", " ", ""]  # Try these in order
)

chunks = splitter.split_documents(pdf_docs)

print(f"Original: {len(pdf_docs)} pages")
print(f"After splitting: {len(chunks)} chunks")

# Good habit: sanity-check your chunks before continuing
for i, chunk in enumerate(chunks[:3]):
    print(f"\n--- Chunk {i} ({len(chunk.page_content)} chars) ---")
    print(chunk.page_content)

Splitting Strategies: Not All Text Is Flat Prose

RecursiveCharacterTextSplitter is the general-purpose default, but different content
types benefit from different strategies:

from langchain.text_splitter import (
    RecursiveCharacterTextSplitter,   # General prose — paragraphs, articles, docs
    MarkdownHeaderTextSplitter,       # Markdown — splits on headings, preserves structure
    Language,                         # Code — splits on functions/classes, not mid-line
)

# For technical documentation in Markdown — splits on headers rather than character count
md_splitter = MarkdownHeaderTextSplitter(
    headers_to_split_on=[
        ("#", "h1"),
        ("##", "h2"),
        ("###", "h3"),
    ]
)
# Each resulting chunk carries header metadata — great for citations later

# For code repositories — respects function/class boundaries
code_splitter = RecursiveCharacterTextSplitter.from_language(
    language=Language.PYTHON,
    chunk_size=1000,
    chunk_overlap=100,
)

💡 Pro tip: Add the source metadata to every chunk explicitly — once you've split
200 documents into 5,000 chunks, you need to know which chunk came from where.
LangChain's splitters preserve metadata from the parent Document, but always verify.

Chapter 5: Embeddings and Vector Stores — Where Your Data Lives

You now have thousands of text chunks. The next problem: how do you find the chunks relevant to a specific user question, fast, at query time?

The answer is semantic search, and it works through embeddings.

What Embeddings Actually Are

Remember from the first article: each chunk of text can be converted into a vector — a list of hundreds or thousands of numbers — that represents its meaning in mathematical space. This conversion is done by an embedding model (a different, smaller model than your LLM — its only job is text → vector).

The key property: semantically similar text produces mathematically similar vectors. "How do I reset my password?" and "Steps to change my account credentials" are worded completely differently but mean similar things — their embedding vectors will be close together in vector space, close enough to find each other via similarity search.

This is why RAG can retrieve relevant content even when the user's question uses completely different words from your documentation. You're not searching for matching keywords; you're searching for matching meaning.

from langchain_openai import OpenAIEmbeddings
from langchain_community.embeddings import HuggingFaceEmbeddings

# OpenAI's embedding model — cloud API, very good quality
openai_embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# Or a local HuggingFace model — free, runs on your hardware, great for cost-sensitive
# or privacy-sensitive use cases (your documents never leave your infrastructure) local_embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")

# What actually happens under the hood (you usually don't call this directly):
vector = openai_embeddings.embed_query("How do I reset my password?")
# vector is a list of ~1500 floats — the "meaning fingerprint" of that sentence print(f"Vector dimensions: {len(vector)}")  # e.g., 1536 for text-embedding-3-small

Vector Stores

Embeddings are only useful if you can search through them efficiently. A vector store is a database built for this — you insert vectors + their associated text, and at query time you give it a query vector and it returns the N most similar stored vectors.

from langchain_community.vectorstores import (
    FAISS,       # Facebook AI Similarity Search — in-memory, great for dev/small scale
    Chroma,      # Lightweight persistent vector store — good for local development
    Pinecone,    # Managed cloud vector database — production scale
    Weaviate,    # Open-source cloud/self-hosted — good for complex filtering
    pgvector,    # Postgres extension — great if you're already on Postgres
)

# Building a FAISS vector store from chunks — this runs your embedding model
# on every chunk and stores the result. This is the slow, expensive indexing step. 
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings()

# This call: embeds every chunk + builds the search index
vectorstore = FAISS.from_documents(
    documents=chunks,      # Your split documents from Chapter 4
    embedding=embeddings   # The model that converts text → vector
)

# Persist to disk so you don't re-embed every time your app restarts
vectorstore.save_local("my_knowledge_base")

# Load it back later — no re-embedding needed
vectorstore = FAISS.load_local("my_knowledge_base", embeddings,
                                allow_dangerous_deserialization=True)

⚠️ Heads up: Embedding your entire document set costs money and takes time —
OpenAI's embedding API charges per token, and embedding 10,000 chunks can take minutes.
Always persist your vector store to disk (or use a managed service) so the indexing
phase runs once, not on every app restart.

Chapter 6: Retrievers — Finding the Right Chunks When It Matters

A retriever is the interface that sits in front of your vector store and answers one question: given this query, what chunks should I surface? It's what Phase 2 of the pipeline calls when a user sends a message.

The simplest retriever is just a vector store wrapper:

# The most basic retriever — pure semantic similarity search
retriever = vectorstore.as_retriever(
    search_type="similarity",   # Find the N most semantically similar chunks
    search_kwargs={"k": 4}      # Return the top 4 chunks
)

# Test it — this is what runs at query time:
relevant_chunks = retriever.invoke("What is the reimbursement limit for travel?")
for chunk in relevant_chunks:
    print(chunk.page_content[:300])
    print(f"Source: {chunk.metadata.get('source', 'unknown')}")
    print("---")

But "top 4 by similarity" is actually a pretty naive strategy, and there are several retrieval approaches that meaningfully improve quality in practice.

MMR — Maximum Marginal Relevance

Pure similarity search has a hidden flaw: if your knowledge base has five paragraphs that all say the same thing slightly differently, you'll retrieve all five of them instead of
getting diverse, complementary information. MMR trades off between relevance (is this chunk similar to the query?) and diversity (is this chunk different from what I've already retrieved?).

retriever = vectorstore.as_retriever(
    search_type="mmr",          # Maximum Marginal Relevance
    search_kwargs={
        "k": 4,                  # Return 4 chunks
        "fetch_k": 20,           # Consider top 20 by similarity first
        "lambda_mult": 0.7       # 0 = pure diversity, 1 = pure similarity
    }
)

Similarity Score Threshold

Don't retrieve bad chunks just to hit your k target. If nothing in your knowledge base is actually relevant to the query, it's better to return nothing than to return vaguely-related content that confuses the model.

retriever = vectorstore.as_retriever(
    search_type="similarity_score_threshold",
    search_kwargs={
        "score_threshold": 0.7,  # Only return chunks above this similarity score
        "k": 4
    }
)

Metadata Filtering

Vector search finds semantically similar content, but sometimes you need to constrain which documents are even eligible — only search HR policies, or only search documents updated in the last 30 days, or only search content in English. This is where metadata filters come in.

retriever = vectorstore.as_retriever(
    search_kwargs={
        "k": 4,
        "filter": {"department": "HR", "document_type": "policy"}
        # Only consider chunks where metadata matches these conditions
    }
)

Multi-Query Retrieval

One underrated technique: the user's question, as phrased, might not be the best query for semantic search. Multi-query retrieval uses the LLM itself to generate multiple alternative phrasings of the question, runs all of them as separate queries, and takes the union of results. This catches relevant chunks that a single query might miss due to phrasing mismatches.

from langchain.retrievers import MultiQueryRetriever
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(temperature=0)

multi_retriever = MultiQueryRetriever.from_llm(
    retriever=vectorstore.as_retriever(search_kwargs={"k": 3}),
    llm=llm
    # Under the hood: generates 3-5 alternative phrasings of the query,
    # retrieves for each, deduplicates results
)

Chapter 7: Putting It All Together — A Working RAG Chain

Here's a complete, minimal, working RAG chain using LangChain's modern interface. This is the skeleton of nearly every document Q&A system you'll ever build.

from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

# ─── PHASE 1: INDEXING (run once, offline) ───────────────────────────────────

# 1. Load documents
loader = PyPDFLoader("company_handbook.pdf")
raw_docs = loader.load()

# 2. Split into chunks
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(raw_docs)

# 3. Embed and store
embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(chunks, embeddings)
vectorstore.save_local("handbook_index")

# ─── PHASE 2: RETRIEVAL + GENERATION (runs per query) ────────────────────────

# Load the pre-built index (skip re-embedding)
vectorstore = FAISS.load_local("handbook_index", embeddings,
                                allow_dangerous_deserialization=True)

retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

# The prompt that instructs the model to answer ONLY from retrieved context
rag_prompt = ChatPromptTemplate.from_messages([
    ("system",
     "You are a helpful assistant answering questions about company policy. "
     "Use ONLY the following retrieved context to answer the question. "
     "If the answer is not in the context, say: 'I don't have that information.' "
     "Do not use any knowledge outside of what's provided below.\n\n"
     "Context:\n{context}"),
    ("user", "{question}")
])

llm = ChatOpenAI(model="gpt-4o", temperature=0)  # temp=0 for consistent, factual answers

def format_docs(docs):
    # Combine retrieved chunks into a single context string
    return "\n\n".join(
        f"[Source: {doc.metadata.get('source', 'unknown')}, "
        f"Page: {doc.metadata.get('page', '?')}]\n{doc.page_content}"
        for doc in docs
    )

# Build the chain using LangChain Expression Language (LCEL)
rag_chain = (
    {
        "context": retriever | format_docs,  # retrieve → format as string
        "question": RunnablePassthrough()    # pass question through unchanged
    }
    | rag_prompt         # fill the template
    | llm                # call the model
    | StrOutputParser()  # parse response to plain string
)

# Use it
response = rag_chain.invoke("What is the reimbursement limit for travel expenses?") print(response)
# "According to the handbook, the travel reimbursement limit is $350 per night
#  for hotels and $75 per day for meals..."

This chain is clean, auditable, and straightforward to swap out individual pieces — change the loader, the splitter settings, the retriever strategy, or the underlying LLM without touching the rest of the pipeline.

Chapter 8: Where RAG Breaks and How to Diagnose It

RAG systems fail in consistent, diagnosable ways. Knowing the failure modes ahead of time saves days of debugging.

"The model ignores the retrieved context and makes things up anyway." Your system prompt isn't firm enough. Add explicit grounding instructions: "Answer only from the context below. If the answer is not in the context, say so." Setting temperature=0
on the LLM also helps with consistency.

"Retrieval returns irrelevant chunks."
This is the most common failure, and it almost always traces to chunking. Chunks are too large (low retrieval precision), too small (not enough context per chunk), or split at bad boundaries (sentences split mid-idea). Try smaller chunks, increase overlap, or switch to a structure-aware splitter (markdown header, code-aware).

"The right information is in the document but retrieval never finds it." Your query phrasing and your document phrasing are too semantically distant. Try the multi-query retriever to cast a wider net. Also check: was this section actually indexed? Loaders silently fail on scanned PDFs, complex tables, and certain layouts.

"The model's answer is correct but I can't trace where it came from." Always include source metadata in your formatted context and instruct the model to cite it. Without attribution, RAG is a black box — with attribution, it's auditable.

"It works in testing but gives bad answers on long documents at scale." Your k value (number of retrieved chunks) is hitting the LLM's context window limit. Either reduce k, reduce chunk size, or use a model with a larger context window. Also check for embedding model mismatch — if you indexed with one embedding model and query with another, the vector space is incompatible.

Where This Takes You Next

You now have a mental model of the complete RAG pipeline from ingestion to response — not just what the pieces are called, but why each one exists and what breaks when it's wrong.

The natural next step is building something real with this. Start with a single clean PDF and a handful of test questions whose correct answers you already know. Run the full pipeline, check whether your retriever surfaces the right chunks for each question, then tune chunk size and overlap until retrieval quality is solid. Get that working before touching retriever strategies or advanced techniques.

Once retrieval is reliable, the rest — getting the model to answer well, adding conversation memory, citing sources — falls into place quickly. The retrieval quality is the foundation. Everything else is downstream from it.

RAG isn't magic. It's plumbing — well-designed plumbing that lets a language model answer questions about your actual data instead of guessing. Build the plumbing carefully, and the magic takes care of itself.

RxJS in Angular — Chapter 10 (Final) | Real-World Patterns, Best Practices & Everything That Actually Matters

Jack Pritom Soren — Wed, 15 Jul 2026 07:38:29 +0000

👋 Welcome to the Final Chapter!

You've made it. 🎉

Over the past 9 chapters, you've learned Observables, subscribe, pipe, map, filter, tap, switchMap, mergeMap, concatMap, Subject, BehaviorSubject, error handling, combining operators, forms, and timing operators.

Now let's put it ALL together. This chapter is about real patterns you'll use every single day in production Angular apps — and the mistakes you must avoid.

🏗️ Pattern 1: The State Service Pattern (Mini State Management)

In large Angular apps, managing shared state is the biggest challenge. You don't always need NgRx — a simple service with BehaviorSubject is often enough.

The Pattern

// feature-state.service.ts
import { Injectable } from '@angular/core';
import { BehaviorSubject, Observable } from 'rxjs';
import { map } from 'rxjs/operators';

// Define the shape of your state
interface ProductState {
  products: Product[];
  selectedProduct: Product | null;
  isLoading: boolean;
  error: string | null;
  filters: {
    category: string;
    maxPrice: number;
    searchTerm: string;
  };
}

// Initial state
const initialState: ProductState = {
  products: [],
  selectedProduct: null,
  isLoading: false,
  error: null,
  filters: {
    category: 'all',
    maxPrice: 999999,
    searchTerm: ''
  }
};

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

  // The one source of truth
  private state$ = new BehaviorSubject<ProductState>(initialState);

  // Derived selectors — computed from state
  products$ = this.state$.pipe(map(s => s.products));
  selectedProduct$ = this.state$.pipe(map(s => s.selectedProduct));
  isLoading$ = this.state$.pipe(map(s => s.isLoading));
  error$ = this.state$.pipe(map(s => s.error));

  // Filtered products — automatically recomputes when state changes
  filteredProducts$ = this.state$.pipe(
    map(state => {
      return state.products
        .filter(p =>
          (state.filters.category === 'all' || p.category === state.filters.category) &&
          p.price <= state.filters.maxPrice &&
          p.name.toLowerCase().includes(state.filters.searchTerm.toLowerCase())
        );
    })
  );

  // State updaters — the only way to change state
  setLoading(isLoading: boolean): void {
    this.updateState({ isLoading });
  }

  setProducts(products: Product[]): void {
    this.updateState({ products, isLoading: false, error: null });
  }

  setError(error: string): void {
    this.updateState({ error, isLoading: false });
  }

  selectProduct(product: Product | null): void {
    this.updateState({ selectedProduct: product });
  }

  updateFilters(filters: Partial<ProductState['filters']>): void {
    const currentFilters = this.state$.value.filters;
    this.updateState({ filters: { ...currentFilters, ...filters } });
  }

  // Private helper — immutable state update
  private updateState(partialState: Partial<ProductState>): void {
    this.state$.next({
      ...this.state$.value,
      ...partialState
    });
  }

  // Synchronous getter for imperative code
  get currentState(): ProductState {
    return this.state$.value;
  }
}

Using the State Service in Components

// product-list.component.ts
@Component({
  template: `
    <div *ngIf="state.isLoading$ | async">Loading... ⏳</div>
    <div *ngIf="state.error$ | async as err" class="error">{{ err }}</div>

    <div *ngFor="let product of state.filteredProducts$ | async">
      <h3>{{ product.name }}</h3>
      <button (click)="state.selectProduct(product)">View</button>
    </div>
  `
})
export class ProductListComponent implements OnInit {

  constructor(
    public state: ProductStateService,
    private productService: ProductService
  ) {}

  ngOnInit(): void {
    this.state.setLoading(true);

    this.productService.getAll().subscribe({
      next: products => this.state.setProducts(products),
      error: err => this.state.setError(err.message)
    });
  }
}

// filter-bar.component.ts
@Component({
  template: `
    <input
      [formControl]="search"
      placeholder="Search...">

    <select [formControl]="category">
      <option value="all">All</option>
      <option value="electronics">Electronics</option>
      <option value="clothing">Clothing</option>
    </select>
  `
})
export class FilterBarComponent implements OnInit, OnDestroy {

  search = new FormControl('');
  category = new FormControl('all');

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

  constructor(private state: ProductStateService) {}

  ngOnInit(): void {
    this.search.valueChanges
      .pipe(debounceTime(300), takeUntil(this.destroy$))
      .subscribe(term => this.state.updateFilters({ searchTerm: term || '' }));

    this.category.valueChanges
      .pipe(takeUntil(this.destroy$))
      .subscribe(cat => this.state.updateFilters({ category: cat || 'all' }));
  }

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

The filter component and the list component are completely decoupled — they communicate through the state service! 🎯

🏗️ Pattern 2: The Smart/Dumb Component Pattern

Smart components manage data and subscriptions.
Dumb components just display data via @Input and emit events via @Output.

// SMART component — manages data
@Component({
  selector: 'app-users-page',
  template: `
    <!-- Pass data DOWN to dumb component via @Input -->
    <app-user-list
      [users]="users$ | async"
      [isLoading]="isLoading$ | async"
      (userSelected)="onUserSelected($event)"
      (deleteRequested)="onDeleteUser($event)">
    </app-user-list>
  `
})
export class UsersPageComponent {
  users$ = this.userService.getUsers();
  isLoading$ = new BehaviorSubject(true);

  constructor(private userService: UserService) {
    this.users$.subscribe(() => this.isLoading$.next(false));
  }

  onUserSelected(user: User): void { ... }
  onDeleteUser(userId: number): void { ... }
}

// DUMB component — only displays, zero knowledge of services
@Component({
  selector: 'app-user-list',
  template: `
    <div *ngIf="isLoading">Loading...</div>
    <div *ngFor="let user of users">
      {{ user.name }}
      <button (click)="userSelected.emit(user)">View</button>
      <button (click)="deleteRequested.emit(user.id)">Delete</button>
    </div>
  `
})
export class UserListComponent {
  @Input() users: User[] | null = [];
  @Input() isLoading: boolean | null = false;
  @Output() userSelected = new EventEmitter<User>();
  @Output() deleteRequested = new EventEmitter<number>();
}

Dumb components are easy to test, reuse, and understand! 💡

🏗️ Pattern 3: The Loading/Error/Success State Pattern

Every page that fetches data should handle 3 states. Here's the cleanest way:

// Shared types
interface AsyncState<T> {
  data: T | null;
  isLoading: boolean;
  error: string | null;
}

// Helper function
function createLoadingState<T>(): AsyncState<T> {
  return { data: null, isLoading: true, error: null };
}

// In your component
@Component({
  template: `
    <ng-container *ngIf="state$ | async as s">

      <app-skeleton *ngIf="s.isLoading"></app-skeleton>

      <app-error-message
        *ngIf="s.error"
        [message]="s.error"
        (retry)="load()">
      </app-error-message>

      <app-product-grid
        *ngIf="s.data && !s.isLoading"
        [products]="s.data">
      </app-product-grid>

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

  state$!: Observable<AsyncState<Product[]>>;

  constructor(private productService: ProductService) {}

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

  load(): void {
    this.state$ = this.productService.getProducts().pipe(
      map(products => ({ data: products, isLoading: false, error: null })),
      catchError(err => of({ data: null, isLoading: false, error: err.message })),
      startWith(createLoadingState<Product[]>())
    );
  }
}

🛑 The Top 10 RxJS Mistakes to Avoid

Mistake 1: Not Unsubscribing

// ❌ Memory leak!
ngOnInit() {
  interval(1000).subscribe(n => console.log(n));
}

// ✅ Proper cleanup
ngOnInit() {
  interval(1000)
    .pipe(takeUntil(this.destroy$))
    .subscribe(n => console.log(n));
}

Mistake 2: Nested Subscribes

// ❌ Never do this — nested subscribes!
this.route.params.subscribe(params => {
  this.userService.getUser(params['id']).subscribe(user => {
    this.user = user;
  });
});

// ✅ Use switchMap
this.route.params.pipe(
  switchMap(params => this.userService.getUser(params['id']))
).subscribe(user => this.user = user);

Mistake 3: Subscribing in Services

// ❌ Bad — subscribing in service creates untraceable subscriptions
@Injectable()
export class UserService {
  loadUsers() {
    this.http.get('/api/users').subscribe(users => {
      this.users = users; // Mutating service state in subscribe!
    });
  }
}

// ✅ Good — return the Observable, let the component decide
@Injectable()
export class UserService {
  getUsers(): Observable<User[]> {
    return this.http.get<User[]>('/api/users');
  }
}

Mistake 4: Forgetting startWith in combineLatest

// ❌ combineLatest won't emit until ALL observables have emitted at least once
combineLatest([
  this.searchControl.valueChanges,  // Won't emit until user types!
  this.categoryControl.valueChanges
])

// ✅ Use startWith so combineLatest fires immediately
combineLatest([
  this.searchControl.valueChanges.pipe(startWith('')),
  this.categoryControl.valueChanges.pipe(startWith('all'))
])

Mistake 5: Using switchMap When You Should Use mergeMap

// ❌ Wrong — switchMap cancels previous file uploads!
from(files).pipe(
  switchMap(file => this.upload(file))  // Each new file cancels the previous upload!
)

// ✅ Correct — mergeMap runs all uploads in parallel
from(files).pipe(
  mergeMap(file => this.upload(file))
)

Mistake 6: Not Handling Errors

// ❌ If API fails, the entire Observable dies — no recovery
this.http.get('/api/data').subscribe(data => this.data = data);

// ✅ Always catch errors
this.http.get('/api/data').pipe(
  catchError(err => {
    this.error = 'Failed to load';
    return of([]);
  })
).subscribe(data => this.data = data);

Mistake 7: Overcomplicating Simple Things

// ❌ Too complex for a simple HTTP call
this.http.get('/api/users').pipe(
  take(1),  // Not needed — HTTP already completes after one emission
  first(),  // Also not needed
  shareReplay(1)  // Also unnecessary for a one-time load
)

// ✅ Keep it simple
this.http.get('/api/users')

Mistake 8: Not Using async Pipe

// ❌ Manual subscribe = manual unsubscribe burden
ngOnInit() {
  this.userService.getUsers().subscribe(users => this.users = users);
}

// ✅ async pipe handles everything
users$ = this.userService.getUsers();
// Template: *ngFor="let user of users$ | async"

Mistake 9: Exposing Subject Directly

// ❌ Any component can push values — breaks encapsulation!
cartItems$ = new BehaviorSubject<CartItem[]>([]);

// ✅ Private subject, public Observable
private cartItemsSubject = new BehaviorSubject<CartItem[]>([]);
cartItems$ = this.cartItemsSubject.asObservable();

Mistake 10: Using tap to Extract Data

// ❌ tap should not be used to extract values like this
let userData: User;
this.getUser().pipe(
  tap(user => userData = user)  // Side effect to extract — bad pattern!
).subscribe();

// ✅ Use the data in subscribe or map
this.getUser().subscribe(user => {
  this.userData = user;
});

📋 The Complete RxJS Cheat Sheet

Creating Observables

of(1,2,3) — from static values
from([1,2,3]) — from array or Promise
interval(ms) — ticks every N ms
timer(ms) — emits once after delay
fromEvent(el, 'click') — from DOM event
new Observable(observer => ...) — custom

Transforming

map(fn) — transform each value
filter(fn) — keep only matching values
tap(fn) — side effects, no change

Flattening (Observables of Observables)

switchMap(fn) — cancel old, start new (search, route)
mergeMap(fn) — run all in parallel (uploads)
concatMap(fn) — run one at a time (sequential)

Timing

debounceTime(ms) — wait for silence (search box)
throttleTime(ms) — limit rate (scroll events)
distinctUntilChanged() — skip duplicates
take(n) — take first N, then complete
takeUntil(obs$) — take until signal

Combining

forkJoin({...}) — parallel, wait for all
combineLatest([...]) — emit on any change
withLatestFrom(obs$) — snapshot on trigger
zip(obs1, obs2) — pair by position

Error Handling

catchError(fn) — catch and recover
retry(n) — retry N times
finalize(fn) — always runs last

Subjects

Subject — multicast, no memory
BehaviorSubject(init) — remembers latest
ReplaySubject(n) — remembers last N

🎓 Your Journey So Far — The Complete Series

Here's everything you've learned across all 10 chapters:

Chapter 1 — Observables: the data stream
Chapter 2 — Subscribe & unsubscribe: open and close the tap
Chapter 3 — pipe, map, filter, tap: transform your data
Chapter 4 — switchMap, mergeMap, concatMap: handle nested streams
Chapter 5 — Subject & BehaviorSubject: broadcast to many
Chapter 6 — Error handling: catchError, retry, finalize
Chapter 7 — forkJoin, combineLatest: combine multiple streams
Chapter 8 — Reactive Forms + RxJS: live validation and dynamic forms
Chapter 9 — Timing operators: debounceTime, throttleTime, interval
Chapter 10 — Real-world patterns and best practices (this chapter!)

🚀 What to Learn Next

You're no longer a beginner! Here's your roadmap to RxJS mastery:

1. NgRx — Formal state management built on RxJS (for very large apps)

2. Angular Signals — Angular's newer reactivity system (complements RxJS)

3. shareReplay() — Share a single HTTP response between multiple subscribers

4. Custom Operators — Build your own reusable operators

5. Testing RxJS — Use TestScheduler and marble testing

6. RxJS in Node.js — Use the same patterns on the backend

💌 Thank You for Reading!

You've completed the entire RxJS in Angular Deep Dive series.

Remember: RxJS seems complex at first, but once you see the patterns — Observable → pipe → subscribe, BehaviorSubject in services, async pipe in templates — everything clicks.

The best way to get better is to build. Take a real project and apply what you've learned here.

Good luck, and happy coding! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 10 of 10 — The Final Chapter

Share this series with your team! Every Angular developer needs to understand RxJS.

RxJS in Angular — Chapter 9 | Timing Operators — debounceTime, throttleTime, interval & More

Jack Pritom Soren — Fri, 10 Jul 2026 06:38:36 +0000

👋 Welcome to Chapter 9!

Imagine a user typing in a search box. They type "i", "ip", "iph", "ipho", "iphon", "iphone" — 6 keystrokes in 2 seconds.

Do you really want to make 6 API calls? Of course not! You want to wait until they stop typing and then search once.

That's what timing operators solve. They control when and how often values flow through your stream.

⏱️ `debounceTime()` — Wait for the Silence

debounceTime(ms) waits until there's a pause of ms milliseconds, THEN lets the latest value through.

Think of it like this: "Ignore everything until they stop for a moment."

Like a person who waits for you to finish talking before responding.

import { debounceTime } from 'rxjs/operators';

// User types fast: 'i' → 'ip' → 'iph' → 'ipho' → 'iphon' → 'iphone'
// debounceTime(400) waits 400ms of silence, then sends 'iphone' only
searchControl.valueChanges
  .pipe(debounceTime(400))
  .subscribe(term => {
    this.searchProducts(term);  // Only called ONCE with 'iphone'!
  });

Timeline:

Type 'i'     →  [400ms timer starts]
Type 'ip'    →  [reset timer]
Type 'iph'   →  [reset timer]
Type 'iphone'→  [reset timer]
... 400ms silence ...
EMIT: 'iphone' ✅

Real Angular Example — Smart Search Box

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

@Component({
  selector: 'app-search-box',
  template: `
    <div class="search-wrapper">
      <input
        [formControl]="searchControl"
        placeholder="Search products..."
        (keyup.escape)="clearSearch()">

      <span *ngIf="isLoading" class="spinner">🔄</span>
      <button *ngIf="searchControl.value" (click)="clearSearch()">✕</button>
    </div>

    <div class="results-count" *ngIf="(results$ | async) as results">
      Found {{ results.length }} results
    </div>

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

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

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

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    this.results$ = this.searchControl.valueChanges.pipe(
      startWith(''),
      debounceTime(400),           // Wait 400ms after typing stops
      distinctUntilChanged(),      // Don't search if value is the same
      tap(() => this.isLoading = true),
      switchMap(term =>
        this.productService.search(term || '').pipe(
          catchError(() => of([]))
        )
      ),
      tap(() => this.isLoading = false),
      takeUntil(this.destroy$)
    );
  }

  clearSearch(): void {
    this.searchControl.setValue('');
  }

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

Without debounceTime, a user typing "iphone 14" (8 keystrokes) would make 8 API calls. With it: 1 call. 🎉

⚡ `throttleTime()` — Only Once Per Time Window

throttleTime(ms) lets the FIRST value through, then ignores everything for ms milliseconds.

"One value per window — take the first, ignore the rest."

Like a bouncer who lets one person in, then waits before letting the next.

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

// User scrolls constantly — fire only once every 200ms
fromEvent(window, 'scroll')
  .pipe(throttleTime(200))
  .subscribe(() => {
    this.checkIfNearBottom();
  });

`debounceTime` vs `throttleTime`:

User clicks rapidly: click, click, click, click, click
                     (every 100ms)

debounceTime(300):   ................ EMIT (only after 300ms silence)
throttleTime(300):   EMIT ............. EMIT (first click, then every 300ms)

Use debounceTime when you want to wait for the user to FINISH (search, form input)
Use throttleTime when you want regular updates while something is happening (scroll, resize, mouse move)

🎯 `distinctUntilChanged()` — Skip Identical Values

This one is simple: don't emit if the value is the same as the last one.

import { distinctUntilChanged } from 'rxjs/operators';

// User clicks in the same input field without changing value
searchControl.valueChanges
  .pipe(
    debounceTime(400),
    distinctUntilChanged()  // Don't search again if value didn't change!
  )
  .subscribe(term => this.search(term));

You can also compare objects with a custom comparator:

this.filterForm.valueChanges.pipe(
  debounceTime(300),
  distinctUntilChanged((prev, curr) =>
    prev.category === curr.category && prev.maxPrice === curr.maxPrice
  )
)

🕐 `interval()` — Emit on a Schedule

interval(ms) emits incrementing numbers (0, 1, 2, 3...) every ms milliseconds. It runs forever until you unsubscribe.

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

// Emit every 1 second: 0, 1, 2, 3...
interval(1000).subscribe(n => console.log(n));

Real Example — Auto-Refresh Dashboard

@Component({
  selector: 'app-live-dashboard',
  template: `
    <div class="dashboard">
      <h2>🔴 Live Orders</h2>
      <p class="last-updated">Last updated: {{ lastUpdated | date:'HH:mm:ss' }}</p>

      <div *ngFor="let order of orders$ | async" class="order-row">
        #{{ order.id }} — {{ order.status }} — ৳{{ order.total }}
      </div>
    </div>
  `
})
export class LiveDashboardComponent implements OnInit, OnDestroy {

  orders$!: Observable<Order[]>;
  lastUpdated = new Date();

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

  constructor(private orderService: OrderService) {}

  ngOnInit(): void {
    // Load immediately, then refresh every 30 seconds
    this.orders$ = interval(30000).pipe(
      startWith(0),  // Emit immediately (don't wait for first interval)
      switchMap(() => {
        this.lastUpdated = new Date();
        return this.orderService.getLiveOrders();
      }),
      takeUntil(this.destroy$)
    );
  }

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

The dashboard refreshes every 30 seconds automatically — no manual button needed!

⏲️ `timer()` — Emit Once After a Delay

timer(delay) emits once after the specified delay.
timer(delay, interval) emits once after delay, then every interval.

import { timer } from 'rxjs';

// Show a toast notification, then hide it after 3 seconds
this.showToast = true;

timer(3000).pipe(
  takeUntil(this.destroy$)
).subscribe(() => {
  this.showToast = false;
});

Real Example — Auto-dismiss Notifications

@Component({
  selector: 'app-toast',
  template: `
    <div *ngFor="let toast of toasts" class="toast" [class]="toast.type">
      {{ toast.message }}
      <button (click)="dismiss(toast.id)">✕</button>
    </div>
  `
})
export class ToastComponent implements OnInit, OnDestroy {

  toasts: Toast[] = [];
  private destroy$ = new Subject<void>();

  constructor(private toastService: ToastService) {}

  ngOnInit(): void {
    this.toastService.toasts$
      .pipe(takeUntil(this.destroy$))
      .subscribe(toast => {
        this.toasts.push(toast);

        // Auto-remove after 4 seconds
        timer(4000)
          .pipe(takeUntil(this.destroy$))
          .subscribe(() => {
            this.dismiss(toast.id);
          });
      });
  }

  dismiss(id: number): void {
    this.toasts = this.toasts.filter(t => t.id !== id);
  }

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

📡 `fromEvent()` — Turn DOM Events into Observables

fromEvent converts any DOM event into an Observable stream!

import { fromEvent } from 'rxjs';
import { debounceTime, map } from 'rxjs/operators';

// Infinite scroll — detect when user is near bottom
const scroll$ = fromEvent(window, 'scroll').pipe(
  throttleTime(200),
  map(() => {
    const scrollTop = window.scrollY;
    const windowHeight = window.innerHeight;
    const docHeight = document.documentElement.scrollHeight;
    return (scrollTop + windowHeight) / docHeight * 100; // % scrolled
  }),
  filter(pct => pct > 80)  // Only when 80% scrolled
);

scroll$.pipe(
  takeUntil(this.destroy$)
).subscribe(() => {
  this.loadMoreItems();
});

🏗️ Full Real-World Example — Infinite Scroll List

@Component({
  selector: 'app-infinite-list',
  template: `
    <div class="scroll-container" #scrollContainer>
      <div *ngFor="let item of items" class="list-item">
        <strong>{{ item.title }}</strong>
        <p>{{ item.body }}</p>
      </div>

      <div *ngIf="isLoadingMore" class="loading-more">
        Loading more... ⏳
      </div>

      <div *ngIf="noMoreItems" class="end-message">
        🏁 You've reached the end!
      </div>
    </div>
  `
})
export class InfiniteListComponent implements OnInit, OnDestroy {

  items: Item[] = [];
  currentPage = 1;
  isLoadingMore = false;
  noMoreItems = false;

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

  constructor(
    private itemService: ItemService,
    private el: ElementRef
  ) {}

  ngOnInit(): void {
    // Load initial items
    this.loadPage(1);

    // Watch for scroll near bottom
    fromEvent(this.el.nativeElement.querySelector('.scroll-container'), 'scroll')
      .pipe(
        throttleTime(300),
        filter(() => !this.isLoadingMore && !this.noMoreItems),
        filter((event: any) => {
          const el = event.target;
          const nearBottom = el.scrollTop + el.clientHeight >= el.scrollHeight - 200;
          return nearBottom;
        }),
        takeUntil(this.destroy$)
      )
      .subscribe(() => {
        this.currentPage++;
        this.loadPage(this.currentPage);
      });
  }

  private loadPage(page: number): void {
    this.isLoadingMore = true;

    this.itemService.getItems(page).subscribe({
      next: (newItems) => {
        if (newItems.length === 0) {
          this.noMoreItems = true;
        } else {
          this.items = [...this.items, ...newItems];
        }
        this.isLoadingMore = false;
      },
      error: () => {
        this.isLoadingMore = false;
      }
    });
  }

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

🧠 Quick Reference — When to Use Which

debounceTime(400) — User is typing in a search box. Wait for them to pause before searching.

throttleTime(200) — User is scrolling or resizing. Handle events at most once per 200ms.

distinctUntilChanged() — Don't trigger again if the value hasn't actually changed.

interval(30000) — Refresh dashboard data every 30 seconds.

timer(3000) — Auto-dismiss a notification after 3 seconds.

fromEvent(el, 'scroll') — Convert a DOM scroll event into an Observable.

🧠 Chapter 9 Summary — What You Learned

debounceTime(ms) — emits only after the stream is silent for ms milliseconds. Best for search inputs.
throttleTime(ms) — emits the first value, then ignores for ms milliseconds. Best for scroll/resize events.
distinctUntilChanged() — skips emission if value is same as previous. Essential for search and forms.
interval(ms) — emits 0, 1, 2... every ms milliseconds. Best for polling/auto-refresh.
timer(ms) — emits once after delay. Best for auto-dismiss notifications.
fromEvent(element, event) — turns any DOM event into an Observable. Best for scroll, click, resize.

📚 Coming Up in Chapter 10 — The Final Chapter!

We wrap up the series with the most important real-world patterns every Angular developer should know:

The async pipe + loading state pattern
The smart/dumb component pattern with Observables
The state management pattern using BehaviorSubject
Performance tips — avoiding common RxJS pitfalls

See you in the final chapter! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 9 of 10

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