DEV Community: Art Stesh

Step Five into RxJS: Error Handling

Art Stesh — Sat, 24 May 2025 14:00:00 +0000

You've encountered those "fun" stories where a developer finishes a task, it passes testing, goes to production, and
then meets an unexpected failure of some minor API method, bringing down the entire app so users see only a blank
screen?

I got too close to them back in the day... Honestly, RxJS streams are excellent teachers — you won’t want to repeat
their lessons. What do they teach us? First and foremost: don’t trust external sources. You control neither the server
connection nor the API service, so you have no grounds to blindly trust them or expect flawless operation.

If your backend has five-nines availability (an excellent result!), it’s still down for a few minutes a year. Failures
happen to all systems.

Typical Newbie Scenarios

Ghost Data

this.api.getData().subscribe(
    data => this.render(data) // What if data === undefined?
);

Silent Crash

combineLatest(
    loadUsers(),
    loadProducts() // If this fails — everything stops
).subscribe();

Domino Effect

interval(1000).pipe(
    switchMap(() => new Observable(o => {
        o.error('Error!')
    }))
).subscribe(); // On error, the entire stream crashes, data stops updating

“A good developer writes code. A great one anticipates how it will break.”

— Unknown Architect*

Basic Error Handling Operators: Your "First Aid Kit" (Relevant for RxJS 7.8+)

`catchError`: The Digital First Aid

How It Works

Imagine your Observable is a delivery service. catchError is the insurance company — yes, it can’t return a lost
package, but it will try to offer a replacement (would a monetary refund work for you?).

Practice

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

const request = new Observable(o => {
    o.error('Error!');
    o.complete();
});
request.pipe(
    catchError(error => {
        console.log(error); // Log the issue
        return of([]); // Return empty array as fallback
    })
).subscribe(orders => {
    console.log(orders); // Always get data to display
});

In all examples, I'll use custom Observable like this. Let’s agree that in real projects you’d use something like
this.http.get('/api/orders'). This format allows you to copy-paste code for experiments, while HTTP examples would
require rewriting. Similarly, I use console.log(error) instead of this.logService.report(error) for simplicity.

retry: Smart Retry with Control

Philosophy

Like a good barista remakes coffee after a mistake — retry repeats requests. But remember: not all operations are
idempotent!

Configuration Example

import {retry, timer} from 'rxjs';

const request = new Observable(o => {
    o.error('Error!');
    o.complete();
});
request.pipe(
    retry({
        count: 3, // Max 3 attempts
        delay: (error, retryCount) => timer(1000 * retryCount) // Growing delay: 1s, 2s, 3s
    })
).subscribe();

Safety Rules

Never use for POST/PUT requests
Always set a reasonable attempt limit
Combine with delays to protect the server

finalize: Guaranteed Cleanup

Why It Matters

No matter the battle, cleanup must happen. finalize executes regardless of outcome:

Success
Error
Manual unsubscription

Ideal Use Case

this.loading = true;
const request = new Observable(o => {
    o.error('Error!');
    o.complete();
});
request.pipe(
    finalize(() => {
        this.loading = false; // Always reset the flag
        console.log('DataLoadCompleted');
    })
).subscribe();

Why We No Longer Use retryWhen?

Deprecated Approach retryWhen is marked deprecated in RxJS 7.8+.
New Capabilities The retry config object is simpler and safer:

retry({
    count: 4,
    delay: (_, i) => timer(1000 * 2 ** i) // Exponential backoff
})

Code Readability Config objects make retry logic explicit.

Battle-Hardened Tips

Three-Layer Rule
- Layer 1: Request retry (retry)
- Layer 2: Fallback data (catchError)
- Layer 3: Global error handler
80/20 Rule

Handle 80% of errors via catchError, 20% via complex strategies.
Logging as a Diary

Always record:
- Error type
- Operation context
- Timestamp
Test Failure Scenarios

Add 1-2 error tests for every ten positive tests.

"Code without error handling is like a house with no fire exit: works until disaster strikes."

Operator Use Cases: From Theory to Practice

Scenario 1: Graceful Data Degradation

Problem

The app crashes if the API returns 404 on a product page.

Solution with `catchError`

this.product$ = this.http.get(`/api/products/${id}`).pipe(
    catchError(error => {
        if (error.status === 404) {
            return of({
                id,
                name: 'Product temporarily unavailable',
                image: '/assets/placeholder.jpg'
            });
        }
        throw error; // Propagate other errors
    })
);

Effect:

Users see an informative card instead of a blank screen.

Scenario 2: Smart Request Retries

Problem

Mobile clients often lose connection while loading news feeds.

Solution with `retry`

this.http.get('/api/feed').pipe(
    retry({
        count: 3, // Max 3 attempts
        delay: (error, retryCount) => timer(1000 * retryCount) // Linear delay
    }),
    catchError(err => {
        this.offlineService.showWarning();
        return EMPTY;
    })
).subscribe();

Stats:

Reduced feed loading errors in unstable network conditions.

Scenario 3: Complex Payment Processing

Problem

Need to guarantee payment clearing even during errors.

Operator Combination

processPayment(paymentData).pipe(
    retry(2), // Retry for temporary failures
    catchError(error => {
        this.fallbackProcessor.process(paymentData);
        return EMPTY;
    }),
    finalize(() => {
        this.cleanupResources();
        this.logService.flush(); // Guaranteed log write
    })
).subscribe();

Architecture Tip:

Always separate "retryable" and "fatal" errors.

Scenario 4: Background Sync

Problem

Background sync process "hangs" on errors.

Solution with `finalize`

this.syncJob = interval(30_000).pipe(
    switchMap(() => this.syncService.run()),
    finalize(() => {
        this.jobRegistry.unregister('background-sync');
        this.memoryCache.clear();
    })
).subscribe();

Key Point:

Resources are released even with manual unsubscription.

Battlefield Tips

"Layered Defense" Pattern Combine operators as filters:

Stream → retry(3) → catchError → finalize

Metrics Are Your Friends Add error counters:

catchError(error => {
    this.metrics.increment('API_ERRORS');
    throw error;
})

Test Edge Cases Use marble diagrams to simulate errors:

Error Handling Strategies: How to Avoid Drowning in Exceptions

1. "Safe Islands" Strategy

Concept

Break the stream into independent segments with local error handling. Like watertight compartments in a ship.

Implementation

merge(
    this.loadUserData().pipe(
        catchError(() => of(null)) // Errors won't break other streams
    ),
    this.loadProducts().pipe(
        retry(2) // Custom retry policy
    )
).pipe(
    finalize(() => this.hideLoader()) // Shared cleanup point
);

Effect:

Errors in one stream don’t crash the entire system.

2. "Layered Defense" Strategy

Three-Tier Model

Request Level: Retries for temporary failures

this.http.get(...).pipe(retry(3))

Component Level: Fallback data

catchError(() => this.cache.getData())

Application Level: Global error interceptor


@Injectable()
export class GlobalErrorHandler implements ErrorHandler {
    handleError(error) {
        this.sentry.captureException(error);
    }
}

3. "Smart Retry" Strategy

When to Use

Services with unstable connections
Mission-critical operations
Background syncs

Exponential Backoff Pattern

retry({
    count: 4,
    delay: (error, retryCount) => timer(1000 * 2 ** retryCount)
})

Real-World Stats:

Successful recovery in most cases with 4 attempts.

4. "Silent Fail" Strategy

Purpose

Non-data-critical components
Demo modes
Functional degradation scenarios (e.g., switching from streams to HTTP requests)

Implementation

this.liveUpdates$ = websocketStream.pipe(
    catchError(() => interval(5000).pipe(
            switchMap(() => this.http.get('/polling-endpoint'))
        )
    )
);

Effect:
Users continue working in a limited mode.

5. "Explicit Failure" Strategy

When to Use

Financial operations
Legally binding actions
Security systems

Implementation

processTransaction().pipe(
    tap({error: () => this.rollbackTransaction()}),
    catchError(error => {
        this.showFatalError();
        throw error;
    })
);

Golden Rule:
Better to fail explicitly than enter an invalid state.

Strategy Selection Checklist

How critical is the operation?

Money/security → "Explicit Failure"
Data viewing → "Silent Fail"

How frequent are errors?

Often → "Layered Defense"
Rare → "Safe Islands"

What resources are available?

Cache exists → "Smart Retry"
No fallbacks → "Silent Fail"

"Strategy without metrics is like a compass without a needle."

— Observability Principle in Microservices

Common Beginner Mistakes: How to Avoid Pitfalls

1. Silent Error Swallowing

❌ Problematic Approach

this.http.get('/api/data').subscribe(data => {
// Errors? What errors?
    this.render(data);
});

Consequences:
Users see a frozen UI, errors go unlogged.

✅ Correct Solution

this.http.get('/api/data').subscribe({
    next: data => this.render(data),
    error: err => this.handleError(err) // Always handle errors
});

2. Infinite Retry Loops

❌ Dangerous Code

this.http.get('/api/orders').pipe(
    retry() // Infinite loop on 500 errors
);

Risks:
Self-inflicted DDoS, mobile battery drain.

✅ Safe Approach

retry(3) // Clear attempt limit

3. Ignoring Unsubscriptions

❌ Common Pitfall

ngOnInit()
{
    interval(1000).subscribe(data => {
// Subscription lives forever after route changes
        this.updateRealTimeData(data);
    });
}

Effect:
Memory leaks, update conflicts.

✅ Professional Approach

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

ngOnInit()
{
    interval(1000).pipe(
        takeUntil(this.destroy$)
    ).subscribe(...);
}

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

4. Global Handler as a "Trash Can"

❌ Anti-Pattern

// global-error-handler.ts
handleError(error)
{
// Catch ALL errors indiscriminately
    this.sentry.captureException(error);
}

Issue:
No way to customize handling for specific scenarios.

✅ Stratified Approach

// Local handling
catchError(err => handleLocalError(err))

// Global handler
handleError(error)
{
    if (error.isCritical) {
        this.sentry.captureException(error);
    }
}

Self-Check Checklist

Do all subscriptions have error handling?
Are there retry attempt limits?
Is takeUntil used for unsubscriptions?
Are global and local errors separated?

"Errors are like rakes: to stop stepping on them, you must first see them in the code."

— Another "auf" principle from dev memes

Conclusion: Errors as a Path to Mastery

What Have We Learned?

Through years of working with RxJS, I've realized: true mastery begins where others see problems. Error handling
isn’t routine—it’s the art of designing resilient systems.

Key Lessons:

Error Handling is a Code Maturity Indicator

Every catchError in your code is a step toward professional-grade development.
Retries ≠ Panacea

Properly configured retry saves where naive implementations harm.

"The best error is the one that never happens. The second best—the one handled gracefully."

— Ancient Developer Proverb

Where to Go Next?

Experiment with Combinations Example of an advanced chain:

   data$.pipe(
   retryWhen(exponentialBackoff(1000, 3)),
   catchError(switchToCache),
   finalize(cleanup)
   )

Study Real-World Cases

Explore source code of Angular HttpClient and Ngrx — treasure troves of patterns.
Share Knowledge

Write a post about your toughest error — the best way to solidify experience.

"In 20 years of development, I’ve seen many 'perfect' systems. They all broke. The ones that survived treated errors
as part of the design."

— Someone, definitely, once said to someone*

Your Next Step:

Open your latest project. Find at least one stream without error handling — and turn it into a reliability example.

Remember: every handled failure saves hours of support and thousands of satisfied users.

The Fourth Step into the World of RxJS: Unfinished Streams - Silent Killers of Applications

Art Stesh — Sat, 17 May 2025 14:00:00 +0000

Throughout the first, second, and third articles, we have embarked on a fascinating journey together: from our initial introduction to Observables, where we grasped the fundamentals of the reactive approach, through mastering operators that enabled us to efficiently transform and filter data, to combining streams, which unlocked the ability to synchronize data from multiple sources. We gradually transformed RxJS from an intriguing tool for experimentation into a powerful instrument for real-world tasks.

Now, having taken three confident steps, it is time to confront the dark side of reactive programming. Like any technology, RxJS has its pitfalls. One of the most insidious is unclosed subscriptions, which can lead to severe issues such as memory leaks, performance degradation, and even application crashes. The true power of RxJS tools demands not only technical knowledge from developers but also genuine professional expertise to build reliable and high-performance applications.

If the first three steps were about creating and transforming streams, the fourth step is about taking responsibility for what has been created. This is a stride toward maturity in working with RxJS—understanding why subscription management is critical and how it impacts the quality of your applications.

Join us to delve deeper into the world of RxJS, avoid common pitfalls, and become a developer who not only crafts engaging code but also ensures it is robust, optimized, and adaptable to any operational environment.

Threats When Working with RxJS

Modern Angular is hard to imagine today without RxJS. It empowers us to handle asynchronous tasks, manage state reactively, respond to events, and even construct complex data processing pipelines.

With RxJS, you work with data streams (Observable). When you subscribe to an Observable, imagine it as attaching a hose to a water tap. The data stream starts flowing, events pour into your application in a continuous stream. The problem is that the tap won't close until you manually turn the handle.

Subscriptions without unsubscribe are silent killers. While you test everything in short development sessions, the app works perfectly... until a QA engineer complains about smoke coming from their laptop after 30 minutes of interacting with your creation.

Imagine you created a subscription inside an Angular component but forgot to "close" it when the component is no longer needed (e.g., the user navigates to another part of the app). What happens?

Data continues to flow. Even if the UI no longer uses this data, the subscription remains active. This means that even when no one is watching, the stream keeps emitting events, straining both your system and the server.
Memory stops being freed. RxJS streams act as long-lived objects. As long as the subscription is active, references to data persist in memory, and the garbage collector (GC) cannot release them.
Hidden issues escalate. At first, this might seem unimportant — everything works. But after a few hours of app runtime (or several component navigations), problems start compounding:
- Performance degradation.
- Memory leaks.
- Browser crashes (especially on low-end devices).

Why Won't You Notice the Problem Immediately?
During development, it's easy to overlook RxJS subscription details. Everything looks fine: data updates correctly, no console errors, performance seems adequate in short sessions. But inefficiency always catches up.
The first serious memory leak might strike days or weeks later when the app reaches users with low-end devices. Then you'll face an odyssey of hunting "phantom" bugs, blaming environment issues, and cursing "user error"...

Memory Leak Example

Imagine developing a real-time chat widget for a website. It receives live messages and displays them on the page. Everything seems perfect, but there's a hidden flaw. A tiny oversight... until the first performance degradation report lands directly from an end-user.

import {ChangeDetectionStrategy, ChangeDetectorRef, Component, OnDestroy, OnInit} from '@angular/core';
import {interval, map} from "rxjs";
import {NgForOf} from "@angular/common";

let instance = 1;

@Component({
    selector: 'app-chat',
    standalone: true,
    imports: [
        NgForOf
    ],
    changeDetection: ChangeDetectionStrategy.OnPush,
    template: `
    <h2>Real-time Chat</h2>
    <div class="chat-window">
      <div *ngFor="let message of messages" class="message">
        {{ message }}
      </div>
    </div>
  `,
    styles: [`
    .chat-window {
      border: 1px solid #ccc;
      height: 300px;
      overflow-y: auto;
    }
    .message {
      padding: 8px;
      border-bottom: 1px solid #eee;
    }
  `]
})
export class ChatComponent implements OnInit, OnDestroy {
    messages: string[] = [];
    instanceId = instance++;
// Creation of a random string
    private getRandomString = () => (Math.random() + 1).toString(36).substring(2);

    constructor(private detector: ChangeDetectorRef) {
    }

    ngOnInit(): void {
// Creation of a new data-stream every 0.5 sec
        interval(500)
            .pipe(
                map((i) => `New message #${i + 1} - ${new Array(1000).fill(0)
                    .map(() => this.getRandomString()).join('')}`) // Симуляция тяжелых данных
            )
            .subscribe(message => {
// Adding of the message to the collection
                this.messages.push(message);
                this.detector.detectChanges();
                console.log(`The subscription ${this.instanceId} is finished.`);
            });
    }


    ngOnDestroy(): void {
        console.log(`ChatComponent ${this.instanceId} destroyed`);
    }
}

What's Wrong with This Component?

At first glance, nothing catastrophic: UI updates, everything works as intended.

But here's the catch: You did NOT unsubscribe from the stream!

When the user hides the chat, the ChatComponent gets destroyed. But the subscription firing twice per second continues to "live". It keeps generating messages to send... nowhere. As a result:

The stream remains active. Messages keep being generated in memory.
References to the messages[] array persist in memory.
The Garbage Collector (GC) cannot free allocated resources because the subscription maintains a "live" reference.

Let's See This in Action:

Download the project from here and run it.
Open browser DevTools and navigate to the Console tab.
Click the chat open/close button multiple times.

You'll see an ever-increasing number of console messages. Worst of all, messages from already destroyed chat instances will keep appearing. In the Memory tab, you'll observe endless growth of application resource usage.

Why Is This Bad? Memory Leaks and Their Impact

When you subscribe to an Observable stream, it creates a reference to your subscriber code. An RxJS stream remains "alive" as long as there's at least one active subscription. This means that if you don't unsubscribe, the associated data will linger in memory indefinitely.

In our example, the subscription maintains a reference to the messages[] array. Even if the user closes the chat:

New message objects keep being generated and added to the array, though no longer needed.
Old array references stay "alive", and the Garbage Collector (GC) cannot reclaim them because the stream remains active.

The result? Memory gradually clogs up. In early stages, this goes unnoticed, but after 5-10 minutes of runtime, the app suddenly starts lagging.

The more active subscriptions remain, the more data your RxJS stream processes. Consequences:

CPU load spikes.
Low-end devices (e.g., older phones) struggle with excess computations.
At the worst possible moment, the browser crashes or severe GUI delays occur.

In our chat example, the bug is particularly dangerous because new messages are generated every 500ms. Multiply this by the number of abandoned subscriptions — and you get a disaster.

Why Isn't This Obvious?

Memory leak-related errors often develop gradually. Here are reasons why developers neglect unsubscribe early in development:

Initial performance seems fine. At first, you notice nothing — subscriptions work, UI updates.
Diagnostic complexity. Memory leaks only manifest long-term. You rarely "see" anomalies during short testing sessions.
Angular handles many tasks automatically. Framework tools often "mask" the issue until it accumulates.
Optimistic mindset. "It works — must be okay". But the truth is: unclosed subscriptions will cause issues at the worst possible time.

How to Fix It? Closing Subscriptions

Now that we understand leaving subscriptions open is bad, let's explore reliable solutions. Proper subscription management in Angular isn't as hard as it seems — make it a rule from day one.

1. Use `Subscription` for Manual Management

RxJS provides the Subscription class to manage subscriptions. By explicitly storing subscriptions, you can unsubscribe when the component is destroyed. Let's modify our problematic code using Subscription:

import {ChangeDetectionStrategy, ChangeDetectorRef, Component, OnDestroy, OnInit} from '@angular/core';
import {interval, map, Subscription} from "rxjs";
import {NgForOf} from "@angular/common";

let instance = 1;

@Component({
    selector: 'app-chat',
    standalone: true,
    imports: [
        NgForOf
    ],
    changeDetection: ChangeDetectionStrategy.OnPush,
    template: `
    <h2>Real-time Chat</h2>
    <div class="chat-window">
      <div *ngFor="let message of messages" class="message">
        {{ message }}
      </div>
    </div>
  `,
    styles: [`
    .chat-window {
      border: 1px solid #ccc;
      height: 300px;
      overflow-y: auto;
    }
    .message {
      padding: 8px;
      border-bottom: 1px solid #eee;
    }
  `]
})
export class ChatComponent implements OnInit, OnDestroy {
    messages: string[] = [];
    instanceId = instance++;
    private subscriptions: Subscription[] = []; // Store all subscriptions here
    private getRandomString = () => (Math.random() + 1).toString(36).substring(2);

    constructor(private detector: ChangeDetectorRef) {
    }

    ngOnInit(): void {
        // Add observable to subscriptions list
        this.subscriptions.push(interval(500)
            .pipe(
                map((i) => `New message #${i + 1} - ${new Array(1000)
                    .fill(0).map(() => this.getRandomString()).join('')}`)
            )
            .subscribe(message => {
                // Add new message to the list
                this.messages.push(message);
                this.detector.detectChanges();
                console.log(`Subscription ${this.instanceId} executed.`);
            }));
    }


    ngOnDestroy(): void {
        // Unsubscribe from all observables
        this.subscriptions.forEach(s => s.unsubscribe());
        console.log(`ChatComponent ${this.instanceId} destroyed`);
    }
}

What's Happening Here?

We create a Subscription object to store our message stream.
When the component is destroyed (ngOnDestroy), we call .unsubscribe(), terminating the data stream observation.

This is the simplest and most straightforward approach. By storing subscriptions separately, you retain full manual control.

You can also create a utility class to encapsulate this logic:

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

export abstract class DestructibleComponent implements OnDestroy {
    protected subs: Subscription[] = [];
    protected onDestroy?: () => void;

    ngOnDestroy(): void {
        this.subs.forEach(s => s.unsubscribe());
        if (this.onDestroy) this.onDestroy();
    }
}

Any component can inherit this class (extends) and add subscriptions to the subs array without redefining ngOnDestroy. For additional cleanup logic, the onDestroy method is available — it runs after unsubscriptions without interfering with them.

2. Use AsyncPipe: Minimal Code

If your data is only displayed in templates (e.g., via *ngFor or {{ }}), you can avoid manual subscriptions in TypeScript altogether. Angular's AsyncPipe handles unsubscriptions automatically.

Here's an example:

import {ChangeDetectionStrategy, ChangeDetectorRef, Component, OnDestroy} from '@angular/core';
import {interval, map, tap} from "rxjs";
import {AsyncPipe, NgForOf} from "@angular/common";

let instance = 1;

@Component({
    selector: 'app-chat',
    standalone: true,
    imports: [
        NgForOf,
        AsyncPipe
    ],
    changeDetection: ChangeDetectionStrategy.OnPush,
    template: `
    <h2>Real-time Chat</h2>
    <div class="chat-window">
      <div *ngFor="let message of messages$ | async" class="message">
        {{ message }}
      </div>
    </div>
  `,
    styles: [`
    .chat-window {
      border: 1px solid #ccc;
      height: 300px;
      overflow-y: auto;
    }
    .message {
      padding: 8px;
      border-bottom: 1px solid #eee;
    }
  `]
})
export class ChatComponent implements OnDestroy {
    instanceId = instance++;
    private getRandomString = () => (Math.random() + 1).toString(36).substring(2);
    messages$ = interval(500)
        .pipe(
            tap(() => console.log(`Subscription ${this.instanceId} is done.`)),
            map((i) => Array.from({length: i}).map((_, idx) =>
                `New message #${idx + 1} - ${new Array(1000).fill(0)
                    .map(() => this.getRandomString()).join('')}`))
        );

    constructor(private detector: ChangeDetectorRef) {
    }

    ngOnDestroy(): void {
        console.log(`ChatComponent ${this.instanceId} destroyed`);
    }
}

Why is AsyncPipe Awesome?

Automatically subscribes to Observables when the template renders.
Unsubscribes automatically when the component is destroyed.
Keeps code extremely concise.

When to Use It?

Use AsyncPipe if the data stream is only consumed in the template and nowhere else in the code.

Best Practices for Subscription Management

1. Adopt a Unified Approach

Stick to one subscription management style across your project. For example:

Inherit DestructibleComponent for all components.
Use the widely-known takeUntil pattern.
Use manual Subscription management for niche cases.

2. Minimize Subscriptions

Combine streams using operators like merge, combineLatest, or switchMap instead of creating multiple small subscriptions.

3. Prefer `AsyncPipe`

Whenever possible, use AsyncPipe for template-bound data.

4. Monitor Performance in DevTools

Regularly audit app performance:

Use the Memory tab to detect leaks.
Profile with Performance to spot anomalies.

5. Log Subscription Cleanup During Development

Add console.log in ngOnDestroy to verify subscriptions close on component destruction.

Conclusion

Working with RxJS isn't just about mastering a new tool — it's a journey toward more efficient, organized, and profound modern app development. Along this path, mistakes like unclosed subscriptions are inevitable, but each is a step forward in your professional growth.

RxJS, like any complex yet powerful skill, demands patience, practice, and relentless determination to improve.

Keep experimenting, learning, and diving into details. Remind yourself that every hour spent mastering fundamentals pays off exponentially: in development speed, app stability, and the respect of colleagues who'll see you as a true professional.

The browser's memory, your users, and your team will thank you. Experiment boldly, make mistakes, fix them, learn, and push toward new horizons. Success in every aspect of development stems from your own effort to transform today's challenges into tomorrow's expertise.

Frontend as the New Legacy: How We Missed the Event-Driven Paradigm Shift

Art Stesh — Sat, 10 May 2025 11:41:56 +0000

Introduction: Architectural Déjà Vu

Have you ever noticed how the digital world moves in spirals? In 2018, I was waving around Dockerfile and Helm charts, implementing microservices in C# with RabbitMQ — all for the sacred goal of low coupling. Three years later, having switched to Angular, I was horrified to realize: frontend components were communicating through Input/Output chains, as if it were 2005 and we were writing WinForms.

It's like assembling a spaceship but controlling it via telegraph. In the backend, we proudly declare event-driven architecture, while on the frontend, components whisper through props like teenagers at a school dance. The irony? The more complex our systems became, the more they resembled the very monoliths we fled from in the backend world.

My epiphany came when I had to modify a dialog box. To add a "Cancel" button, I needed to:

Update the parent component
Rewrite the mediator service
Fix three child modules

Twelve files for one button! In the microservices world, this would be like editing five repositories to change a label color. I asked myself: "Why hasn’t the frontend learned from distributed systems?"

We’ve mastered WebAssembly, adopted GraphQL, modularized CSS — yet component communication remains stuck in the jQuery era. As if architects forgot that React, Angular, and Vue aren’t just about rendering, but interaction between independent agents.

But what if I told you the solution has existed for decades? That the pattern powering RabbitMQ, Kafka, and AWS SQS could save the frontend? That it requires no heavy libraries — just 15 KB of code and a paradigm shift in how we view components.

Let’s dive into the rabbit hole of event-driven design. After this article, your components might stop whispering and start conversing like mature, independent modules.

Part 1: Historical Context — 40 Years of Pub/Sub Evolution

In 1983, when programmers manually set motherboard jumpers, Xerox PARC’s Adele Goldberg was coding Smalltalk-80. Her lab birthed an idea that would outlive PCs, the web, and mobile: "Objects should communicate through messages, not method calls."

Evolution Across Three Eras

1. Tribal Era (1980–2000)
Smalltalk objects exchanged messages like primitive tribes — directly, without intermediaries. The problem? To send a " message," you needed to know the exact location of the recipient "tribe."

"Tribe A sends a message to Tribe B"
B primitive: 'The fire is out!'

Imperial Era (2000–2010)
CORBA and Enterprise Service Bus (ESB) turned messaging into bureaucracy. You had to:

Know WSDL contracts
Register endpoints
Build XML schemas

On a 2010 project, we spent three weeks integrating SAP with .NET via ESB. When we asked the architect, "Why not simplify it?" he replied, "This is enterprise — that’s how it’s done here."

Globalization Era (2010–Present)
Kafka, RabbitMQ, and cloud queues turned Pub/Sub into the lingua franca of microservices. The rules simplified:

Message format = the only contract
Publishers don’t know subscribers
Brokers guarantee delivery

Philosophical Shift: From Commands to Contracts

Pub/Sub is a digital incarnation of Rousseau’s social contract. When a module publishes a PriceChangedEvent, it essentially declares:

"I don’t know who needs this"
"But if you want it — listen"
"I promise the format: {itemId: string, newPrice: number}"

This mirrors TCP/IP for humans: just as data packets don’t care if you’re a browser or email client, messages don’t care if you’re Angular or React.

Why Has Pub/Sub Survived 40 Years of Tech Revolutions?

Antifragility: Systems learn to live with errors (recall the Dead Letter Queues principle)
Language Agnosticism: Messages don’t care what you code in — they’re like Esperanto for microservices
Evolutionary Design: You can start with a simple bus and scale to distributed streaming

Once at a meetup, I heard: "Kafka is Smalltalk for big data." There might be some truth — both approaches teach systems to communicate politely without unnecessary questions.

In the next part, we’ll take this 40-year experience and apply it to Angular components — making them stop poking each other via Input/Output and start speaking the language of independent messages.

Frontend: Stuck in the Past?

While backend migrated from SOAP to events in the 2010s, frontend was busy inventing… @Output(). Angular components are stuck with relics of the imperial era:

Rigid call hierarchies
Services as ESB-like monsters
Events passing through 5 layers — like bureaucratic mail

Once, to add analytics for a button in a child component, we had to:

Add @Output() analyticsEvent to component D
Pass it through B → C → A
Subscribe in the root component

A ton of work for a single line: analytics.track('click'). It’s like delivering a letter to your neighbor via three post offices.

Lessons the Frontend Missed

1. Events ≠ Call Chains

Backend figured out long ago: if microservice A calls B, and B calls C — that’s an anti-pattern. But in frontend, @Output() → service → @Input() is considered normal.

2. Broker ≠ Single Point of Failure

RabbitMQ handles millions of messages. A typical Angular service with Subjects crashes at 1000 events per second.

3. Format > Implementation

Backend uses OpenAPI/Swagger to define contracts. Frontend still works with any in events.

Dawn of Hope: Web Components

Ironically, the future of event-driven frontend began in 2011 with the concept of Web Components. Their Custom Events align closer to Pub/Sub philosophy than the Angular approach:

// Component A
dispatchEvent(new CustomEvent('price-changed', {
    detail: {itemId: '45', price: 20}
}));

// Component B
window.addEventListener('price-changed', (e) => {
    console.log(e.detail.price);
});

This echoes early Smalltalk principles but with HTML5 syntax. It's a pity frameworks didn't pursue this path further.

Historical Paradox: Frontend technologies refresh every 2 years, yet architectural patterns remain stuck in the 2000s. Perhaps it's time to stop reinventing wheels and borrow solutions from... 40-year-old Smalltalk.

In the next part, we'll explore how these principles apply to modern Angular applications – and why @Input/@Output can be more dangerous than they appear. Spoiler: it's like building a castle wall that's harder to scale from the inside than outside.

Part 2: Frontend Dilemma – When Components Start Gossiping

You know that moment when you open a colleague's code and see a component that knows too much? Like that neighbor who monitors everyone through security cameras. In the Angular world, this often starts with innocent @Input() and @Output(), but quickly evolves into a dependency web. Let's uncover why traditional approaches sometimes resemble a game of "broken telephone".

Problem 1: Input/Output as Chain Reactions

Imagine a ProductCard component that should show a modal on click. The classic approach:

// product-card.component.ts
@Output()
openModal = new EventEmitter<string>();

onClick()
{
    this.openModal.emit('product-details');
}

// parent.component.html
<product-card(openModal) = "handleModal($event)" > </product-card>
< modal [type] = "modalType" > </modal>

What's Wrong:

ProductCard knows that a modal exists somewhere
Parent component becomes a courier between unrelated parts
Changing modal type requires editing multiple files

It's like if every office employee delivered documents personally instead of using a shared mailbox.

Problem 2: Mediator Services as New Monoliths

When Outputs multiply, we create ModalService:

// modal.service.ts
private modalSubject = new Subject<string>();
modal$ = this.modalSubject.asObservable();

open(type: string)
{
    this.modalSubject.next(type);
}

// product-card.component.ts
constructor(private modal: ModalService)
{
}

onClick()
{
    this.modal.open('product-details');
}

Seems better, but:

Service becomes a "god object" knowing all modals
Components are tightly coupled to service API
Testing requires mocking entire service for one button

In one project, our SharedService grew to 1200 lines - it managed modals, tooltips, notifications, and animations. We joked that it now runs the project instead of us, but the laughter was nervous.

Case: The Spy Modal

Several years ago we needed to add analytics for a feedback modal. The problem - it was opened from 17 places in the app. With the old pattern we had to:

Add @Output() registerClick to 5 components
Push events through 3 layers of parent components
Update AnalyticsService to add tracking
Write 23 tests to verify event propagation

This took 2 workdays. With postboy solution - 20 minutes:

// Opening modal with analytics
postboy.fire(new OpenModalEvent({
    type: 'signup',
    source: 'navbar' // Analytics context
}));

// Global subscription to all modal opens
postboy.sub(OpenModalEvent).subscribe(event => {
    analytics.track('modal-open', event.type, event.source);
});

No component edits - just added subscription in root module.

Why This is an Architectural Trap?

Fragility: Changing one component triggers a wave of edits in others
Testability: To test a button, you need to mock a chain of services
Scalability: New features increase complexity exponentially

This resembles a city without a master plan: first buildings are erected haphazardly, then they spend years clearing crooked alleys.

Plus, up to a quarter of code review discussions revolve around "how to properly pass an event through component C".

Interim Summary: Angular components are like metropolis residents — they can be independent but need a "central post office" for communication. In the next part, we'll explore how to implement such an office: via custom solution, NgRx, or lightweight libraries. Spoiler: sometimes the best framework is a few dozen lines of code.

Part 3: Backend Lessons — What Frontend Can Steal from RabbitMQ

If components could talk, they'd ask the backend for advice. RabbitMQ, Kafka, and other brokers have been solving the same problems that plague frontend for decades. Let's "borrow" four principles to stop reinventing wheels.

Principle 1: Publishers Don't Know Subscribers

How it works in RabbitMQ:

A seller (publisher) places goods in a warehouse (broker). They don't care who takes the goods — a courier, client, or thief (just kidding).

Frontend Analogy:

A component publishes a "User Logged In" event without knowing:

Who will update the header
Who will send analytics
Who will show a welcome tooltip

// Before
this.authService.login().pipe(
    tap(() => {
        this.header.refresh();
        this.analytics.trackLogin();
        this.tourService.start();
    })
);

// How it should be
this.authService.login().subscribe(() => {
    eventBus.publish(new UserLoggedInEvent());
});

Principle 2: Messages as System Documentation

Backend Practice:

In RabbitMQ, message schemas (e.g., using Avro) serve as living API documentation.

Frontend Implementation:

Every event is a typed class:

class PasswordChangedEvent {
    constructor(
        public readonly userId: string,
        public readonly method: 'email' | 'sms'
    ) {
    }
}

Now any developer can see:

What data the event contains
Possible field values
Where it's used (via project search)

Principle 3: Queues as Chaos Buffers

Backend Pattern:

If a consumer service crashes, RabbitMQ preserves messages in queues until it recovers.

Frontend Adaptation:

For critical events (e.g., analytics), implement retry logic:

class AnalyticsService {
    private failedEvents: AnalyticEvent[] = [];

    constructor() {
        eventBus.subscribe(AnalyticEvent).subscribe(event => {
            try {
                this.sendToServer(event);
            } catch {
                this.failedEvents.push(event); // Save for retry
            }
        });
    }
}

Principle 4: Typing as Contract

Backend Example:

Kafka schemas are registered in Confluent Schema Registry. Incompatible versions get blocked.

Frontend Implementation:

Use TypeScript for error prevention:

// V1: Deprecated version
class ProductAddedEvent {
    constructor(public productId: string) {
    }
}

// V2: New version
class ProductAddedEventV2 {
    constructor(
        public productId: string,
        public categoryId: string
    ) {
    }
}

// Subscriber catches only its version
eventBus.subscribe(ProductAddedEventV2).subscribe(/* ... */);

What It Looks Like in an Ideal World

Imagine components as independent microservices:

Module A publishes CartUpdatedEvent with type { cartId: string, items: CartItem[] }
Module B subscribes and updates the cart badge
Module C listens to the same event for shipping calculations
Module D writes to LocalStorage

No one knows about others' existence. Changed the cart format? Just create CartUpdatedEventV2 — old subscribers keep working with V1.

Why Frontend Lags Behind?

Synchronous Mindset: "Click button → call method → get result" — this is a legacy approach.

Fear of Asynchronicity: Developers fear "floating" events, though it's normal in backend.

Contract Culture: Frontend teams rarely document event formats, turning them into magic strings.

Real-Life Story:

When we implemented typed events, a new developer connected the "order history" feature in a day by studying existing message classes. Previously, this required weeks of negotiations.

Conclusion:

Backend architects have polished event-driven approaches for decades. It's time for frontend to stop stewing in its own juice and start "stealing" proven solutions. In the next part, we'll implement these principles in practice — from custom buses to ready-made tools.

Part 4: Practical Implementation — From Custom Solutions to Libraries

Frontend developers often argue: "Should we build our own EventBus or use existing solutions?". The answer depends on scale. Let’s implement three variants and analyze when each fits.

Option 1: Custom RxJS Bus in 15 Minutes

A basic RxJS EventBus in 20 lines of code:

import {filter, map, Subject} from 'rxjs';

type EventPayload<T> = { type: string; data?: T };

class EventBus {
    private _events$ = new Subject<EventPayload<unknown>>();

    publish<T>(type: string, data?: T): void {
        this._events$.next({type, data});
    }

    subscribe<T>(type: string) {
        return this._events$.pipe(
            filter(event => event.type === type),
            map(event => event.data as T)
        );
    }
}

// Usage
const bus = new EventBus();
bus.subscribe<string>('GREETING').subscribe(msg => console.log(msg));
bus.publish('GREETING', 'Hello from 1983!');

Pros:

Full control
0 dependencies
Suitable for small projects

Cons:

No data typing
Manual subscription management
No Angular lifecycle support

When to use:

Prototypes
Mini-apps (<15 components)
Teaching Pub/Sub principles

Option 2: NgRx as an Event Store

NgRx is "heavy artillery" with a full toolkit:

// actions/events.actions.ts
export const showModal = createAction(
    '[UI] Show Modal',
    props<{ type: string; context?: unknown }>()
);

// effects/events.effects.ts
showModal$ = createEffect(() =>
    this.actions$.pipe(
        ofType(showModal),
        tap(({type}) => console.log(`Modal ${type} opened`))
    ), {dispatch: false}
);

// component.ts
this.store.dispatch(showModal({type: 'confirm'}));

Pros:

DevTools with event history
Integration with app state
Support for complex scenarios (CQRS, sagas)

Cons:

Overkill for simple tasks
Learning curve
Bundle size +45 KB
Typing challenges

When to use:

Enterprise applications
When NgRx is already in use
Complex state-driven business logic

Option 3: Specialized Libraries

The postboy Example:

// Event definition
class ApiErrorEvent extends PostboyGenericMessage {
    constructor(public readonly error: Error) {
        super();
    }
}

// Publishing
postboy.fire(new ApiErrorEvent(err));

// Subscription
postboy.sub(ApiErrorEvent).subscribe(event => {
    alert(`Error: ${event.error.message}`);
});

When to use:

Medium to enterprise projects
Microfrontends
Gradual legacy code migration

How to Choose a Tool?

1. Decision Map:

< 15 components: RxJS Subject
15+ components (to infinity): postboy or similar
50+ components (to infinity): NgRx + additional brokers

2. 48-Hour Rule:
If you couldn't implement Pub/Sub in two days — your choice is too complex.

3. Scalability Test:
Try adding a reaction to an event from a completely new module. If it requires changes in 3+ places — your architecture isn't event-driven.

Case Study:
On a project with 70 components, we started with a custom solution and switched to postboy after six months. It was like changing an engine mid-flight, but the event-driven architecture allowed gradual migration.

Conclusion:
Pub/Sub isn't a silver bullet. It's like a hammer: you can drive nails or smash screens. Choose tools based on "nail size" and remember: the best architecture lets you sleep at night, not brag at meetups.

Part 5: When Events Become Harmful — Pub/Sub Pitfalls

Pub/Sub is like fire: warms when controlled, burns everything when unleashed. Let's explore three scenarios where event-driven models turn from medicine to poison.

1. Cyclic Dependencies: Infinite Loop

Problem:

Event A triggers B, B triggers C, and C triggers A again.

// Component A
postboy.subscribe(EventC).subscribe(() => {
    postboy.publish(new EventA()); // Looping
});

// Component B
postboy.subscribe(EventA).subscribe(() => {
    postboy.publish(new EventB());
});

// Component C
postboy.subscribe(EventB).subscribe(() => {
    postboy.publish(new EventC());
});

Why dangerous:

Infinite event loop → 100% CPU load
Impossible to debug via DevTools

Solution:

Add debounce (RxJS operator):

postboy.subscribe(EventA).pipe(
    debounceTime(100)
).subscribe(/* ... */);

Use inhibitor flags:

let isProcessing = false;

postboy.subscribe(EventA).subscribe(() => {
    if (!isProcessing) {
        isProcessing = true;
// Logic...
        isProcessing = false;
    }
});

2. Memory Leaks: Ghost Subscriptions

Problem:

Unsubscribed subscriptions in services accumulate during hot module reloading.


@Injectable()
export class AnalyticsService {
    constructor() {
// Subscription never unsubscribed!
        eventBus.subscribe(TrackingEvent).subscribe(/* ... */);
    }
}

Why dangerous:

Memory leaks → performance crashes
"Zombie handlers" react to events after component destruction

Angular Solution:

Use takeUntilDestroyed:

private destroyRef = inject(DestroyRef);

eventBus.subscribe(Event)
    .pipe(takeUntilDestroyed(this.destroyRef))
    .subscribe(/* ... */);

For services — manual management:

private sub?: Subscription;

ngOnInit()
{
    this.sub = eventBus.subscribe(Event).subscribe(/* ... */);
}

ngOnDestroy()
{
    this.sub?.unsubscribe();
}

3. Typing Blind Spots: Errors in the Darkness

The Problem:

Untyped events become runtime time bombs.

// Bad: Data without contract
eventBus.publish('user_updated', {id: 123, name: 'Alice'});

// Somewhere else in the codebase
eventBus.subscribe('user_updated').subscribe(data => {
    console.log((data as any).age); // undefined → runtime crash
});

Why Dangerous:

Errors surface only at runtime
Refactoring becomes Russian roulette

Solution:

Use message classes:

class UserModel {
    id: string;
    name: string
}

class UserUpdatedEvent extends PostboyGenericMessage {
    constructor(data: UserModel) {
        super();
    }
}

// Type-safe subscription
postboy.subscribe(UserUpdatedEvent).subscribe(data => {
    console.log(data.name); // string type guaranteed
});

When NOT to Use Pub/Sub

Safety Rule:

Before publishing an event, ask three questions:

Are there subscribers besides me?
Could this event trigger unexpected side effects?
Can the problem be solved simpler via Input/Output?

Conclusion:

Pub/Sub requires discipline. It's nuclear energy: properly handled gives light, mishandled causes destruction.

Part 6: Epilogue — Cultivating Architecture

Software architecture isn't a blueprint carved in stone. It's a living garden where components, like plants, grow, intertwine, and occasionally require pruning. Pub/Sub isn't a magic staff, but a gardener's tool to manage chaos without suppressing it.

Three Rules of Evolution

1. Start Small

Don't attempt to implement event-driven architecture across the entire application at once. Begin with one module where dependencies already resemble a spiderweb. Replace the most problematic @Output() with an event — and watch how the architecture starts evolving on its own.

2. Refactor Only When Issues Arise

If components communicate through two initialization layers — leave them untouched. As Kent Beck said: "Don't solve problems you don't have". Pub/Sub is a remedy for complexity, not a preventive vitamin.

3. Choose Tools Matching Scale

A custom 20-line bus might be better than NgRx or postboy for a 15-component project. But when the system grows to 200+ modules — seek solutions with typing.

How to Start Tomorrow

1. Find a "Suspicious" Component

One that knows about five other modules. Replace one method call with an event.

2. Document Contracts

Create an events folder with message classes. Even if using string types — describe them in JSDoc.

3. Organize a "Silent Day"

Ban the team from using @Output() and mediator services for a week. You'll be surprised how quickly event-driven alternatives emerge.

Epilogue for Skeptics

"But events complicate debugging!" you'll say. Let me answer with a story: when we implemented event-driven architecture in our project, a new developer integrated a feature in one day that previously took a week. They simply found the right event in documentation and subscribed.

Yes, events mean responsibility. Yes, they require discipline. But they also grant freedom comparable to transitioning from monarchy to democracy. You stop being a god-architect and become a gardener who only sets growth rules.

Postboy — one tool in your shed. You might choose NgRx, a custom bus, or something else. The essence isn't the library, but the paradigm shift: *stop coupling components and start describing their interaction as a contract between equals
*.

Final Tip. Next time you see a chain of three @Output()s — imagine it's a weed. Uproot it, plant an event, and watch the architecture blossom.

P.S. Postboy documentation — here. But if you prefer to write your own EventBus, I hope this treatise inspires your heroic feat. Happy coding!

C# vs Angular: Universal Principles of Dependency Injection

Art Stesh — Sat, 03 May 2025 14:00:00 +0000

Introduction

Dependency Injection (DI) is a concept so deeply ingrained in everyday programming practices that ignoring it could almost be considered a cardinal sin, on par with neglecting version control. But why has DI become so crucial?

DI is one of the key principles enabling the creation of flexible and maintainable applications. The philosophy behind it revolves around freeing code from unnecessary details that tightly couple logical components. Components no longer depend on specific implementations of other parts of the system—they simply declare their needs, and DI provides the required dependencies.

The goal here is not just to master a trendy technology but to explore a universal architectural tool whose concepts transcend different ecosystems. Studying DI across multiple languages and environments not only deepens your understanding of the concept itself but also broadens your perspective on system design. You’ll come to realize that, despite syntactic differences, fundamental ideas converge toward the same architectural goals.

Who will benefit from this article? If you’re already familiar with .NET’s IServiceCollection but have always wanted to understand Angular’s Injectors, you’re in the right place. Conversely, if you write TypeScript code but the term "Transient" leaves you puzzled—welcome aboard. We’ll explore how similar concepts adapt to two different worlds and why studying both ecosystems will help you design better applications.

The aim of this piece is to demonstrate that the fundamental principles of DI remain consistent regardless of framework popularity or language-specific syntax. In short, you’ll see how elegant ideas underpin technologies as diverse as C# and Angular.

What Is DI? A Unified Philosophy

Dependency Injection may seem complex at first glance, but its "magic" boils down to a simple idea: let a specialized mechanism handle the creation and management of dependencies in your application. This relieves the code of unnecessary coupling, making the application significantly more flexible and testable.

Why Reduce Coupling?

A primary goal of DI is decoupling. Application components no longer rigidly depend on one another. Instead, they work with abstractions, and concrete implementations are dynamically supplied. Remember the golden rule of good architecture: depend on interfaces, not concrete classes.

Reduced coupling means components are easier to test (dependencies can be replaced with mocks). It also simplifies extending functionality: you can swap one implementation for another without rewriting old code—just register the new dependency. This is especially important in large applications where changes require careful validation and minimal side effects.

Similarities in C# and Angular

Here’s the interesting part. At first glance, C# and Angular seem like entirely different technologies: strict, OOP-oriented C# versus Angular’s modular, declarative approach. Yet both systems understand and support DI in the same way, proving the universality of this philosophy.

At the core of DI in Angular and C# lies the same key idea: inversion of control. The architectural magic in both revolves around a "dependency container"—a mechanism that handles object creation, configuration, and management.
Angular uses a powerful system of "injectors," while C# relies on IoC containers (Inversion of Control).

Additionally, both approaches clearly recognize dependency lifecycles, offering flexibility: from objects created anew each time to Singleton implementations that persist for the application’s entire lifespan.

DI in C#: Runtime Injection Flexibility

In the .NET ecosystem, DI centers on the IServiceCollection interface for registering dependencies and the DependencyResolver mechanism for retrieving them. Registered dependencies become automatically available, eliminating the need to manually specify how each object is created. Injection can occur via constructors, methods, or properties—giving you full control over how and where dependencies integrate.

Why is this useful? Constructors suit mandatory dependencies, methods work for optional ones, and properties enable dependencies relevant only at specific times. All you need to do is configure the DI container correctly.

IoC Containers and Service Lifetime

A major strength of DI in .NET is lifecycle management (Service Lifetime). Using Transient, Scoped, and Singleton, you define how long an object exists and how often it’s created.

Transient: A new object is created each time it’s requested. Ideal for lightweight, "disposable" dependencies.
Scoped: An object is created once per request or application scope. Useful for database contexts or related data within a single request.
Singleton: An object is created once and persists for the application’s lifetime.

Configuring DI in ASP.NET Core

The beauty of DI in .NET lies in its simplicity. The ConfigureServices method registers dependencies in the container, making them available throughout your application.

public void ConfigureServices(IServiceCollection services) { 
   // Register dependencies with different lifetimes 
   services.AddTransient<IMyTransientService, MyTransientService>(); 
   services.AddScoped<IMyScopedService, MyScopedService>(); 
   services.AddSingleton<IMySingletonService, MySingletonService>(); 
}

Demonstration of Usage

As a mini-example, let's demonstrate the use of some already registered dependency in a controller.

public class MyController {
   private readonly IMyService _myService;

   public MyController(IMyService myService)
   {
      _myService = myService;
   }

   public string GetMessage()
   {
      return _myService.GetGreeting();
   }
}

The controller here focuses only on its task, while the creation and management of IMyService remains the responsibility of the DI container.

DI in Angular: Declarative Approach with Metadata Binding

Dependency Injection (DI) in Angular is a fundamental part of its architecture, making applications modular, flexible, and easily extensible. If you work with Angular, DI will be your constant companion—it ensures that components and services interact simply, clearly, and without surprises.

Basics of DI Mechanism in Angular

Angular uses a powerful and declarative DI system based on three main pillars: Injectors, Providers, and Injection Tokens.

Injectors — the foundation of the entire system, a repository that manages the creation and provision of dependencies. It handles all the "heavy lifting," leaving you only with configuration.
Providers — a way to instruct Angular on how to create or provide a dependency. Here, you declare: "for this interface or token, use this class or value."
Injection Tokens — a solution for cases where no existing interface or class is available. They allow the use of arbitrary identifiers for dependencies.

Providers: Root, Module, and Component-Level Scopes

The flexibility of DI in Angular is achieved through different provider visibility levels. Depending on the scope, you can specify:

root — the provider becomes available application-wide. Ideal for global services used everywhere.
module — the provider is limited to a specific module. Useful for services required within a particular feature or application section.
component-level — creates a unique dependency instance for each component. This enables data and state isolation between components.

For example, you can register a provider globally via @Injectable({ providedIn: 'root' }) or bind it to a component using the providers array in @Component.

Using Decorators and Metadata

Angular ensures dependency configuration remains declarative and intuitive. Decorators like @Injectable or @Inject explicitly "mark" what Angular needs to operate.

The @Injectable decorator indicates that a class can be used as a dependency and specifies its registration scope. For greater flexibility, @Inject allows explicit token or provider specification at injection points.

Dependency injection in a class is straightforward:


@Component({
    selector: 'app-example',
    templateUrl: './example.component.html',
    providers: [ExampleService]
})
export class ExampleComponent {
    constructor(private exampleService: ExampleService) {
        console.log(this.exampleService.getData());
    }
}

IoC Containers, C# in Angular

The DI mechanism took care of initialization and passed the ready-made dependency to the component.

Unified Principles

When it comes to Dependency Injection, it's surprising how similar the approaches are in seemingly different technology stacks like Angular and C#. Despite the differences in ecosystems and languages, both tools use unified architectural principles for building applications. Let's examine the key points.

IoC (Inversion of Control)

The core idea of DI is the inversion of control (IoC). The traditional approach assumes that a class itself creates instances of its dependencies. DI changes the rules: control is now delegated to the container.

In Angular, this task is handled by the Injector. It determines what, when, and where to create, ensuring components or services receive only ready-made dependencies. The code remains simple and isolated from infrastructure details.
In C#, the IoC container plays a similar role. Through it, you declare dependencies (e.g., using IServiceCollection), and the system handles their creation.

This transfer of control simplifies both code writing and architectural changes: classes become independent of implementation details.

Scopes (Lifespan)

Both Angular and C# DI provide flexible mechanisms for defining object "lifespans," helping manage state and limit dependency scopes.

Angular offers three main scopes: root (global), module/component, and factory (local). The system automatically creates new instances or reuses existing ones based on the specified level.
C# uses Transient, Scoped, and Singleton lifetimes. These determine whether a new object is created each time, preserved within a request, or maintained as a single application-wide instance.

Angular Scope	C# Lifetime
`root`	Singleton
`component`/`module`	Scoped
`factory`	Transient

Motivation and Testability

Both approaches agree on another point: Dependency Injection is key to testability. Simplifying dependency substitution allows testing classes or components in isolation.

Angular and npm libraries provide tools for mocking objects, replacing real dependencies with mocks to speed up testing and ensure determinism.
C# leverages mock objects and interfaces replaceable via the DI container in unit tests. Test implementations or libraries simulate any behavior.

Thus, DI in both technologies minimizes component coupling, enhances modularity, and accelerates the creation of quality tests.

Key Implementation Differences

Despite shared principles, DI implementations in Angular and C# differ in approach, tools, and philosophy. Each solution reflects its context: Angular focuses on client apps, while .NET targets web, desktop, and more. Let’s explore the details.

Resolvers and Dependency Types

A key difference lies in how dependencies are defined and registered.

Angular uses Injection Tokens extensively. These unique keys explicitly identify dependencies, crucial for architectures with multiple implementations of the same interface or when default types fall short.

Example:

  const MY_TOKEN = new InjectionToken<string>('myToken');
  providers: [
    { provide: MY_TOKEN, useValue: 'Angular DI' }
  ]

This strict, flexible approach prevents runtime errors.

C# relies on interfaces and their implementations. Dependencies are registered as interface-to-class mappings:

  services.AddTransient<IMyService, MyService>();

The process is linear, without tokens or additional layers.

Areas of DI Application

At the level of DI application, it becomes evident how Angular and C# differ in their approaches.

In Angular, DI is deeply integrated into the architecture. Developers cannot bypass it during development. Services, components, and even directives interact through injections, making DI an inseparable part of the ecosystem. The framework is fundamentally structured around this mechanism.
In C#, DI is more of a recommended practice than a built-in language or platform feature. Developers can build projects without DI containers. However, most modern .NET frameworks (e.g., ASP.NET Core) include native DI support.

This distinction determines how systematically DI is adopted: Angular enforces a universal model, while C# offers flexibility.

Dependency on Build/Runtime Execution

Another conceptual difference lies in how dependencies are handled during compilation versus runtime.

In C#, dependencies are resolved dynamically at runtime. Developers define dependencies in the IoC container, and the system instantiates objects on the fly. This can lead to runtime errors (e.g., misconfigured or missing dependencies). While flexible, this approach demands vigilance.
In Angular, DI is strictly controlled at compile time due to strong typing. Tools like Injection Tokens, decorators, and Angular’s compilation process detect DI issues before the app runs. For example, omitting a provider for a token will prevent the app from compiling.

This makes Angular more rigorous, reducing runtime error risks. In contrast, C#’s runtime flexibility is advantageous for dynamic or complex scenarios.

While Angular and C# share DI’s core architectural principles, their implementations diverge contextually. Angular emphasizes systematicity and safety through tokens, strong typing, and compile-time checks. C# prioritizes flexibility and dynamism, typical of a general-purpose platform. Recognizing these differences helps select the right tool for specific tasks.

Benefits of Learning DI in Both Ecosystems

Mastering diverse approaches and tools builds confidence in designing and implementing complex systems. Beyond technologies, it hones critical skills.

Expanding Professional Horizons and Architectural Skills

Understanding DI across ecosystems reveals multiple solutions to the same problem. It deepens knowledge of patterns like IoC (Inversion of Control), modularity, and loose coupling. Working with Angular and C# immerses developers in two domains: client-side apps with rich UIs and server-side systems with intricate logic.

This knowledge extends beyond DI:

Recognizing when strict typing limits design freedom versus preventing errors.
Evaluating trade-offs between runtime and compile-time solutions.
Selecting optimal architectures for specific projects.

Designing Cross-Platform Architectures

In an era where client-server boundaries blur, DI expertise in Angular and C# enables seamless cross-platform solutions.
Examples include:

A .NET backend with REST API paired with an Angular frontend, ensuring clear separation of concerns and unified dependency handling.
Complex apps (e.g., backend serving web, desktop, and mobile) that avoid redundancy through combined approaches.

The result is loosely coupled, testable, and extensible architectures. Such systems are easier to maintain, scale, and hand over to teams.

Advancing Testing and Design Practices

Testability is a cornerstone of modern development. DI simplifies testing by decoupling components. Learning DI logic is pivotal for designing testable systems and writing effective tests.

Mastering DI in Angular and C# transcends library or tool proficiency. It cultivates professional skills: architectural design, testing, and adapting best practices across platforms. Developers gain a holistic perspective, enabling them to combine strategies and solve real-world challenges effectively.

Conclusion

Dependency Injection (DI) is more than just a tool—it’s a development philosophy that remains consistent whether you’re working with Angular or C#. Principles like separation of concerns, inversion of control, and testability create flexible architectures and maintainable code.

When working with both ecosystems, it becomes clear that DI universally strives for the same goals but achieves them differently. Angular impresses with its strict typing and deep integration, while C# excels in flexibility and architectural freedom. It’s in these nuances that the magic of working across platforms truly lies.

Final Thoughts

There’s a simple truth: the more we study and compare technologies, the better we understand their strengths and weaknesses. DI teaches us to embrace complex systems and experiment with new approaches. There’s no one-size-fits-all formula here—everything depends on your tasks, vision, and the ecosystem you operate in.

How does your experience with DI in C# differ from Angular? Where do you feel more freedom, and where do you encounter rigidity? Your insights are invaluable to the discussion.

If you have ideas or topics you’d like to explore, don’t hesitate to share them. Dialogue strengthens us, and your experience could spark new discoveries.

Thank you for reading! I’d love to hear your thoughts, questions, or suggestions—not just about DI, but about architecture in general. Let’s move forward together, advancing our knowledge and professional skills.

Why you'll never learn all the frameworks

Art Stesh — Mon, 28 Apr 2025 05:45:53 +0000

When was the last time you felt like a real development expert? Personally, I — somewhere at the moment when I first wrote a program that ended without errors. Programming is like an endless renovation of the house you already live in. _ Even yesterday, you thought that a new roof would be the solution to all your problems. And today it turned out that there were windows with automatic heating, and without them the house is not a house at all. And, of course, all the neighbors have already installed such devices._

When I first started writing code, it seemed that everything was arranged quite simply. I've learned the language, figured out a couple of libraries, and written a few algorithms, and you're already a great programmer. But over time, this feeling disappeared. Now I go to Telegram or read another tech blog, and it seems to me that everyone is discussing something that I haven't figured out yet: a new framework like Bun has been released.js, updated language specification (JavaScript ECMAScript 2024), released Webpack 6. And someone managed to test some new linter. And against the background of these bright changes, I look at my work project and wonder: and whether I can integrate all this ultra-modern stack into my projects, and whether it is necessary at all.

Programmers as athletes

One of the most challenging(and interesting) aspects of our profession is its inability to stop. If there's one constant in development, it's the speed of change. We live in an industry growing faster than any other — every month:

New tools are coming (like Vite && TurboPack),
Someone finds problems in existing approaches (for example, problems with the scalability of old monoliths),
And someone offers fundamentally new architectural solutions (such as the popularization of microservices or "serverless-first").

These innovations make us part of incredible progress, but also part of the race. Only this race often turns out to be far from about technology — it is about ourselves. It's like you were comparing yourself yesterday and asking the same questions: How much more do I need to know? How quickly can I learn a new technology? Will I be able to understand in a week what others have been studying for months?

And this constant comparison — as in professional sports-can either stimulate or destroy success.

Yes, we live in a world where we are always under pressure from deadlines and new frameworks. But admit it: it's cool to argue with your colleagues about whether your project needs a new "lightweight" tool that you'll regret for the next quarter.

Framework of the week. Or how technology is moving faster than us

Every month there are not just new technologies, but "blindingly new" ones — so much so that it seems as if your project is doomed without them. Everyone has examples:

Someone implemented Next.js also claims that without server-side rendering (#SSR), modern sites are no longer relevant.
Someone switched to SvelteKit and said that its performance impact surpassed the project on React.
Or remember the hype around Deno, which was supposedly supposed to replace the good old one Node.js. Do you use it?

New 'tech killers' appear faster than you can finish your coffee and open the tab with their dock. And by the time you take the last sip, other material is already appearing with screaming headlines about the fact that there was an even more ultimatum competitor for the "killer". Remember how NoSQL replaced all these outdated and outdated relational database approaches, creating a beautiful world without PostgeSQL/MSSQL/...? And how did sharp Blazor destroy JS, TS, and indeed all front-end development?

The volume of docs of new frameworks released in 2024 cannot be reread in a year, and none of us knows them all. No one. Even the most popular tech bloggers who give great conference presentations don't have time to jump on every tech train.

The life of a programmer is a constant choice: what to learn and what to skip. Kubernetes looks like a complex monster, but do you need it in your real work? Maybe right now it's easier to focus on deepening the knowledge in your stack or on mastering TypeScript?

At some point, I realized that knowledge overlaps in layers. If you have a good base — it won't be difficult for you to understand new tools, because the concepts remain the same. It's funny, but the more experience you have in programming, the slower your knowledge starts to become outdated.

Pressure Formula: Why we always feel like we're falling behind

The key problem that most developers face is the perception of time. Deadlines are pressing on you. This is superimposed on the perception of learning: it seems to us that the new tools should be mastered immediately, because "this should have been done yesterday". And if you spend time on GitHub, Hacker News, or Reddit, there are all success stories around:

Someone launched a small software product that made millions.
Someone posted a library that collected tens of thousands of stars.
And someone implemented algorithms that you didn't even know in theory.

But this is an illusion. Real life isn't like that. No one posts GIFs as they spend 3 days trying to figure out why docker-compose doesn't work for them. No one posts about banging their head against the wall for 2 hours before the test database started. We only see the result, not the path. And we compare ourselves to this "edited image".

GitHub is like Instagram for programmers; only instead of beautiful photos, there are projects with perfect code that make you forget that real life is a little less glamorous. No one puts out stories "five hours of debugging, and the reason was in my cache".

In this race, it is important to understand one thing: this approach destroys everything. If you constantly run just to "catch up", then you will get tired faster than you will succeed.

How to handle this race

I don't think that any of the programmers can completely get out of this feeling. We will always be passionate about something, concerned about something in our work. But I've learned to treat it differently.

First — I don't compare myself to other people anymore. There is no "perfect engineer" position to strive for. Even if you meet a cool developer who created a bunch of libraries, they also started somewhere. His way is his way, and yours is yours.

Second — appreciate your progress. One of the main principles for me was the constant "recording of small victories". Yes, today I didn't learn a new library or implement a supernova tool, but I figured out another bug, optimized the module, or closed several tasks. This is already a reason to meet the needs.

Finally, the job of a programmer is more about curiosity than commitment. We don't have to "learn all the technologies" or "become the best at everything at once". We must always remain curious and explore the world. This is the best thing we can do for ourselves and this profession.

How to get out of the "race"

Do not rush to master everything at once. Add technologies to your list, but don't try to dive into every topic. New tools always seem irreplaceable, but usually only 10–20% of them actually become standards.
Compare yourself only with past experience. Have you learned how to use a new tool? Did you solve the problem easier? This is your progress.
Get inspired, but don't focus on other people's charts. Everyone has their own "race". Some people write neural networks by the age of 20, while others have a career built up by the age of 30–40, but it leads to a deep understanding of fundamental knowledge.
Learn the basics of. This will slow down the obsolescence of your knowledge. If you rely on the principles of development (SOLID, algorithms and data structures, asynchrony), then any framework will be much easier to master. After all, concepts don't change.

Instead of concluding

I like to think that programming is a profession in which you will learn and grow until the very end of life. It's a never-ending race with yourself. But it's not about being the best at some conferences or showing off in interviews. It's about asking yourself every day: "What new things can I understand and create?"

But if you're going to admit it's a race, then imagine that it's a race for fun and not to get to the finish line first. Look around you: you are a participant in an incredible marathon, in which it is not so much important for us to win, but to learn how to enjoy running.

Yes, we will always be a little behind reality, but this is not a reason to stop. After all, the best thing about this job is the learning process.
Everything you do is a step forward. As one of my colleagues said:

"If you still ask questions, it means that you continue to grow and learn — and this is the main sign of a good programmer".

# The Third Step Into the World of RxJS: Combining Streams in RxJS

Art Stesh — Sat, 19 Apr 2025 14:00:00 +0000

RxJS is a powerful tool, but it can also be tricky. Many beginners who have mastered basic operators like map, filter, and perhaps even take, start feeling confident. Then they encounter tasks where they need to combine multiple streams simultaneously... and that's where it all begins to fall apart. Panic sets in. Should you use combineLatest, forkJoin, merge, zip? What do you do when data arrives at different speeds? This material is for those feeling lost at this stage. Let’s calmly and methodically figure it out together.

Why Is This Important?

Your first challenge with combination operators is that they seem to speak their own language. If you think of an Observable as a stream of events, then combination operators are the conductors orchestrating multiple streams, aligning them in sync, and producing a "new melody."

Imagine a classic scenario: you're building a form in Angular, and you need to show a "Submit" button only when all fields are validated. Or you need to merge data from two APIs. These are typical use cases where combination operators become your main instrument.

When to Use Which Operator?

RxJS provides several tools to merge data from different sources. However, despite the abundance of articles on this topic, developers in real projects often misunderstand how to apply them correctly. Let’s examine the most popular combination operators with real-world examples.

Imagine this scenario:

Factory A produces components (e.g., every hour). This is one stream of data.
Factory B sends requests for components as they are ready for assembly. This is a second stream of data.
As operators, we need to organize the supply of components for assembly based on different conditions. Each RxJS operator dictates its own method for managing this process.

1. zip — "One to One"

The zip operator enforces strict synchronization. We wait for Factory A to produce a component and simultaneously for Factory B to request that specific component. Only then is the component passed for assembly. No component will be sent until a pair is matched: "ready component + request for the component."

When to Use:

Multiple streams logically depend on one another.
You need to ensure strict synchronization of streams in order.

Production Example:

Factory A produces components every 3 hours.
Factory B sends requests for components every 2 hours.

Outcome: Each pair of "component + request" is sent to assembly. If a component is produced before the request, it waits until a signal to dispatch it arrives.

Code Example in TypeScript:

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

// Factory A (produces components every 3 seconds)
const factoryA$ = interval(3000).pipe(map(i => `Component ${i + 1}`));

// Factory B (requests for components every 2 seconds)
const factoryB$ = interval(2000).pipe(map(i => `Request for Component ${i + 1}`));

// Combine one component from A with one request from B
zip(factoryA$, factoryB$).pipe(take(3)).subscribe(([component, request]) => {
  console.log(`${request} paired with ${component}`);
});

// Output:
// Request for Component 1 paired with Component 1
// Request for Component 2 paired with Component 2
// Request for Component 3 paired with Component 3

Performance of `zip`

The Number of Streams Matters:

zip can combine not just two but multiple streams. However, as the number of streams grows, performance can degrade because the operator has to monitor each stream and wait for values to align before producing a new combination. This is particularly noticeable when streams emit data at different rates or have delays.
Data Buffering:

If one stream produces values faster than another, zip will need to buffer these values (temporarily store them) until data from all streams is ready. This may require more memory when handling streams with uneven data flow. For instance, if one stream emits millions of items quickly, zip will buffer them until the corresponding data from the other streams arrives.

Pitfalls When Using `zip`

Sensitivity to Value Counts:

If streams emit a significantly different number of items, the operator will only work up to the point where one of the streams runs out of values. Any additional items from other streams will not be processed after one stream completes.
Compatibility with Infinite Streams:

If all input streams are infinite (e.g., interval or UI events) and there’s no mechanism to terminate them, the subscriber will never complete. This can result in memory leaks or hanging processes.

More Advanced Features of `zip`

Using a Transformation Function: By default, zip returns an array of synchronized values, but you can specify a function to immediately shape the result into the desired format. Example:

import { zip, of } from 'rxjs';

const stream1$ = of(10, 20, 30);
const stream2$ = of(1, 2, 3);

zip(stream1$, stream2$, (x, y) => x * y).subscribe(result => {
  console.log(result); // 10, 40, 90
});

// Output:
// 10
// 40
// 90

Recommendations for Use

Add Protection Against Infinite Streams: Use limiting operators (take, takeUntil) to prevent application hangs.
Monitor Stream Frequencies: If one stream is significantly "slower" than another, calculate delays properly to avoid inefficient waiting. In some cases, it might be better to replace zip with other operators like combineLatest.
Consider Completion Behavior: Explicitly manage completion or handle cases where streams emit different amounts of items.

zip isn't just an operator that "stitches" streams together. It's a synchronization tool tailored for strictly ordered scenarios where the structure of the data between streams matters. However, keep in mind its sensitivity to completion, buffering, and potential delays. To effectively utilize zip, it’s crucial to understand each stream's behavior and account for their limitations.

2. combineLatest — "Working with What's Available"

combineLatest focuses on the current state of multiple streams. It emits a value only after all its sources have produced at least one value, and then updates anytime any of the streams emits new data.

combineLatest waits for the first value from all sources before starting to work. Then, it emits a new combination of data whenever any of the streams produces updated data. This means that for every new request from Factory B, the current latest component from Factory A is used immediately.

When to Use:

You need to track the state of multiple sources simultaneously.
Tasks related to user input or application states.

Output: As soon as there’s a new update from B (a request), the current state of a component from A is taken and dispatched immediately.

TypeScript Code Example:

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

// Factory A (components every 3 seconds)
const factoryA$ = interval(3000).pipe(map(i => `Component ${i + 1}`));

// Factory B (requests every 2 seconds)
const factoryB$ = interval(2000).pipe(map(i => `Request for Component ${i + 1}`));

// Each new request uses the latest state of components
combineLatest([factoryA$, factoryB$]).pipe(take(4)).subscribe(([component, request]) => {
  console.log(`${request} paired with ${component}`);
});

// Output:
// Request for Component 1 paired with Component 1
// Request for Component 2 paired with Component 1
// Request for Component 3 paired with Component 2
// Request for Component 4 paired with Component 2

Performance of `combineLatest`

Buffering and Memory:

combineLatest keeps the latest value from each source in memory. In most cases, this doesn’t impose serious constraints, but for streams emitting large objects (e.g., arrays or JSON data), it might impact performance.
Handling "Noisy" Streams:

If one stream emits data too frequently (e.g., a mouse movement stream), combineLatest will frequently recalculate the result, even if the other stream remains unchanged.

Recommendation: For noisy streams, use operators like throttleTime or debounceTime to suppress excess events and avoid processing overload.

Pitfalls of `combineLatest`

Unpredictable Behavior with Missing Values:

If at least one of the streams hasn’t emitted a value, combineLatest will not publish anything. This means that a stream that always "stays silent" can block the entire operation. This can be unexpected for beginners.
Performance with a High Number of Streams:

combineLatest can work with multiple streams, but performance drops significantly when trying to combine dozens of them. The reason is that, with each change, all combinations must be recalculated and reassembled.
Unexpected Failures in Real Applications:

In applications where data comes from external APIs, combineLatest can stop working unexpectedly if one API source suddenly goes silent. For example, if a service returns an HTTP error, that stream completes, making the combined stream useless.
Solution: Add error handling using operators like catchError.

Hidden Features of `combineLatest`

Using Custom Transform Functions:

Instead of receiving an array of values, you can transform the result directly using a custom function.

Example:

import { combineLatest, of } from 'rxjs';

const width$ = of(100);
const height$ = of(200);

combineLatest([width$, height$], (width, height) => width * height).subscribe(area =>
  console.log(`Area: ${area}`)
);

// Output:
// Area: 20000

combineLatest is an incredibly useful operator for working with data streams where the current state of all sources is essential. However, its use requires careful attention: pitfalls such as delays, inability to emit when a stream remains silent, or performance limitations can unexpectedly lead to bugs. To avoid such issues, always assess the emission frequencies of streams, their completion, and start with initial values (startWith). This will make your applications reliable and predictable.

3. forkJoin — "All at Once"

forkJoin takes multiple streams, waits for all of them to complete, and then returns a single final value. If even one stream doesn’t emit or doesn’t complete, no result will be emitted.

forkJoin waits for ALL streams to complete and only then provides their latest results as a final list. In production terms, this means we’ll wait for Factory A to finish producing ALL components and for Factory B to send all the requests before processing everything at once.

When to Use:

You need a single result from multiple sources.
Ideal for API requests, when you need to wait for all responses.

Production Example:

Factory A finishes producing all components.
Factory B sends all requests.

Output: Processing begins only after both factories complete their operations.

TypeScript Code Example:

import { forkJoin, interval } from 'rxjs';
import { delay, take, map } from 'rxjs/operators';

// Factory A (component production)
const factoryA$ = interval(3000).pipe(map(i => i + 1), take(3));

// Factory B (requests for components)
const factoryB$ = interval(2000).pipe(map(i => i + 1), take(2));

// Start processing only after both streams complete
forkJoin([factoryA$, factoryB$]).subscribe(([details, requests]) => {
  console.log(`Processed data: ${details} components ready for ${requests} requests`);
});

// Output:
// Processed data: 3 components ready for 2 requests

Conclusion:

forkJoin is perfectly suited for tasks where only completed data matters. For instance, it’s great for batch processing after preparation.

Performance and Optimization

Issue with Large Streams: If one of the attached streams generates a large amount of data before completing, it can place significant load on memory since each stream allocation requires resources until completion.

Pitfalls of `forkJoin`

Not Suitable for Infinite Streams:

If any of the streams in the set are infinite (e.g., fromEvent, interval), forkJoin will never emit anything. This is not an error but can be an unexpected behavior.
Challenges with Error Handling:

One major challenge is that if any stream throws an error (error), the results of all other streams are lost. This might be undesirable in scenarios where partial success is significant.

Hidden Features of forkJoin
Using an Object Instead of an Array:

forkJoin supports object syntax, which can be convenient for working with REST APIs or associative structures.

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

   // Simulating three data sources as objects:
   const user$ = of({ id: 1, name: 'Ivan' }).pipe(delay(1000));
   const orders$ = of([{ id: 101, total: 300 }, { id: 102, total: 450 }]).pipe(delay(1500));
   const notifications$ = of(['Notification 1', 'Notification 2']).pipe(delay(2000));

   // Using an object instead of an array:
   forkJoin({
     user: user$,
     orders: orders$,
     notifications: notifications$,
   }).subscribe(result => {
     console.log('Merged data:', result);
   });
   // Output:
   // Merged data:
   // {
   //   user: { id: 1, name: 'Ivan' },
   //   orders: [{ id: 101, total: 300 }, { id: 102, total: 450 }],
   //   notifications: ['Notification 1', 'Notification 2']
   // }

Working with objects instead of arrays makes the code more readable, especially in scenarios involving different types of data (e.g., responses from various APIs). Instead of referencing values by array indexes (result[0], result[1]), you can refer to the object keys (result.user, result.orders).

forkJoin is an excellent tool for managing parallel processing and combining results. However, its strict requirement for stream completion imposes some limitations. To avoid unexpected errors, always consider stream completion, use error handling (catchError), and add constraints (take, timeout). This approach will allow you to use forkJoin reliably and effectively in most scenarios.

4. merge — "Send Everything Immediately"

merge combines streams but emits items as soon as they arrive. Unlike combineLatest, it doesn’t wait for all sources.

merge simply merges all events from the streams into a single flow and emits them in the order they are received. In production, this means that as soon as a component is ready or a request arrives, it is immediately processed, without concern for synchronization.

When to Use:

You need to combine events from multiple sources, but the order of their appearance isn’t important.

Production Example:

Factory A produces components every 3 hours.
Factory B sends requests every 2 hours.

Output: Any event from A or B is processed immediately.

TypeScript Example:

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

// Factory A (producing components)
const factoryA$ = interval(3000).pipe(map(i => `Component ${i + 1} is ready`), take(3));

// Factory B (requests for components)
const factoryB$ = interval(2000).pipe(map(i => `Request for Component ${i + 1}`), take(2));

// All events are processed in order of arrival
merge(factoryA$, factoryB$).subscribe(event => {
  console.log(event);
});

// Output (example):
// Request for Component 1
// Component 1 is ready
// Request for Component 2
// Component 2 is ready
// Component 3 is ready

Working Features

Simultaneous Merging of Multiple Streams:

Unlike zip or forkJoin, merge does not depend on the sequence or frequency of data emissions from different streams. It simply publishes values as soon as they arrive.
Does Not Wait for All Streams to Complete:

merge continues to operate as long as at least one source stream remains active. The resulting stream completes only when all input Observables have completed.
Stream Competition:

If values from multiple streams are emitted at the same time, they will be processed in the order they actually arrive (by timestamp).
Operator Parameters:
- concurrent (default is Number.POSITIVE_INFINITY): This parameter determines the maximum number of streams that can be processed simultaneously. If the specified number is exceeded, the remaining Observables will wait for the currently active ones to complete.

Pitfalls

Overload When Working with Infinite Streams:

If merge is merging infinite streams (like interval, fromEvent) that generate data too frequently, it can cause processing overload. This is especially critical when multiple such "noisy" streams are merged.

Solution: Use event frequency limiting operators like throttleTime, debounceTime, or manually set the concurrent parameter to reduce the load.
Premature Stream Closure:

If all input streams complete but one of them throws an error (error), merge will terminate with an error, and the data from other completed streams will be lost.

Solution: Use catchError to handle errors in each stream independently without terminating the main stream.
Complexity in Handling Concurrent Streams:

With a large number of streams operating simultaneously, the order in which merge outputs the data may become unpredictable. While logical, this behavior can cause confusion if you expected the values to appear in the same order as with concat.

Interesting Aspects of `merge`

Handling the Processing Order Using concurrent: The concurrent option allows you to limit the number of streams processed simultaneously. This is useful when combining resource-heavy processes like HTTP requests. Example:

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

   const stream1$ = of('A').pipe(delay(1000));
   const stream2$ = of('B').pipe(delay(1500));
   const stream3$ = of('C').pipe(delay(500));

   merge(stream1$, stream2$, stream3$, 2).subscribe(console.log);

   // Output:
   // A
   // C
   // B

Explanation: Here, only two streams will be processed simultaneously. As soon as one finishes, the next stream starts, maintaining the queue.

Performance

Parallel Performance:

merge excels at performance because it processes data from all sources in parallel. This makes it an ideal choice when there are no constraints on the order of event processing.
Resource Intensity of Streams:

Streams generating a large quantity of data can strain memory and CPU because each stream operates independently. It’s important to consider the concurrent parameter to manage simultaneous execution.
Sensitivity to Event Frequency:

If streams are "noisy" (e.g., a stream generating mouse movement events), the resulting merged stream may become overloaded. Therefore, it is important to use limiting operators to optimize the load.

The merge operator is simple and versatile yet packed with powerful functionality. It is perfectly suited for tasks requiring parallel data processing, but it demands careful resource management when dealing with frequent or infinite streams. Use it when event order doesn’t matter, and always optimize load by limiting event frequency and the number of simultaneously processed streams (concurrent).

4. concat — "First Come, First Served"

The concat operator in RxJS offers a simple and intuitive way to process multiple streams sequentially, one after another. Unlike merge, which works in parallel, concat processes the next stream only after the previous stream has completed. It can be thought of as a "queue" of Observables.

Factory B will only start sending requests after the production of components in Factory A is fully completed.

When to Use:

When you need to ensure the sequential execution of streams without risking data overlap.
For tasks where data logically depends on one another (e.g., step-by-step processing, sequential API requests).
When simultaneous data processing (like in merge) is unnecessary or unacceptable.

Production Example:

Factory A produces 3 components (each taking 3 hours to complete).
Factory B starts sending requests only after Factory A has finished production.

TypeScript Code Example:

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

// Factory A (production of components)
const factoryA$ = interval(3000).pipe(
    map(i => `Component ${i + 1} is ready`),
    take(3) // Produces 3 components
);

// Factory B (processing requests for components)
const factoryB$ = interval(2000).pipe(
    map(i => `Request for component ${i + 1} processed`),
    take(2) // Processes 2 requests
);

// Run production and requests sequentially
concat(factoryA$, factoryB$).subscribe(event => {
    console.log(event);
});

// Expected Output (approximate, considering timing):
// After 3 seconds: Component 1 is ready
// After 6 seconds: Component 2 is ready
// After 9 seconds: Component 3 is ready
// After 11 seconds: Request for component 1 processed
// After 13 seconds: Request for component 2 processed

Working Features

Strict Sequence:

The main feature of concat is the strict sequential order of processing streams. First, data from the first Observable is processed, then, after it completes, the next stream is activated, and so on.
Waits for Completion:

Each stream must complete (complete) before the operator moves to the next one. This makes concat particularly useful for creating chains of sequential operations.
Blocking by Infinite Streams:

If there’s an infinite stream (like interval or fromEvent), it will block the execution of the rest of the chain since it will never complete.
No Limit on Number of Streams:

concat can combine any number of Observables, provided either through an array, manually, or by using the arguments operator.

Pitfalls

Using Infinite Streams:

If one of the Observables in concat generates infinite data (interval, fromEvent, etc.), the next stream will never be triggered because the current one won’t complete.

Solution: Use limiting operators like take or takeUntil to ensure the infinite stream eventually completes.
Error Handling:

If one of the Observables throws an error (error), the entire concat chain will terminate with an error, and no subsequent streams will be executed.

Solution: Handle errors locally using catchError.
Complexity in Handling Competition:

While concat ensures strict order of execution, if you mismanage resource usage or processing delays, infinite streams and unexpected competition between sources may occur. For such cases, other operators like merge or additional custom handling might better suit your needs.

The concat operator is an excellent choice when you need to process streams sequentially and ensure reliable order of execution. Despite its simplicity, it is particularly powerful in scenarios where order and completion are critical. To avoid pitfalls like infinite streams or early termination on errors, always control stream completion and implement proper error handling for a smooth and predictable sequence.

Interesting Aspects

Optimizing Sequential Data Loading:

concat is often used to manage a chain of dependent requests. For example, first obtaining an authorization token and then using it to make API requests.

Example:

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

const authToken$ = of('Token received').pipe(delay(500));
const fetchData$ = of('Server data loaded').pipe(delay(1000));

concat(authToken$, fetchData$).subscribe(console.log);

// Output:
// Token received
// Server data loaded

Performance

Clear Sequential Efficiency:

concat places no extra load on the scheduler as it only manages values from one active stream at any given time.
Delays with Large Streams:

Performance can decrease if the initial streams contain a large amount of data or take too long to execute, as subsequent Observables must wait for their completion. This is especially important to consider when working with streams in UI components.

The concat operator is a powerful tool for sequentially working with streams. It is especially useful if the order of emissions is critically important or if one task must be fully completed before proceeding to the next. However, when using it, it is essential to consider stream completion constraints, proper error handling, and potential delays caused by large or slow streams. Proper use of concat makes working with sequential data intuitive and manageable.

Operator	Features
`combineLatest`	Combines the latest values from all streams. Waits for all streams to emit at least one value.
`zip`	Groups values from streams together (one value from each).
`concat`	Processes streams sequentially (one starts only after the previous one completes).
`forkJoin`	Waits for all streams to complete, then returns the results.
`merge`	Processes data in parallel without waiting for stream completion.

Conclusions

We’ve covered the foundational operators and succeeded in our first experiments with RxJS. Ahead lie more complex but fascinating challenges where your knowledge of combination operators will become an essential skill. The foundation is already set: we’ve explored how to use zip and other operators for data synchronization. But knowledge is only half the battle. True understanding comes when you start applying these tools in real-world projects.

Think about all the complex scenarios where data streams may depend on each other: forms with multiple validations, interactions between API requests, or even time management in games. By understanding how to "orchestrate" streams in RxJS, you won’t just solve problems—you’ll discover entirely new, elegant ways to approach them. And this is just the beginning.

Every step you take in learning RxJS brings you closer to mastering asynchronous programming. Don’t hesitate to experiment and ask questions. It’s much easier to learn from small examples than to tackle large projects where every stream feels like a mini-puzzle.

Now it’s time to set new goals, explore different operators, and find what works best for your scenarios. RxJS may seem complex at first, but with every new challenge, it will reveal itself as a powerful tool. Let your journey through stream combination lead you confidently toward true expertise.

The next step awaits—keep going and continue to unlock the world of reactive programming. Good luck!

How to Defeat the Chaos of Manual Backend Contracts: Automating Models in Angular

Art Stesh — Mon, 14 Apr 2025 14:36:00 +0000

Greetings,

today I decided to talk about how automatic generation of models and services on the frontend can simplify the development process.

The problem of interaction between the frontend and backend is one of the biggest headaches for developers. Data format mismatches, outdated documentation, and integration errors inevitably slow down the development process. However, modern approaches make it possible to minimize these challenges.

One technology that has proven effective for such tasks is automatic code generation from OpenAPI specifications.

The Problem with Contracts: Why "Gentlemen’s Agreements" Always Lead to Pain

In the early stages of developing small applications, frontend and backend teams often communicate something like: “Well, let’s agree like normal people! The JSON will look like this, ok?” — “Ok.” It sounds nice, like a promise to meet at the same place in five years.

A month later — the frontend is already tied to the old contract, while the backend decided to "slightly improve" things, but no one can dispute the original agreements anymore because, of course... they weren’t written down. This leads to a classic scenario:

Backend: “Well, you know how we do things in REST, we replaced userId with clientUuid and moved personal data into a separate model. It's all logical anyway.”

Frontend: sounds of panic and frustration

QA: “The backend works perfectly, I’ve logged 100,500 bugs against the frontend team.”

Manager: “My presentation is in two hours; is it really that hard to fix this?”

It's at moments like these when you realize: it’s better to spend a couple of hours generating contracts than endlessly "syncing up" with another developer on Slack.

Here are the main problems teams face:

Inconsistent request and response formats. The API is constantly expanding, and the gap between the frontend and backend continues to grow.
Unpredictable changes. Backend developers add functionality, breaking the frontend — often unintentionally.
Lack of up-to-date documentation. No one informs the team in time when an endpoint's behavior is modified.
Manual validation. Sending requests manually, analyzing errors — all of this wastes an enormous amount of time.

The Core Idea: Automation Instead of Routine

When the frontend is developed based on a backend with a defined API (e.g., OpenAPI), it's entirely possible to eliminate the manual creation of interfaces, services, and data modeling. Instead, everything is done automatically using code generators.

Why Is This Important?

Data Accuracy: Automatic generation of interfaces eliminates the chance of type errors.
Faster Development: Instead of creating models manually, developers receive ready-to-use code immediately.
Easier Updates: When a backend contract changes, it’s enough to update the OpenAPI specification and regenerate the files — everything on the frontend will update automatically.

4. Reduced Developer Workload: Teams can focus on functional logic instead of wasting time syncing data.

How to Implement This in Projects?

1. Swagger Integration and Documentation Generation

The first key task is to make the API “self-explanatory.” This is important for the frontend (there’s no time to dig into the backend code to figure out how to send a request) and for the testers.

We set up automatic documentation generation, which is hosted on Swagger UI at the /api-docs endpoint.

In C#, connecting it comes down to installing the


 and

 ```Swashbuckle.AspNetCore.Annotations```

 libraries and adding a few lines of code in Program.cs (or Startup.cs):



```textmate
services.AddSwaggerGen(c =>
        {
            c.SwaggerDoc("v1", new OpenApiInfo { Title = "Api", Version = "v1" });
            var currentAssembly = Assembly.GetExecutingAssembly();
            var xmlDocs = currentAssembly.GetReferencedAssemblies()
                .Union(new[] { currentAssembly.GetName() })
                .Select(a => Path.Combine(Path.GetDirectoryName(currentAssembly.Location), $"{a.Name}.xml"))
                .Where(f => File.Exists(f)).ToArray();
            xmlDocs.ToList().ForEach(d =>
            {
                c.IncludeXmlComments(d);
            });
        });
        ...

app.UseSwagger();
app.UseSwaggerUI();

For other programming languages, integrating Swagger is not a challenge — the vast number of examples available online for practically every use case makes it quick and easy to set up in nearly any tech stack.

Main Advantages of Swagger:

A convenient visual interface for exploring endpoints.
Easy integration into CI/CD for generating up-to-date documentation.
Enables simple access for all team members (frontend, testers, analysts) to the current state of the API.

2. Generating Frontend Models with `ng-openapi-gen`

Considering that the foundation of our frontend is Angular, for generating models and services based on OpenAPI schemas, we chose the library ng-openapi-gen. This tool, in a semi-automated manner, creates Angular services and models from the OpenAPI specification, freeing developers from the need to manually describe data structures and requests.

Preparing the OpenAPI Specification

To manage the generation process, a json file is created (in any location), one for each data source (the application can interact with multiple different APIs):

{
  "$schema": "../../../../node_modules/ng-openapi-gen/ng-openapi-gen-schema.json",
  "input": "https://localhost:5001/swagger/docs/v1/backend-name", // backend docs URL
  "output": "src/app/api/backend-name", // destination for the generated models
  "ignoreUnusedModels": false,
  "indexFile": true,
  "removeStaleFiles": true,
  "skipJsonSuffix": true,
  "module": "ApiModule",
  "configuration": "ApiConfiguration"
}

Code Generation

Add a new script to


:


```json
"openapi-gen-backend-name": "ng-openapi-gen -c <path to the config file from the previous step>/config.json"

That's it! To generate services and models, simply run:

npm run openapi-gen-backend-name

Once the command is executed, the specified directory (in our case, src/app/api/backend-name) will contain the automatically generated models, services, and the ApiModule, which can be integrated into your application.

...

@NgModule({
  imports: [
    ...
    ApiModule.forRoot({rootUrl: 'https://localhost:5001'})
  ]
})
export class AppModule {}

Using the Models and Services

Generated models and services provide strict typing and a convenient interface for API requests. For example, the User model and the UserService service are generated automatically:

Example of Generated Models:

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

Example of Generated Service:

...

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

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

Now, the service can be used in any component of your Angular application:

Often, the code of the generated services may seem odd and not particularly user-friendly, but the idea is that we don’t need to focus on it. All we care about is the contract itself.

Example of Usage:

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

@Component({
  selector: 'app-user-list',
  template: `
    <div *ngFor="let user of users">
        {{ user.name }} (ID: {{ user.id }})
    </div>
  `
})
export class UserListComponent implements OnInit {
  users: User[] = [];

  constructor(private userService: UserService) {
  }

  ngOnInit(): void {
    this.userService.getUsers().subscribe((data) => {
      this.users = data;
    });
  }
}

Alternatives

It’s worth noting that using OpenAPI is not limited to Angular or frontend development. The approaches outlined here can scale across many popular technologies. For example, in React and TypeScript environments, libraries like openapi-typescript-codegen and swagger-typescript-api are widely used to generate strictly typed API clients. In Python and Java ecosystems, tools like openapi-generator help save development time for both server and client applications, generating code tailored for frameworks such as Flask, Django, Spring Boot, or Kotlin.

This proves that the main advantage of OpenAPI is its versatility. Regardless of the programming language or framework, OpenAPI unites frontend, backend, and QA teams around a single contract, minimizing human error and integration issues. Whether your team is working with web technologies, mobile platforms, or server applications, OpenAPI and automatic generation tools help standardize processes and accelerate development.

Tool	Languages/Frameworks	Features
`openapi-typescript-codegen`	React, TypeScript	A compact generator for clients with types.
`openapi-generator`	Vue, Svelte, Python, Java, Kotlin, etc.	A powerful, multi-platform tool.
`swagger-typescript-api`	React, Node.js, TypeScript	Lightweight and fast generator with CLI.

Recommendations for Tool Selection

If you are using Angular, your best choice is ng-openapi-gen.
For React/TypeScript, pick openapi-typescript-codegen or swagger-typescript-api. Both libraries work well for different scenarios.
For complex or multi-language projects, use openapi-generator, as it supports a broader range of platforms and languages.
Working with frameworks like Django or Spring? openapi-generator can even generate server-side code.

3. Integrating OpenAPI into CI/CD

A major focus should be placed on automating contract validation at the pipeline level to avoid desynchronization between the frontend and backend.

What to Add to CI/CD:

Automatic documentation generation (Swagger on the backend) for every deployment.
Specification validation using tools like swagger-cli or openapi-cli.
Synchronization of frontend models during the build process (while high-level validations are unlikely here, the mere fact of invalidating the code—and consequently preventing compilation—in case of untracked backend changes significantly reduces reaction time).

Results: What Did OpenAPI Implementation Achieve?

After several months of active use, we observed the following improvements:

Fewer Errors: Thanks to strict typing, problems are identified before requests even run.
Faster Development: Automating model and documentation generation reduced the time required for updating and integrating APIs.
Transparency: Swagger UI and generated types simplified API structure comprehension for newcomers to the team.
Stable Collaboration: QA teams gained access to documentation through Swagger, and frontend developers started working with clear, readable interfaces.

Conclusion

Establishing seamless collaboration between the frontend and backend is no easy task, especially as your project grows and contracts multiply. Automatic generation of frontend models and services helps eliminate routine work, reduce desynchronization risks, and speed up development. Instead of manually writing interfaces or dealing with unverified contracts, you gain a single source of truth, synchronized with just a couple of commands.

The best part is that you don’t need to completely overhaul your project or development approach. You can start small: set up model and service generation for one module or a key API. Gradually, your process will stabilize, your team will work faster, and the number of bugs at the server-client intersection will noticeably decrease.

Using tools like OpenAPI or similar solutions only simplifies this process, providing developers with an efficient and convenient way to maintain order in the contract layer. By introducing automation step by step, you’ll not only reduce routine tasks but also make development significantly more comfortable.

There is an excellent way to confirm this—try it for yourself. And soon, you may find it hard to imagine API development without these kinds of solutions.

Code is Written, Not Born: Overcoming the Idea of a "Perfect Project Start"

Art Stesh — Wed, 09 Apr 2025 13:16:58 +0000

Every programmer, regardless of skill level, has faced this situation at least once. You sit down to start a new project, brimming with plans and ideas, full of excitement about creating something perfect. Yet... an hour passes, then two, and all you have on the screen are a few folders, a couple of placeholders, and a README.md file. Soon enough, you’re returning to the documentation, searching for the "correct" project structure or sneaking peeks at how others did it.

The same often happens when working in a team: meetings wind up turning into endless discussions about architecture, abstractions, and frameworks. Ideas fly around like comets, everyone agrees everything "should be done the right way," but actual progress? It stagnates. Because the team—along with you—is subconsciously waiting for something: the perfect start.

The syndrome of the perfect start isn’t just a myth; it’s a genuine roadblock to productive development. In this article, we’ll dive into why waiting for "perfection" means stalling, how this mindset stifles progress, and what you can do about it.

Why Do We Wait for the Perfect Start?

Let’s be honest. The engineering mindset instills in most programmers a desire for "purity" and "eternity." It feels critical that a project is built on a solid foundation that can be scaled and maintained for years. But this relentless pursuit of "flawlessness" often turns into a toxic habit of postponing meaningful action until "the perfect solution" has been found.

The problem is that perfection is usually unattainable. Here’s why:

The world changes faster than we write code. By the time you finish analyzing that new framework or pattern, its next version may have already been released, your environment will shift, and the project requirements might evolve—say, from a web app to mobile.
We can’t foresee everything. At the start of a project, it seems like you need to make a hundred decisions right away: Will it be microservices? Will you use a monorepo? What should the layers of abstraction look like? But this mostly leads to analysis paralysis. While you're deep in thought, actual work slows down.
We fear "tainting" the codebase. That relentless commitment to clean code can hold us back. The idea that the code must be clear, tested, and elegant from the very first line often prevents us from writing anything that looks "less-than-perfect."

Why Is It Crucial to Stop Waiting for the Perfect Start?

In programming, as in life, the most important thing is movement. Making small, fast, incremental changes is far more effective than spending days crafting a theoretically perfect structure or ideologically flawless architecture.

Here are a few reasons why:

Decisions always evolve as the project grows. During the planning phase, you won’t even be aware of the real challenges yet. The project defines the architecture—not the other way around.
A working prototype beats abstract concepts. In most cases, building something functional, even if it’s far from perfect, is already half the battle. Real code doesn’t just push you forward—it provides feedback.
The process itself is where experience lies. Even if the initial code is "messy," you’ve started something. Refactoring (yes, everyone loves that word) is every developer's old friend.
It’s beneficial for business. Remember, money isn’t made from "perfect code." For the client, the product, or the end user, functionality is what matters. Code can always be improved later—time cannot.

A Story About Chasing the "Perfect Start"

Years ago, I witnessed firsthand the pitfalls of striving for a "perfect start." The task was to develop an internal-use application: a large dashboard for data analysis, interactive tables, graphs, and integrations with multiple APIs. The project seemed ambitious, but progress at the beginning was quick: we finalized the design system, discussed frameworks, and even built a basic structure within a few days.

Then things spiraled out of control. The team, weary of maintaining "old" projects and deeply convinced that older projects were inherently bad because:

they were legacy code,
and business never allowed enough time for proper refactoring, rendering them messy,

went all-in on trying to "do things right," modern, and perfect.

It seemed as though every task required a top-tier solution. For example, all API interactions had to be strictly typed, fully universal, and outfitted with error handlers that adhered to top-tier best practices. We attempted to build a custom API interaction mechanism just in case those APIs ever changed, designed complex role models and intricate access logic, and... what was the result?

After a month, we had absolutely nothing useful—just a mountain of abstractions, dozens of interfaces, and basic logging. It was like that old meme:

We had 35 lines of code, 2 loops, 2 try/catch blocks for safety,

4 if/else conditions, and a whole bunch of indents and hacks.

Not that this was anywhere near what was needed.

But once you start writing subpar code, it’s hard to stop.

The only thing we feared was recursion.

There is nothing more confusing than recursion.

I knew sooner or later we would resort to it.

In the end, everything had to be thrown out, and we essentially started over with a simpler approach. We focused on bare essentials: did we need a universal API module right away? No, just simple functions for each service. Did we need a universal data abstraction layer from day one? No. And so on. Per rectum ad astra, as they say in some distant Russian villages.

We quickly assembled a working prototype that was good enough to show the business. And you know what? Many features we initially wanted to implement simply weren’t needed. If we’d developed them from the start, they would’ve been a complete waste of time.

The Paradox of the Perfect Start

The most fascinating thing about the chase for a perfect start is that, in real life, it never comes. Here’s why:

Perfect architecture is born only through practice. As long as a project exists only in your head, you don’t fully understand it—there are only hypotheses, untested by reality. Real business requirements or user feedback will shatter your plans.
Frameworks and tools age faster than your development. It’s unrealistic to expect that this year’s choices will meaningfully help you a year down the line.
Everything becomes clearer after initial chaos. When a project gets off the ground with even a minimum working version, it’s much easier to see what needs to be improved.

How to Stop Waiting for a Perfect Start

Taking that first step is daunting. But developers love algorithms, so here are practical recommendations—no theory, only tried-and-true methods.

Break tasks down—into absurd simplicity. When faced with an empty project and the overarching goal to "build something big," that scope can feel paralyzing. The solution is to break tasks down into bite-sized steps until they become glaringly obvious.

Example:

Instead of "Set up API architecture," start with "Create a basic Express server that outputs Hello World." Sure, it seems too simple—but within an hour, you’ll have something to build upon.

Don’t make too many decisions at once.

If you’re starting a new project, don’t insist that it must "immediately" have:
- a precise directory structure,
- the "perfect" Redux/Signals/Vuex store,
- a custom CI/CD pipeline,
- or 100% test coverage. Leave these goals for later and focus on minimal, working versions.
Let early stages be messy.

Turn your project development into a sequence of iterations. In reality, there is no such thing as perfect code at the starting point because the project itself exists in a state of uncertainty.

Stop viewing "messy" code or temporary solutions as problems. What’s important is to keep the following chain in mind at all times:

Write working code.
Improve something in the existing codebase.
Repeat.

Refactoring is not scary if you do it regularly.

4. Set Action-Oriented Goals Instead of Result-Oriented Ones

Instead of telling yourself, "Today I will build a modular backend structure," say, "Today I will create authentication functionality with minimal coupling." This approach helps you focus on the process and feel less discouraged if the results don’t yet seem "grand."

5. Learn to Let Go

Let go of the illusion that the first solution is always final. It isn’t. Code is meant to be written, not carved in stone. If you choose a strategy and later find it ineffective, there’s nothing stopping you from changing it.

Don’t fear leaving something unfinished. What matters is your ability to keep moving forward. In this industry, those who survive are not the ones striving to build something perfect on the first try, but those who release functioning projects and are willing to improve them with each update.

Refactoring Doesn’t Wait for a Special Moment

Here’s an important point to highlight—the significance of continuous refactoring. Oftentimes, we mentally separate development from refactoring. We think there’s the stage when "we’re quickly writing code for the MVP," and then the stage where "we go back to clean everything up." However, this approach is fundamentally flawed: the business won’t allocate money for a "refactoring stage" unless the project is already collapsing under its own weight.

Personally, I no longer think of these as separate activities. Refactoring isn’t a distinct phase of the project; it’s an ongoing part of the development process. It’s something you do every day, with every commit, to leave the code just a little better than it was yesterday.

Years ago, I worked on a project that was a textbook example of poor development at the start. The codebase was chaotic: tons of "hotfixes," duplication, no tests, and a complete mess in directory structure. The term "architecture" simply didn’t apply—the logic was scattered throughout the project. While the product met basic functionality needs, working with it was so complex that adding any new feature became a nightmare, even for experienced developers.

The project was already generating some income, but adding features or fixing bugs took 2-3 times longer than the initial estimates. The company faced a choice: either rewrite the project completely (which might take up to a year) or gradually improve it without interrupting business operations.

The first step was agreeing on a practical approach: "each commit should leave the code slightly better than it was." This didn’t mean rewriting everything all at once. Instead, the plan included the following steps:

When adding new functionality, refactor the surrounding code. For example, if a method was added to an outdated class, the class would be tidied up, and the method itself implemented according to best practices.
Gradually introduce testing. Every new or updated piece of code was covered with tests to reduce the risk of breaking something.
Create small "on-the-fly" tasks. For instance, if we encountered a complicated, unreadable method, we rarely rewrote it immediately but would create a ticket like "Optimize X."
Standardize code style. Even things like consistent import order and formatting became important to us.

After a year of gradual improvement, the project passed an external audit when the company attracted a major client. The auditor noted that although remnants of poorly written legacy code still existed, the current structure and maintainability already met professional standards.

Most importantly, the business saw the difference—adding new features took less time and cost the company significantly less. As a result, the product grew to a point where it became a noticeable source of profit.

This experience taught me and the team that gradual improvement is a working strategy. There’s no need to rewrite a project from scratch, as long as there’s discipline and a desire to improve it step by step. The key is consistency and a commitment to bring order.

The Perfect Start: Nobody Remembers It, But Everyone Sees the Result

When a project is finished—or at least up and running—nobody cares about the chaos of the beginning. Users will use it, clients will sign the contracts, and your team lead may or may not give you a pat on the back—but the project lives, and that's what matters.

Let’s take a look at how many successful products were built. Facebook started as a local university network. Amazon began as an online bookstore. And the first code for Python, according to its creator Guido van Rossum, looked far from better than your average student project.

If some of the world’s most successful companies began with functionality that "just worked," then why do we believe that our code has to be perfect from the very first attempt?

Conclusion

The perfect start doesn’t exist. Period.

Code is written; it isn’t born. Code lives through constant iterations. There’s no need to aim for the perfect structure in the first few days of development—it’s an illusion. A developer’s job is not to create a masterpiece at the start but to move forward, improving upon what’s already been built, a little at a time.

Beautiful code is a myth. Good code is the kind that works. Choose the latter.

P.S. Some Recommended Reading

"Continuous Delivery" by Jez Humble and David Farley – This one’s older, but its core concepts are timeless.
"Refactoring" by Martin Fowler – In case someone still hasn’t read it, it’s a must.
"Release It!" by Michael Nygard – Insights into real-world struggles and the challenges waiting for us in actual projects.

The Second Step into the World of RxJS: RxJS Operators — How to Learn and Why They Are Needed

Art Stesh — Fri, 04 Apr 2025 14:00:00 +0000

Welcome to the second article on the topic of RxJS! If you've read the first part, chances are you've experimented with from(), interval() and got familiar with basic operations — filtering and transforming data. We will build upon this foundation to explore more sophisticated tools, so that RxJS can evolve from simply being "interesting experiments" to becoming a truly powerful tool for your projects.

Note that this article, as well as the rest in this series, is aimed exclusively at beginners. No groundbreaking insights, revolutionary findings, or "brilliant" thoughts are expected to be found here for experienced users. The content is based on my understanding of how best to structure the learning process of the given topic.

Why are operators so important?

RxJS can be compared to a LEGO set: you receive a basic platform (Observable) and a variety of tools (operators) that allow you to create virtually any solution, whether it's asynchronous requests, event management, or user input processing.

Today's question: there are so many operators! How do we master all of them without getting overwhelmed?

Continuing the logic of the previous article, let's state the following: operators cover the widest range of tasks, but the key to success is starting with the most commonly used and easy-to-understand tools. This will help you quickly grasp their power and integrate them into real-world applications.

How to choose the order of studying operators?

In this article, we'll get acquainted with the basic core of operators that you should prioritize in your study plan (once you're familiar with operators like map and filter).

I divide the learning process into three main stages:

Basic operators for filtering and transforming data. (The easiest to start with: they work "out of the box" and are easy to apply to simple code.)
Combination operators. (These allow you to merge data sources, select necessary streams, and switch between them.)
Subscription management mechanisms. (Handling unsubscriptions, error processing, and stream completion management.)

Today, we will continue progressing through the first stage by deepening our knowledge.

In the previous article, you already learned about filter() and map(). Now, let’s introduce a new operator — take().

take() — Control the number of data items

If your data stream starts becoming too long or you need to limit the number of data items processed, the take() operator comes in handy. For example, let’s say you only want to process the first three messages:

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

interval(1000)
  .pipe(take(3)) //  Specify that we only need the first 3 values
  .subscribe(value => console.log(value));

// Output:
// 0
// 1
// 2

The take() operator tells the observable stream: “Thanks, but I only need a few of the initial items.” This is especially useful for infinite streams like interval.

reduce and scan

Now it's time to get acquainted with operators that allow you to work with the entire stream of data, rather than individual items. For example, when you need to transform a stream into a single final value or track the accumulation of data over time.

Let’s dive deeper into the reduce and scan operators.

Why are reduce and scan so important?

Both operators are often compared to tools from regular arrays, such as Array.reduce(). However, instead of processing a fixed array, reduce and scan work with data streams that may come in gradually. It’s like someone delivering coins to you one by one, and you’re putting them in a piggy bank:

reduce works like this: it collects the coins in a piggy bank and only tells you the total amount after the process is complete.
scan works differently: it informs you of the intermediate totals every time you add a coin.

Essentially, reduce is perfect for final calculations, while scan is great for working with real-time data.

reduce: The Final Value Upon Completion

Imagine you’re running a charity fundraiser. People send you donations one at a time, and your task is to calculate the total amount collected. Only when the fundraiser ends do you make the final announcement:

import { from } from 'rxjs';
import { reduce } from 'rxjs/operators';

const donations = from([10, 20, 30]); // A stream of donations

donations.pipe(
  reduce((acc, value) => acc + value, 0) // Summing up all the donations
).subscribe(total => console.log(`Total amount: ${total}`));

// Output:
// Total amount: 60

How does it work?

reduce() takes two arguments:
1. Accumulator function (acc, value), which updates the accumulated value.
2. Initial value of the accumulator (in this case, 0).
In our example, we take each element from the stream (donation) and add it to the total sum acc.

Note: You only get the result after the stream is fully completed. If the stream is infinite (e.g., interval), reduce simply won't work.

Example: Calculating Orders

Now, let's apply reduce to a task where we have a list of orders, and we want to calculate the total revenue for a company:

import { from } from 'rxjs';
import { reduce } from 'rxjs/operators';

const orders = from([
  { id: 1, total: 100 },
  { id: 2, total: 250 },
  { id: 3, total: 50 }
]);

orders.pipe(
  reduce((acc, order) => acc + order.total, 0) // Summing up revenues
).subscribe(totalRevenue => console.log(`Общий доход: $${totalRevenue}`));

// Output:
// Total amount: $400

With the same approach, you could count the number of elements, find the maximum/minimum, or concatenate text strings.

scan: Real-Time Tracking

Now imagine that you don’t want to wait for the final result and instead want to observe intermediate totals right away. For example, you start a timer during a run and want to see each new time update.

This is where scan() comes to the rescue:

import { from } from 'rxjs';
import { scan } from 'rxjs/operators';

const donations = from([10, 20, 30]); // Stream of donations

donations.pipe(
  scan((acc, value) => acc + value, 0) // Calculate the sum at each step
).subscribe(currentSum => console.log(`Current sum: ${currentSum}`));

// Output:
// Current sum: 10
// Current sum: 30
// Current sum: 60

The feature of scan is that the result updates at every step, not just at the end.

Example with real-time data: Bank Account

Now imagine another example: you deposit and withdraw money from a bank account. The scan operator is perfect for calculating the balance in real-time:

import { from } from 'rxjs';
import { scan } from 'rxjs/operators';

const transactions = from([100, -50, 200, -75]); // Deposits and withdrawals

transactions.pipe(
  scan((balance, transaction) => balance + transaction, 0) // Calculating balance
).subscribe(currentBalance => console.log(`Current balance: $${currentBalance}`));

// Output:
// Current balance: $100
// Current balance: $50
// Current balance: $250
// Current balance: $175

Here, each new value updates the current account balance. You see the changes instantly, which is perfect for monitoring.

Comparison: Reduce vs Scan

To better understand, let's visually compare how reduce and scan work. For example, we process the same data stream [1, 2, 3]:

reduce: will return only the final result — 6.
scan: will first return 1, then 3, and finally 6.

Example code:

import { of } from 'rxjs';
import { reduce, scan } from 'rxjs/operators';

const numbers = of(1, 2, 3);

numbers.pipe(
  reduce((acc, value) => acc + value, 0)
).subscribe(result => console.log(`reduce: ${result}`)); // reduce: 6

numbers.pipe(
  scan((acc, value) => acc + value, 0)
).subscribe(result => console.log(`scan: ${result}`)); // scan: 1, 3, 6

When to use Reduce vs Scan?

Here are some tips for selecting the right operator:

Use `reduce` when:

You are working with a finite stream (e.g., a data array that ends).
You are only interested in the final result.
You need to calculate the total sum, product, or process all elements of the stream.

Use `scan` when:

You want to see data in real-time.
The stream may be infinite.
You need to track intermediate states: for example, balance calculation, accumulating sums, or monitoring updates.

What's Next?

After mastering these two tools, you can start combining them with other operators. For example, try adding filtering before reduce or see how scan behaves when combined with map to transform intermediate states.

Further steps may include:

Using scan for complex states, such as working with objects.
Exploring more advanced transformations with reduce to collect arrays or turn a data stream into more complex structures.

Experiment, challenge yourself with real-world tasks, and try to solve them in different ways — this is the best way to master RxJS.

Operators debounceTime and throttleTime

It's time to talk about event frequency management, where the main stars are debounceTime and throttleTime.

These operators are extremely useful when dealing with events generated at a high frequency (e.g., mouse clicks or text field inputs). They allow you to manage the number and frequency of these events to prevent resource overloading.

Why are debounceTime and throttleTime important?

Imagine the following scenario: a user is quickly typing into a search box, triggering a server request with each character entered. You don't want to send requests every millisecond, as this would overload the server. Instead, you want to optimize the process by handling only the latest input event after a short delay. This is where the debounceTime operator comes in.

In another scenario, you might want to limit event handling frequency, allowing only one event to pass through every few seconds, such as when tracking mouse movement. For this, throttleTime works perfectly.

Both operators act as filters for frequent events but handle them differently.

debounceTime: Wait for a pause between events

How does debounceTime work?

debounceTime delays event processing until the stream has been silent for a specified amount of time. If a new event occurs within this time, the timer resets. As a result, debounceTime always processes the last event in a series.

Example: Search with delay

At this point, we transition to examples that are more challenging to run in online tools such as PlayCode, mentioned in the first article. You may need to switch to local projects to execute the code.

Let's consider a classic task: a user enters a search query into a text field. To avoid creating a server request for every keystroke, we use debounceTime:

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

const searchInput = document.getElementById('search');

// Create an event stream from the text input field
fromEvent(searchInput, 'input').pipe(
  map((event: any) => event.target.value), // Extract text from the input field
  debounceTime(300), // Wait 300ms after the last input
).subscribe(searchTerm => console.log(`Request: ${searchTerm}`));

// Output:
// The user quickly types "RxJ", then pauses on "RxJS".
// The console logs only: "Request: RxJS".

How debounceTime works here:
- If the user pauses for at least 300ms, the stream passes the last change.
- If the user continues typing, the timer resets.
This approach is useful for optimizing input processing or other frequent events.

Example: Auto-save with delay

Now, another example: auto-saving a document. When a user makes changes to the text, saving does not happen instantly but after a pause to avoid too frequent requests:

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

const textarea = document.getElementById('editor');

fromEvent(textarea, 'input').pipe(
  map((event: any) => event.target.value), // Extract text from the editor
  debounceTime(1000) // Wait 1 second after the last change
).subscribe(content => console.log(`Saving: ${content}`));

// The user writes the text: "Hello, RxJS".
// The save action is triggered only after a 1-second pause.

throttleTime: Limiting Event Frequency

How does throttleTime work?

throttleTime allows passing events no more frequently than the specified time interval, ignoring all other events. If the stream generates multiple events during the interval, the operator will pass through only the first one.

Example: Tracking mouse position

Suppose you want to track mouse movements but do not want to overload the handler with a huge number of events. Instead, you want to receive the mouse coordinates once every 500ms:

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

fromEvent(document, 'mousemove').pipe(
  throttleTime(500), // Pass only one event every 500ms
  map((event: MouseEvent) => ({ x: event.clientX, y: event.clientY }))
).subscribe(position => console.log(`Mouse coordinates: (${position.x}, ${position.y})`));

// Output:
// Move the mouse quickly across the screen. Coordinates are logged only once every 500ms.```
{% endraw %}

{% raw %}

How throttleTime works:

It's like starting a "timer" after the first event.
All subsequent events are ignored until the specified interval of time has passed (in our case, 500ms).

Example: Preventing multiple button clicks

Let's consider a scenario: you have a button that sends a request to the server. To avoid sending multiple requests when the button is clicked repeatedly, we use throttleTime. This ensures that only one click is processed every 2 seconds:


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

const button = document.getElementById('submit');

fromEvent(button, 'click').pipe(
  throttleTime(2000) // Allow only one click every 2 seconds
).subscribe(() => console.log('Request sent!'));

// Output:
// The user quickly clicks the button 5 times in a row.
// Only one request is logged every 2 seconds.

Comparison: debounceTime vs throttleTime

Both operators allow you to control the frequency of events, but they do it differently. Here are their key differences:

Feature	debounceTime	throttleTime
How it works	Passes the event only after a pause.	Passes the first event in each interval.
Best for	When you only care about the last event.	When you need to limit the frequency of events.
Ignores events	All events until the pause ends.	All events during the interval.

When to use debounceTime vs throttleTime?

Use `debounceTime` if:

You want to wait for the stream to go silent.
You're working with searches, auto-saving, or other scenarios where you care about the last input.
You want to reduce the number of requests.

Use `throttleTime` if:

You want to limit the event frequency.
Events occur in real-time (e.g., mouse tracking, scrolling).
You need to prevent multiple consecutive triggers of the same function within a short time.

The debounceTime and throttleTime operators help efficiently manage streams of frequent events, simplifying the handling of user interactions. With their help, you can avoid unnecessary computations, optimize server requests, and enhance the user experience.

As always, try using these operators in real-world tasks, experimenting with delay and interval parameters. Practice is the best way to master these useful tools!

mergeMap and switchMap

These operators are used to process data streams when each element of the original stream needs to be turned into a new stream. In other words, each element triggers an additional process, such as an asynchronous request or data transformation.

What are mergeMap and switchMap used for?

Imagine you have a data stream (e.g., button clicks, text input, or even a list of numbers), and each element triggers an additional action: sends a request, transforms data, or something else. The challenge is that such actions can spawn many parallel tasks, and managing them manually can be difficult.

Here’s what mergeMap and switchMap do:

mergeMap starts all actions simultaneously (in parallel) and returns results as they are completed.
switchMap cancels the previous action if a new event occurs, returning results only for the latest.

mergeMap: Process all actions simultaneously

How does mergeMap work?

When using mergeMap, every event in the stream triggers a new action, and all launched actions work together. It does not cancel old tasks but waits for all of them to complete.

Example: Multiple numbers — multiple text streams

Let’s look at an example. Pay close attention, as it’s a bit more complex.

We create a basic stream of numbers [1, 2].

For each element in this stream, we’ll start a new inner stream that returns a string in the format <base number>-<time in seconds>. To keep the output manageable, we’ll limit the inner stream to two values.


typescript
import { from, interval } from 'rxjs';
import { mergeMap, take, map } from 'rxjs/operators';

// Stream of numbers
const numbers = from([1, 2]);

// Apply mergeMap
numbers.pipe(
  mergeMap(num => 
    interval(1000).pipe(
      take(2), 
      map(i => `Number ${num}-${i}`) // Convert number to text
    )
  )
).subscribe(result => console.log(result));

// Output:
// Number 1-0
// Number 2-0
// Number 1-1
// Number 2-1

Here, each element of the stream [1, 2] starts its own stream, and as tasks are completed, the composed strings are logged to the console. Notice the output: we don’t wait for one task to finish; both streams work simultaneously.
While we use a synthetic example here, the scenario is realistic. Just imagine that instead of numbers, we have user IDs, and for each ID, we want to make an asynchronous request to a remote server.

switchMap: Processing Only the Latest Action

How does switchMap work?

switchMap works differently: it cancels all previous actions if a new event occurs. This is useful when you only need the latest action. For example, if a user is typing in a search bar, old requests become irrelevant when a new input is received.

Example: Multiple numbers, but only the latest matters

Let's take a stream of numbers and imagine that we want to update the output only for the latest number. If a new event occurs, the previous one is ignored:


typescript
import { from, interval } from 'rxjs';
import { switchMap, take, map } from 'rxjs/operators';

// Stream of numbers
const numbers = from([1, 2]);

// Apply switchMap
numbers.pipe(
  switchMap(num =>
    interval(1000).pipe(
      take(2),
      map(i => `Number ${num}-${i}`)
    )
  )
).subscribe(result => console.log(result));

// Output:
// Number 2-0
// Number 2-1

switchMap cancels the processing of the first value when the second value arrives later.

Difference Between mergeMap and switchMap

While both operators map the source stream to new data streams, they are suited for different use cases:

Feature	mergeMap	switchMap
What it does	Executes all actions simultaneously.	Cancels previous actions, keeps only the latest one.
When to use	If you're interested in the results of all tasks.	If you're interested only in the latest task.
Example	Transforming all events (e.g., multiple clicks).	Text search, where only the most recent input matters.

When to use mergeMap vs switchMap?

Use `mergeMap` if:

You want to process each event individually.
You need to run multiple parallel asynchronous operations.
All results are important, regardless of the order or completion time.

Example: Handling all mouse clicks or sending multiple requests to a server.

Use `switchMap` if:

You're only interested in the latest event.
Results from previous events become irrelevant when a new one arrives.
You're working with streams that update frequently — for example, a search field or a slider input.

It’s worth noting that understanding these two operators, in my opinion, is one of the most challenging aspects of RxJS. Simple examples may not fully explain the problems they solve. But as always, the key takeaway is to experiment. These are two essential operators, and while they may seem overly complex or rarely applicable at first, it’s enough to understand their general logic to recognize when they might be useful in real-world tasks.

Next Steps: Combining Knowledge

Now that you're able to work with the basic operators, it's time to create interesting combinations. Consider this task: every second, a number is generated, but you only want to see even numbers, and you also want to double them:


typescript
import { interval } from 'rxjs';
import { filter, map, take } from 'rxjs/operators';

interval(1000)
  .pipe(
    filter(value => value % 2 === 0), // Keep only even values
    map(value => value * 2),         // Double them
    take(5)                          // Take only the first five values
  )
  .subscribe(value => console.log(value));

// Output:
// 0
// 4
// 8
// 12
// 16

Such combinations allow you to use several operators together to process a data stream. Your task here is to break the logic of the operators into steps to avoid confusion.

Conclusion

Getting into RxJS is a journey that requires time, experiments, and gradual learning. It's best to start small: try out basic operators like map, filter, and take, understanding them through examples. This lays a solid foundation for working with more complex tools. Focus on the operators that helped solve specific problems or felt intuitive. Practice is the key to mastering any technology.

Don't feel pressured to learn all operators at once. RxJS is a powerful tool that reveals its potential as your experience grows. It’s enough to master a few key operators (as we have done in these articles) and then gradually expand your knowledge as the need arises. The official RxJS documentation is structured well for finding operators, making it the best resource for learning them once you’ve grasped the basics.

Remember: what matters most is not the number of operators you’ve learned but your comfort in using them and your understanding of data stream logic. Solve real-world problems, experiment with operators, combine them, and create your own small projects. This approach allows you to progress from simple to complex without feeling overwhelmed.

In the third article, we’ll discuss common mistakes in managing RxJS streams, which often complicate developers' lives. Stay productive — see you in the next step!

Test Data in TypeScript: Challenges, Solutions, and My Experience

Art Stesh — Sat, 29 Mar 2025 11:01:31 +0000

Testing is an integral part of development, especially when it comes to complex applications. It allows us to ensure code quality and prevent unexpected errors. However, an important question every developer faces sooner or later is: how do you balance between thorough test coverage and the time spent writing them? Even more importantly, how do you avoid getting bogged down by the routine?

Working with test data is a challenge that can exhaust even the most patient developers. Simple tests with primitive parameters are quick and easy to write. But when your method deals with complex objects with nested structures, the situation becomes significantly more complicated. With each new test, more time is spent preparing the data, reducing readability, and increasing overall workload.

This story is not about promoting libraries or tools. It’s my personal experience with tackling typical issues related to data generation for TypeScript tests. I want to share the difficulties I’ve faced, how common approaches from other languages didn’t work, the solutions I eventually arrived at, and—hopefully—get some new perspectives on the problem from the community.

The Test Data Problem in Unit Testing

Writing a good test isn’t too difficult if the functional code adheres to SOLID principles and isn’t overloaded with logic—the test should also end up being simple and concise. But here’s where everything hits a wall: models.

As long as we’re dealing with concepts like “method accepts a string”, “method returns an int”, everything works smoothly. However, when we move on to working with objects, the issue of supplying data to each required model in every test arises.

At first glance, generating this data might seem trivial: we simply create objects with the required values. But in practice:

Complexity of entities. The more complex the data types in the code (e.g., nested structures or collections with various objects), the harder it becomes to manually generate a valid test dataset.
Quantity. There are a lot of tests, so preparing each dataset consumes a massive amount of time.
Maintenance. During refactoring or changes to type structures, updating the test data manually becomes an additional burdensome task.

Approaches to Generating Test Data

Below, I’ll describe a typical progression for a developer writing tests—perhaps you’ll recognize something from your own project.

Carrying Everything With You

The first approach is based on the same primitive principle—if I can define the value of an int variable directly in the test, why not populate a reference type in the same way?

For simple objects like a Role class with fields Id and Name, this works, of course. But where there’s a role, there’s also a user that this role belongs to. Then there’s UserInRole, which links these two entities... If there’s a method in the functional code like "retrieve all role names for a user with login X", we’ll need to define not just one but three models.

The test grows as the model gets more complex. It becomes extremely inconvenient to read—how can you understand which of these details are truly important for the test (e.g., the user's login) and which are not?

With this approach, we:

Ruin readability.
Forget about brevity.
Spend a lot of time writing each test.

Special Methods in Test Classes

At some point, someone notices that the X class contains a lot of duplicate code across its tests. That duplicated code gets extracted into a separate method right there in the X class.

Tests become short again. We've stopped violating the principle of not duplicating code—although wait, there’s no such specific prohibition for test code! So, what did this achieve? Can we say we’ve improved the conciseness of the tests? To be fair, yes, the code is now cleaner. That’s a small victory!

But what about the downsides?

Readability has not only failed to improve—it may have actually become worse. Now, to understand what’s happening in a test, you have to jump back and forth between the test and the factory method.
Situations often arise where the same object needs to be used across different classes. If we create a fake in class A, what should we do in class B? Duplicate it? In a small project, this isn’t immediately noticeable, but once the project grows in scale, you find yourself drowning in problems.

Handwritten "Databases"

Eventually, a “genius” idea may arise: why not hard-code a fake database in static collections, predefine all the needed values and relationships, and use this data in our tests?

There’s not much sense in dwelling on this approach, because it’s only suitable for small projects with three classes and (ideally) no relationships between them.

This resolves nothing, and the supposed "central management" of fake data is completely overshadowed by major downsides:

As the project scales, it becomes nearly impossible to account for and define all the relationships within this system.
The initializer for this fake context quickly grows into a ridiculously long monster.
Developers using this approach tend to rely too much on the predefined data in these collections. Since the required value is already defined, they simply remember it and use it when writing tests. That’s it—you can kiss your code readability goodbye.

On top of that, these collections become untouchable—don’t dare to alter anything, because half the tests will immediately fail!

Factories

Eventually, you get tired of writing the same thing in every test, or micromanaging the handwritten “database,” and you decide to switch to object factories. For instance, if there’s a Role class, the testing project gets a RoleFakeFactory with methods like Create or CreateMany. Yes, you'll need to address some implementation decisions, such as whether these factories should be static, how they get data context, and other similar questions.

However, these aspects don’t significantly affect the usability of this approach. Again, with a small amount of code, this feels like the right solution, and it really seems to work. For the first couple of weeks, everyone is probably satisfied with the results.

So, what did we achieve?

We finally solved the duplication problem, as everything is now in its assigned place. That’s... basically it.

Downsides?

The code is still difficult to read. Yes, management of fakes is now centralized, but how do we interpret the values of these fields?

 public class UserFactory
 {
    public static Create(): User
    {
       return new User
       {
          Id = 345,
          Name = "Vasya",
          Email = "mail@test.test",
          PhoneNumber = "123456789",
          EmailConfirmed = true,
          PhoneNumberConfirmed = true
       }
    }
 }

`EmailConfirmed == true` for a specific test? For most tests? Is it a default value? It’s completely unclear where all these values came from and which ones are meaningful or simply irrelevant.

Readability remains at the same level as the previous approach.
The sacredness hasn’t gone away—we’ve just slightly reformatted the "magic" values without really changing the core approach.

Automatic Object Generation

Many programming languages provide built-in ways to generate random objects for the purposes of unit testing. While the specifics of how this generation is implemented may vary, it’s important (in the context of our discussion) to consider the consequences of such automation.

Objects are generated at runtime with random values, eliminating the need to guess the purpose of hardcoded variables—anything truly necessary for the test can be explicitly specified.
Class instances are created in a single line. Goodbye to factories, special methods, and extra utilities—we gain the ability to generate usable objects anywhere and with any configuration.

What did we achieve with automatic generation?

Code readability has significantly improved—we can now truly be proud of it. All necessary data for a test is located within the test itself.
Conciseness is also top-notch—everything written is focused on the specific needs of the test, with no unnecessary data cluttering up the code.
Performance of both test writing and reading has improved drastically. Depending on prior approaches, speed gains can be considerable—sometimes even multiple times faster.
Efficiency is directly tied to simplicity and convenience, and the easier these aspects are, the greater the developers’ engagement. The more eager developers are to write tests, the higher overall quality of the production code.

I often say that most things have already been invented for us, and programmers shouldn’t reinvent the wheel at every step. However, in the case of TypeScript, this concept falters...

Inspiration from C#: AutoFixture

AutoFixture has become a true ally in my C# testing endeavors. This library enables the automatic generation of objects based on their type, minimizing manual effort. AutoFixture works by leveraging reflection—access to type metadata at runtime—which makes it incredibly powerful and convenient.

After trying AutoFixture, I quickly grew fond of this approach: less repetitive code, more focus on test logic. It worked so seamlessly that when transitioning to TypeScript and Angular, I found myself missing such functionality.

TypeScript and the Test Data Problem

TypeScript is a powerful language that has become indispensable for developing complex frontend applications. However, it has an important limitation: all types are erased at compile time. Once the code is transpiled into JavaScript, all type information disappears.

Thus, what can be easily implemented using reflection in C# becomes unattainable within standard TypeScript code. I spent a long time searching for AutoFixture-like alternatives for TypeScript, but all my efforts were in vain. Either the libraries lacked sufficient functionality, or they required explicit type specifications when generating data—failing to resolve the core problem.

TypeScript Transformers as a Solution

During my search, I came across TypeScript Transformers. This is an incredibly powerful yet underutilized tool.

TypeScript Transformers are plugins that intervene in the process of compiling TypeScript to JavaScript. They allow you to add or modify code "on the fly." Thanks to transformers, it becomes possible to do what regular TypeScript code cannot—pass metadata about types into the final JavaScript.

Inspired by the idea, I set off to develop my own library for automatic object generation for tests.

At first, it all looked very promising, but... as with many powerful tools, there was a catch. The main difficulty is using TypeScript Transformers. It’s an incredibly useful technology, but it requires some "hoop-jumping." Since TypeScript Transformers interfere with the compilation process, they need to be manually integrated into a project.

As a result, simply installing the library via npm install was out of the question.

To work properly with transformations, you need to:

Use a build tool that supports TypeScript Transformers (such as Webpack with ts-loader, or other tools like esbuild or ts-patch).
Register the transformer in the compiler configuration—not just declare it but add a new phase to the project build process.
Occasionally update the settings when TypeScript gets updated. Unfortunately, updates are not always seamless.

Although these steps may not sound overly complex, in practice, not every developer is willing to dive into build configuration just to use a single library. Over time, I was able to streamline everything into simple steps, but "interesting" approaches almost always lead to increased bugs and difficulties for users. Still, this is where I am currently—it’s the best solution I’ve come up with so far. The dependencies on the tooling remain an issue—not all build tools handle transformations effectively. For example, Webpack with ts-loader and tsc work fine, but lighter tools like Vite or esbuild may require an abundance of effort to configure.

In simpler terms, I couldn’t make my library "just work out of the box," which doesn’t personally bother me. In my standard Angular projects, everything works fine, as it does in rare "pure" TypeScript setups with Jest. But beyond that—there’s a fog of war I haven’t had time to penetrate.

Is It Worth It?

Given all the downsides of working with transformers, you might ask: is this even worth it? After all, data generation can still be set up manually, or you could rely on a simpler API.

For me, the answer is clear: all this "hoop-jumping" is absolutely worth the effort. I believe the time I spent digging through TS documentation and writing/testing the library was justified, and as for its usage? I now include it in all my projects by default.

Moreover, the transformer technology itself is still evolving. Over time, the TypeScript build ecosystem may make the connection process simpler than it is now.

Conclusion

In the end, I arrived at a form of testing that closely resembles the logic I used to write in C#.

typescript
it('number of lines is correct', () => {
const items = Forger.create()!;
//
const result = service.convert(items);
//
should().array(result).length(items.length);
});




`ListItem` here is a complex object with numerous fields, but since its content isn’t relevant within the context of the test, it’s enough to populate it with any values just to ensure the tested code works correctly, allowing the narrow logic of the test to be evaluated.

The library is actively used in my projects, and I hope it becomes a convenient tool for other developers looking to make their tests not only high-quality but also easier to write. Perhaps someone will even suggest new approaches and methods. You can explore its capabilities [here](https://forger.artstesh.ru/76a7eb56-cc26-481c-9302-cf8ddbd2002a), and feel free to share suggestions in the comments or via direct messages—I’d be happy to hear constructive ideas.

Getting Rid of Boilerplate in Angular: Using TypeScript Decorators

Art Stesh — Tue, 25 Mar 2025 14:00:00 +0000

Every Angular developer has wondered at least once: "Why am I writing so much repetitive code?" Dependency injection, recurring logging methods, uniform event handling—all of it feels like an endless battle with boilerplate code. However, Angular has a powerful feature in its arsenal to simplify tasks and automate repetitive actions—TypeScript Decorators.

Decorators are a quick way to add unified functionality to your codebase, making it cleaner, more understandable, and easier to maintain. In this article, we'll explore how decorators can help eliminate repetitive patterns while introducing flexibility and error reduction.

Introduction to TypeScript Decorators

Decorators are functions applied to classes, methods, properties, or parameters. They allow you to modify the behavior of an object or its elements without altering its original source code. Decorators are available in TypeScript thanks to the ES7 standard. In fact, Angular heavily relies on them: @Component, @Injectable, @Input, etc.

Purpose of Decorators

The main goal of decorators is to add new behavior to objects. They eliminate boilerplate code, ensure reusability of functionality, and make the code more readable. Decorators allow you to:

Modify or extend the functionality of classes, properties, methods, and parameters.
Automate everyday tasks, such as:
- Logging,
- Validation,
- Caching,
- Dependency injection (DI).
Add metadata, like class or method registration.
Simplify API interaction, freeing developers from manual calls.

Example problem:

Suppose you want to log every method call in the application. Instead of adding console.log() into each method, you can use method decorators:

function LogMethod(target: Object, propertyKey: string, descriptor: PropertyDescriptor) {
  const originalMethod = descriptor.value;

  descriptor.value = function (...args: any[]) {
    console.log(`Method invoked: ${propertyKey}, arguments: ${JSON.stringify(args)}`);
    return originalMethod.apply(this, args);
  };

  return descriptor;
}

class Example {
  @LogMethod
  doSomething(param: string) {
    console.log("Doing something important...");
  }
}

const instance = new Example();
instance.doSomething("test");
// Console:
// Method invoked: doSomething, arguments: ["test"]
// Doing something important...

How Do Decorators Work?

Decorators are functions that run at runtime. They are called to add or modify the functionality of a class, its methods, properties, or parameters.

Types of Decorators:

Class Decorators: Operate on the class itself.
Property Decorators: Modify properties or fields of the class.
Method Decorators: Allow modification of a method’s behavior.
Parameter Decorators: Process method or constructor parameters.

Example Tasks & Implementations

Task 1: Method Call Logging (Method Decorator)

Tracking user interactions and actions in an application is a common requirement. Instead of manually adding logger calls in every method, you can automate logging using method decorators.

Implementation:

We create a @LogMethod decorator to log method names and passed arguments:

function LogMethod(target: Object, propertyKey: string, descriptor: PropertyDescriptor) {
  const original = descriptor.value;

  descriptor.value = function (...args: any[]) {
    console.log(`Method invoked: ${propertyKey} with arguments: ${JSON.stringify(args)}`);
    const result = original.apply(this, args);
    console.log(`Method ${propertyKey} returned: ${JSON.stringify(result)}`);
    return result;
  };

  return descriptor;
}

Usage:

class Calculator {
  @LogMethod
  add(a: number, b: number): number {
    return a + b;
  }
}

const calc = new Calculator();
calc.add(5, 7);

Console output:

Method invoked: add with arguments: [5,7]
Method add returned: 12

Task 2: Transformations and Validations (Property Decorator)

In form-based applications, user input often requires automatic transformations and validations. By using property decorators, you can easily add such functionality without overriding set methods explicitly.

Automatic Transformation with `@Capitalize`:

This decorator ensures string inputs are capitalized:

function Capitalize(target: Object, propertyKey: string) {
  let value: string;

  const getter = () => value;
  const setter = (newValue: string) => {
    value = newValue.charAt(0).toUpperCase() + newValue.slice(1);
  };

  Object.defineProperty(target, propertyKey, {
    get: getter,
    set: setter,
    enumerable: true,
    configurable: true
  });
}

Usage:

class User {
  @Capitalize
  name: string;

  constructor(name: string) {
    this.name = name;
  }
}

const user = new User("john");
console.log(user.name); // "John"

Input Validation:

Automatically validate inputs with a decorator:

function ValidatePositive(target: Object, propertyKey: string) {
  let value: number;

  const getter = () => value;
  const setter = (newValue: number) => {
    if (newValue < 0) {
      throw new Error(`Property ${propertyKey} must be positive`);
    }
    value = newValue;
  };

  Object.defineProperty(target, propertyKey, {
    get: getter,
    set: setter,
    enumerable: true,
    configurable: true
  });
}

Usage:

class Product {
  @ValidatePositive
  price: number;

  constructor(price: number) {
    this.price = price;
  }
}

const product = new Product(50);
product.price = -10; // Error: "Property price must be positive"

Task 3: Automating DI in Services (Class Decorator)

Centralize recurring logic for requests, caching, or error handling in Angular services with decorators. Here's an example of a caching decorator @Cacheable:

const methodCache = new Map();

function Cacheable(target: Object, propertyKey: string, descriptor: PropertyDescriptor) {
  const original = descriptor.value;

  descriptor.value = function (...args: any[]) {
    const key = JSON.stringify(args);
    if (methodCache.has(key)) {
      console.log(`Using cache for: ${propertyKey}(${key})`);
      return methodCache.get(key);
    }

    const result = original.apply(this, args);
    methodCache.set(key, result);
    return result;
  };

  return descriptor;
}

Usage:

class ApiService {
  @Cacheable
  fetchData(url: string) {
    console.log(`Fetching data from ${url}`);
    return `Data from ${url}`;
  }
}

const api = new ApiService();
console.log(api.fetchData("https://example.com/api")); // "Fetching data..."
console.log(api.fetchData("https://example.com/api")); // "Using cache..."

Task 4: Improve Angular Components with Decorators

Automate subscriptions in components with @Autounsubscribe to avoid memory leaks.

function AutoUnsubscribe(constructor: Function) {
  const originalOnDestroy = constructor.prototype.ngOnDestroy;

  constructor.prototype.ngOnDestroy = function () {
    for (const prop in this) {
      if (this[prop] && typeof this[prop].unsubscribe === "function") {
        this[prop].unsubscribe();
      }
    }
    if (originalOnDestroy) {
      originalOnDestroy.apply(this);
    }
  };
}

Usage:

@AutoUnsubscribe
@Component({ selector: 'app-example', template: '' })
export class ExampleComponent implements OnDestroy {
  subscription = this.someService.data$.subscribe();

  constructor(private someService: SomeService) {}

  ngOnDestroy() {
    console.log("Component destroyed");
  }
}

Downsides of Decorators and When to Avoid Using Them

While powerful and convenient, decorators are not without drawbacks. There are scenarios where their usage can lead to problems, increased code complexity, or degraded performance.

1. Unstable Standardization

The Problem:

Decorators are still at Stage 2 in the ECMAScript specification. This means their behavior may change, and their implementation could differ in future versions of JavaScript. As a result, the code written with decorators today might require rewriting in the future.

Consequences:

Complete reliance on the TypeScript implementation of decorators.
Not all JavaScript-compatible tools and libraries support them (e.g., some specific libraries or execution environments).

2. Reduced Readability of Complex Code

The Problem:

Decorators abstract functionality, hiding it behind a concise syntax. As a result, if you use multiple decorators in a single class or component, the program's behavior becomes less predictable—especially for developers unfamiliar with advanced decorators in your project.

Example:

@Auth('admin')
@TrackUsage('createUser')
@Retry(3)
class UserService {
  createUser(user: User) {
    // Implementation
  }
}

For a developer encountering this code, it will be unclear:

What each decorator does.
How they interact with each other.
At what stage of execution each decorator is applied.

When This Becomes Critical:

In projects with a large number of contributors, where code simplicity is paramount.
For newcomers to the project, who may spend extra time understanding the logic.

3. Excessive Magic (Overhead)

The Problem:

Decorators often introduce additional "magical" functionality, leading to unexpected effects. For example, changes via Object.defineProperty or method rewriting can make debugging and understanding the code more challenging.

Consequences:

Difficult debugging: The program's behavior may depend on the sequence in which the decorators are applied.
Unpredictable bugs: Migrating to a new version of TypeScript or Angular could break the functionality of decorators.

4. Challenges in Testing

The Problem:

Testing tools may struggle to interpret code with excessive hidden logic in decorators. Decorators may introduce proxy layers or change the "underlying" code, making test simulation more complex.

Example:

If you use validation decorators (e.g., @Validate), tests may require direct access to the internal implementation of the decorator, making the test-writing process less straightforward.

5. Debugging Complexity

The Problem:

When decorators not only add metadata but also modify methods/properties, the results can become harder to anticipate. Debugging tools (like debuggers) sometimes display the "unmodified" code, rather than its actual behavior.

Example:

While using a debugger to view a modified method, it might not be immediately clear where and how the decorator has been applied.

When Should You Avoid Using Decorators?

1. Small Projects

In small applications with minimal repetition, decorators are unlikely to justify their added complexity. Additional abstraction will only make the code harder to read, while simplifying minimal logic won’t yield significant benefits.

2. Projects with a Low Learning Curve

If your project is aimed at junior developers or those unfamiliar with TypeScript decorators, their use could become a barrier. For such teams, it's better to avoid overcomplicating code.

3. Risky Modifications to State

If a decorator modifies an existing method/property, it might cause unstable behavior—especially if decorators are layered on top of each other.

Best Practices for Using Decorators

Use Decorators for Repetitive, "Boring" Logic:

Decorators work best for tasks like logging, authorization, and caching—situations where reducing boilerplate is important.
Avoid Overcomplicating Code with Abstractions:

If a task can be accomplished with two lines of code without a decorator, it’s better to avoid them.
Document Decorator Behavior:

Always explain what a decorator does in comments or documentation to avoid confusion.
Monitor Performance:

If a decorator performs resource-intensive tasks, ensure it doesn’t noticeably impact application performance.
Don’t Add Business Logic to Decorators:

Decorators should remain lightweight, addressing infrastructure concerns such as logging or validation, not directly processing business data.

Conclusion

Decorators in TypeScript are a powerful tool, but like any tool, they require a reasonable approach. Overusing them, particularly in simple projects, will only complicate the code and make your work harder. It’s important to understand that decorators are best suited for managing cross-cutting concerns (e.g., logging, authorization, validation), but not everything.

Remember: The simpler and clearer the code, the better for you and your team. Decorators are a tool—not a magical solution to all problems! 😊

The First Step into the World of RxJS: Getting to Know Observables

Art Stesh — Thu, 20 Mar 2025 14:00:00 +0000

Learning something new is always a challenge, especially when you're deluged with streams of terms, functions, and concepts that aren't immediately obvious. Let's dive into some simple examples and try to create a mini-plan for mastering this topic. I’m even considering writing a series of articles in this vein, inspired by my experience interacting with newcomers to the field (as long as the topic and presentation spark interest).

Why Learn RxJS at All?

Reactive programming is becoming an increasingly popular approach in modern application development, especially where asynchronous data is critical—user input, working with WebSockets, event handling, or API requests. RxJS is widely used in frameworks like Angular, where its knowledge is practically essential for working with components, services, and data streams.

But even beyond specific framework requirements, RxJS is a powerful tool that simplifies and enhances how we handle asynchronous operations compared to traditional callback or promise approaches. Mastering it will not only give you an edge in managing complex applications but also provide a new perspective on managing data and events.

The Problem With Getting Started

The problem many beginners face when first encountering the topic of subscriptions lies in the abundance of topics and nuances related to it. Tons of articles, discussions, and documentation on topics like "RxJS mergeMap vs switchMap vs concatMap vs exhaustMap" can cause a headache in just the first fifteen minutes. That’s why my first piece of advice is this: limit the list of topics and tools you’re trying to master to the bare minimum. Decomposition is always important — you need to "eat the elephant piece by piece." Similar to how a chess beginner learns, they first study each piece individually, memorize its capabilities and nuances, and gradually move on to the overarching strategy of the game. So, let’s sweep all the pieces off the board and leave only the pawn.

Imagine Yourself as a Magazine Subscriber

The core idea of Observables is observing events and responding to them. To clarify, let’s compare Observables with a magazine subscription system:

Publisher (Data Source) sends data.
The subscriber wants to get updates regularly (data).
The subscriber agrees and subscribes.
While the subscription is active, updates (data) are received.

Key Observations:

Subscribed data only starts flowing after the subscription.
You can unsubscribe to stop receiving data.
Sometimes the publisher stops sending updates entirely.

In programming terms:

There’s a data source (e.g., an event stream or HTTP response).
Subscribers (you) monitor changes.
You "subscribe" using subscribe().
While subscribed, you continuously get updates.

Diving into Observable Code Basics

Traditional Observable Example

An Observable is an object that produces data or notifications. The data can be of any type: numbers, strings, arrays, results of HTTP requests. And here’s where the interesting part begins: traditionally, at this point, it’s common to show examples like:

import { Observable } from 'rxjs';

const observable = new Observable<number>(subscriber => {
  subscriber.next(1);
  subscriber.next(2);
  subscriber.next(3);
  subscriber.complete();
});

observable.subscribe({
  next: value => console.log(value),
  complete: () => console.log('Stream completed'),
});

// Console output:
// 1
// 2
// 3
// Stream completed

But in my experience, this approach doesn’t work at all with beginners – too many things happen all at once, which either require lengthy line-by-line explanations or forcing them to “look the other way” and focus only on the “main idea” while ignoring the “other non-essential details.” But we agreed to try and find the smallest possible topic, so I propose starting with the from() operator and building the learning process around it. Why? Simply because it “sweeps away” all the questions related to creating streams, emitting events, completing subscriptions, and so on.

Going back to the newspaper example: for now, we just want to figure out how to get our favorite newspaper delivered every day, not how to build a printing press and set up its operations.

So, let’s agree that for our basic experiments, we’ll only need two things: the from operator and some collection of objects that we’ll come up with as we go.

Where to Run the Code?

If you're comfortable setting up a local app for experimenting, do so.
Otherwise, consider online tools like PlayCode—quick and easy with RxJS support.

Creating a Basic Number Stream

Let’s simplify the earlier example using from():

import { from } from 'rxjs';

const obs = from([1, 2, 3]);
obs.subscribe(value => console.log(value));
// Console output:
// 1
// 2
// 3

That’s the entire basic example, though it’s worth dedicating enough time to it. The printing press analogy isn’t very fitting here due to the simplicity of what’s happening, so let’s switch to people instead. Sometimes in conversations, we touch on a topic that’s really interesting to the other person, and they start pouring out their knowledge/opinions on the subject (it could be office gossip about colleagues, or it could be the lore of Warhammer – luck plays a role here). That’s exactly how obs holds its “knowledge” about the numbers 1, 2, 3, so it can dump them on anyone who subscribes. When we subscribe to obs, we sequentially receive the entire collection of elements. Moreover, if another listener connects to obs, they will again receive the entire collection from the beginning – just like in real life, you just can’t get this guy to stop talking!

Example (Multiple Subscriptions):

import { from } from 'rxjs';

const obs = from([1, 2, 3]);
obs.subscribe(value => console.log(value)); // First subscriber
obs.subscribe(value => console.log(value)); // Second subscriber
// Console output:
// 1
// 2
// 3
// 1
// 2
// 3

If a second subscriber connects, the data replays from the first item.

What’s Next?

Next, start experimenting with this micro-code, gradually expanding its functionality. Change the data and their types; work, for example, with a collection of strings or objects. Get used to the idea that all these subscriptions are just a versatile tool that works according to a pattern, not some highly complex space shuttle.

Next, it's worth exploring the logic of pipe() with two operators: map() and filter().

As for pipe() itself, there’s no need to dwell on it too much—it’s simply a function that allows us to modify the data stream by applying the corresponding operators (we’ll start with the two mentioned).

Operators: `filter` and `map`

`filter` – Set Conditions for Data

That guy with the gossip is unlikely to share gossip about you directly with you; he’ll save those stories for another conversation partner. And there you have the idea of filtering: we won’t always work with the full data stream—sometimes, we need to filter out irrelevant data.

import { from, filter } from 'rxjs';

const obs = from([1, 2, 3]).pipe(filter(n => n > 2));
obs.subscribe(value => console.log(value));
// Console output:
// 3

filter sets a condition for publishing data, and once again, the same suggestion: experiment, change data types and conditions, get fully comfortable with the ideas of filtering so that you approach other operators later with more awareness and understanding.

It's worth noting an important detail here: pipe can be applied to the entire subscription as a whole or to a specific subscriber only.

import { from, filter } from 'rxjs';
const obs = from([1, 2, 3]).pipe(filter(n => n > 2));
obs.subscribe(value => console.log(value));
obs.subscribe(value => console.log(value));
// Console output:
// 3
// 3

Here, the source itself filters the data, and none of the subscribers can get the unfiltered set—our “gossiper” is not willing to share everything they know.

import { from, filter } from 'rxjs';
const obs = from([1, 2, 3]);
obs.pipe(filter(n => n > 2)).subscribe(value => console.log(value));
obs.subscribe(value => console.log(value));
// Console output:
// 3
// 1
// 2
// 3

In this example, one of the listeners doesn’t want to know anything about numbers less than two, while obs faithfully provides the entire set.

`map` – Transform Data

When telling stories, it’s hard to resist embellishing them a little! And that’s where map comes to the rescue, capable of transforming the data stream on the fly.

import { from, map } from 'rxjs';

const obs = from([1, 2, 3]).pipe(map(n => n * 2));
obs.subscribe(value => console.log(value));
// Console output:
// 2
// 4
// 6

map takes each value (e.g., a number, text, or object) from the stream.
Transforms it as instructed by you.
Passes the modified version of the data further.

Using `interval` for Continuous Data

The previous steps help us get familiar with the mechanisms of working with RxJS, but they don't really resemble anything asynchronous— the code executes instantly, with no waiting or delays. That's why we should include one more function in our starter set: interval. It creates an infinite stream of numbers starting from 0, emitting them at a given time interval in milliseconds.

Let's create an Observable that emits a new value every second:

import { interval } from 'rxjs';

const timerObservable = interval(1000); // Emit values every second.

timerObservable.subscribe(value => {
  console.log(`One second passed: ${value}`);
});
// Console output:
// One second passed: 0
// One second passed: 1
// One second passed: 2
// ...

This generator will help you slightly expand the base for experiments alongside the functions mentioned above.

Conclusion

The main thing to remember is that mastering powerful tools like RxJS takes time. And that's completely normal. Honestly, no one becomes an expert in a single day.

Don't try to understand everything at once or apply dozens of operators immediately. It’s easy to get lost when attempting to "embrace the immense." Start with the simplest concepts, with topics you already grasp to some extent: experiment with from(), interval(), filter, and map until you feel comfortable writing code with these topics without effort or confusion. Once you’ve achieved that ease, the next steps will be considerably simpler.

Remember that every complex topic can be broken down into simpler parts. A deliberate, gradual approach is the key to making RxJS less of a confusing magic trick and more of a convenient, powerful tool that you’ll genuinely enjoy using.

Don’t be afraid to make mistakes, ask questions, or return to basic examples. Everyone progresses differently, but each of us started from the basics at some point.

In upcoming articles, we’ll explore how to make Observables even more powerful with other operators like switchMap, mergeMap, and others while trying to understand how to approach mastering this extensive list of operators properly.

Happy Coding!

DEV Community: Art Stesh

Step Five into RxJS: Error Handling

Typical Newbie Scenarios

Basic Error Handling Operators: Your "First Aid Kit" (Relevant for RxJS 7.8+)

catchError: The Digital First Aid

How It Works

Practice

retry: Smart Retry with Control

Philosophy

Configuration Example

Safety Rules

finalize: Guaranteed Cleanup

Why It Matters

Ideal Use Case

Why We No Longer Use retryWhen?

Battle-Hardened Tips

Operator Use Cases: From Theory to Practice

Scenario 1: Graceful Data Degradation

Problem

Solution with catchError

Scenario 2: Smart Request Retries

Problem

Solution with retry

Scenario 3: Complex Payment Processing

Problem

Operator Combination

Scenario 4: Background Sync

Problem

Solution with finalize

Battlefield Tips

Error Handling Strategies: How to Avoid Drowning in Exceptions

1. "Safe Islands" Strategy

Concept

Implementation

2. "Layered Defense" Strategy

Three-Tier Model

3. "Smart Retry" Strategy

When to Use

Exponential Backoff Pattern

4. "Silent Fail" Strategy

Purpose

Implementation

5. "Explicit Failure" Strategy

When to Use

Implementation

Strategy Selection Checklist

Common Beginner Mistakes: How to Avoid Pitfalls

1. Silent Error Swallowing

❌ Problematic Approach

✅ Correct Solution

2. Infinite Retry Loops

❌ Dangerous Code

✅ Safe Approach

3. Ignoring Unsubscriptions

❌ Common Pitfall

✅ Professional Approach

4. Global Handler as a "Trash Can"

❌ Anti-Pattern

✅ Stratified Approach

Self-Check Checklist

Conclusion: Errors as a Path to Mastery

What Have We Learned?

Key Lessons:

Where to Go Next?

The Fourth Step into the World of RxJS: Unfinished Streams - Silent Killers of Applications

Threats When Working with RxJS

Memory Leak Example

What's Wrong with This Component?

Let's See This in Action:

Why Is This Bad? Memory Leaks and Their Impact

Why Isn't This Obvious?

How to Fix It? Closing Subscriptions

1. Use Subscription for Manual Management

2. Use AsyncPipe: Minimal Code

Best Practices for Subscription Management

1. Adopt a Unified Approach

2. Minimize Subscriptions

3. Prefer AsyncPipe

4. Monitor Performance in DevTools

5. Log Subscription Cleanup During Development

`catchError`: The Digital First Aid

Solution with `catchError`

Solution with `retry`

Solution with `finalize`

1. Use `Subscription` for Manual Management

3. Prefer `AsyncPipe`