DEV Community: miinhho

Bring Spring-Style AOP to NestJS with nestjs-saop

miinhho — Mon, 08 Sep 2025 15:51:46 +0000

Implement powerful Aspect-Oriented Programming in your NestJS applications with complete TypeScript support and familiar Spring-like syntax.

If you've worked with Spring Framework, you've probably enjoyed its powerful AOP (Aspect-Oriented Programming) capabilities. AOP helps you cleanly separate cross-cutting concerns like logging, caching, security, and transaction management from your business logic, making your code more maintainable and readable.

What if you could bring that same elegant AOP experience to your NestJS applications? Enter nestjs-saop – a library that brings Spring-style AOP to the NestJS ecosystem with full TypeScript support.

What is nestjs-saop?

nestjs-saop is a comprehensive AOP library for NestJS that provides:

✅ Complete AOP Advice Types: All 5 Spring-style advice types (Around, Before, After, AfterReturning, AfterThrowing)

✅ Full TypeScript Support: Type safety with generics and interfaces

✅ Seamless NestJS Integration: Works perfectly with the NestJS module system

✅ Decorator Pattern: Clean, familiar decorator-based API

✅ Flexible Configuration: Highly configurable with custom options support

Quick Setup

Install the package:

npm install nestjs-saop

import { AOPModule } from 'nestjs-saop';

@Module({
  imports: [
    AOPModule.forRoot(),
  ],
})
export class AppModule {}

Creating Your First AOP Decorator

Let's create a logging decorator that demonstrates all AOP advice types:

import { AOPDecorator, Aspect } from 'nestjs-saop';

@Aspect()
export class LoggingDecorator extends AOPDecorator {
  around({ method, options }) {
    return (...args: any[]) => {
      console.log('🔄 Around: Before method execution');
      const result = method.apply(this, args);
      console.log('🔄 Around: After method execution');
      return result;
    };
  }

  before({ method, options }) {
    return (...args: any[]) => {
      console.log('▶️ Before: Method called with', args);
    };
  }

  after({ method, options }) {
    return (...args: any[]) => {
      console.log('⏹️ After: Method completed');
    };
  }

  afterReturning({ method, options, result }) {
    return (...args: any[]) => {
      console.log('✅ AfterReturning: Method returned', result);
    };
  }

  afterThrowing({ method, options, error }) {
    return (...args: any[]) => {
      console.error('❌ AfterThrowing: Method threw', error.message);
    };
  }
}

@Module({
  providers: [LoggingDecorator],
})
export class AppModule {}

Real-World Examples

1. Smart Caching Decorator

@Aspect()
export class CachingDecorator extends AOPDecorator {
  private cache = new Map();

  around({ method, options }) {
    return (...args: any[]) => {
      const key = `${method.name}:${JSON.stringify(args)}`;

      // Cache hit
      if (this.cache.has(key)) {
        console.log('💡 Cache hit!');
        return this.cache.get(key);
      }

      // Cache miss - execute method
      console.log('💭 Cache miss, executing method...');
      const result = method.apply(this, args);

      // Store in cache with TTL
      this.cache.set(key, result);
      if (options.ttl) {
        setTimeout(() => this.cache.delete(key), options.ttl);
      }

      return result;
    };
  }
}

// Usage
@Injectable()
export class UserService {
  @CachingDecorator.around({ ttl: 300000 }) // 5 minutes
  async getUserById(id: string): Promise<User> {
    return await this.userRepository.findById(id);
  }
}

2. Performance Monitoring

@Aspect()
export class PerformanceDecorator extends AOPDecorator {
  around({ method, options }) {
    return (...args: any[]) => {
      const start = Date.now();

      try {
        const result = method.apply(this, args);
        const duration = Date.now() - start;

        if (duration > options.threshold) {
          console.warn(`⚠️ Slow method detected: ${method.name} (${duration}ms)`);
        }

        return result;
      } catch (error) {
        const duration = Date.now() - start;
        console.error(`💥 Method failed: ${method.name} (${duration}ms)`);
        throw error;
      }
    };
  }
}

// Usage
@Injectable()
export class DataService {
  @PerformanceDecorator.around({ threshold: 1000 })
  async processLargeDataset(data: any[]): Promise<ProcessedData> {
    // Your expensive operation here
    return await this.complexProcessing(data);
  }
}

3. Error Handling with Retry Logic

@Aspect()
export class RetryDecorator extends AOPDecorator {
  afterThrowing({ method, options, error }) {
    return (...args: any[]) => {
      console.error(`🔄 Method ${method.name} failed:`, error.message);

      if (options.retryCount < options.maxRetries) {
        console.log(`🔄 Retrying... (${options.retryCount + 1}/${options.maxRetries})`);

        // Implement exponential backoff
        const delay = Math.pow(2, options.retryCount) * 1000;
        setTimeout(() => {
          // Retry logic here
          method.apply(this, args);
        }, delay);
      }
    };
  }
}

// Usage
@Injectable()
export class ApiService {
  @RetryDecorator.afterThrowing({ maxRetries: 3, retryCount: 0 })
  async callExternalAPI(endpoint: string): Promise<any> {
    const response = await fetch(endpoint);
    if (!response.ok) {
      throw new Error(`API call failed: ${response.status}`);
    }
    return response.json();
  }
}

TypeScript Power 💪

One of the strongest features of nestjs-saop is its complete TypeScript support. Define custom option types for better developer experience:

interface LoggingOptions {
  level: 'debug' | 'info' | 'warn' | 'error';
  includeTimestamp: boolean;
  logArgs: boolean;
}

@Aspect()
export class TypedLoggingDecorator extends AOPDecorator {
  before({ method, options }: UnitAOPContext<LoggingOptions>) {
    return (...args: any[]) => {
      const timestamp = options.includeTimestamp 
        ? `[${new Date().toISOString()}] ` 
        : '';

      const argsLog = options.logArgs 
        ? ` with args: ${JSON.stringify(args)}` 
        : '';

      console.log(
        `${timestamp}${options.level.toUpperCase()}: ${method.name}${argsLog}`
      );
    };
  }
}

// Usage with full type safety
@Injectable()
export class UserService {
  @TypedLoggingDecorator.before({
    level: 'info',           // ✅ Type-safe
    includeTimestamp: true,  // ✅ Type-safe  
    logArgs: false          // ✅ Type-safe
  })
  async createUser(userData: CreateUserDto): Promise<User> {
    return await this.userRepository.create(userData);
  }
}

Combining Multiple Decorators

You can stack multiple decorators on a single method for powerful combinations:

@Injectable()
export class PaymentService {
  @LoggingDecorator.before({ level: 'info', logArgs: true })
  @PerformanceDecorator.around({ threshold: 2000 })
  @CachingDecorator.around({ ttl: 60000 })
  @RetryDecorator.afterThrowing({ maxRetries: 3 })
  async processPayment(paymentData: PaymentDto): Promise<PaymentResult> {
    // This method gets enhanced with:
    // 1. Logging before execution
    // 2. Performance monitoring 
    // 3. Caching capabilities
    // 4. Automatic retry on failures

    return await this.paymentGateway.process(paymentData);
  }
}

AOP Execution Order

The advice types execute in this specific order:

🔄 Around (before method)
▶️ Before
Method Execution
⏹️ After
✅ AfterReturning OR ❌ AfterThrowing
🔄 Around (after method)

Conclusion

nestjs-saop brings the power and elegance of Spring-style AOP to the NestJS ecosystem. Whether you need logging, caching, performance monitoring, or error handling, this library helps you implement cross-cutting concerns cleanly and efficiently.

The combination of familiar Spring-like syntax, complete TypeScript support, and seamless NestJS integration makes it a perfect choice for building maintainable enterprise applications.

Give it a try in your next NestJS project – your code will thank you! 🚀

📚 Resources:

What's your experience with AOP in backend development? Have you tried implementing cross-cutting concerns in NestJS before? Share your thoughts in the comments below! 💬

Why Real-World Performance is Different from Benchmark Numbers

miinhho — Sat, 01 Mar 2025 23:15:07 +0000

When evaluating the performance of a library, most developers rely on published benchmarks.
These benchmarks often show impressive performance gains compared to competitors — sometimes even 5x or 10x faster.

But there’s a catch: these numbers typically come from static, highly optimized flows, where the same operators and middleware are applied repeatedly.
This allows modern JIT engines to fully optimize the process, leading to artificially high performance numbers.

What Happens in Real-World Systems

In real-world systems, especially large-scale streaming or event-driven systems, the actual data flow is rarely static.

Operators or middleware may change depending on request type, data structure, or user input.
Dynamic branching and real-time decisions prevent JIT engines from fully optimizing the flow.
Buffers, pausing, resuming, and handling errors further complicate optimization.
This dynamic nature significantly reduces the effectiveness of JIT-based performance gains.

My Experiment: Static vs Dynamic Performance

I conducted a performance test on a streaming library I built.
Here’s how it worked:

I processed 1 billion events in batches of 1 million.
In the first test, the same operators/middleware were applied consistently across all events — maximizing JIT optimization.
In the second test, operators were selected dynamically using Math.random, simulating real-world conditions where different transformations may apply to different events.

Test Scenario	Performance Difference vs RxJS
Static (same operators)	8x faster
Dynamic (random operators)	~80% faster

What This Means

The difference is striking:

In a controlled, static flow, my library was over 8x faster than RxJS.
But in a realistic, dynamic flow, that advantage shrank to just 80% faster.

This doesn’t mean my library is slow — even at 80% faster, it still outperforms.
But it highlights the huge gap between artificial benchmarks and real-world performance.

Why This Matters for Enterprise Systems

For enterprise-grade systems, realistic performance matters more than synthetic numbers.

Real-world systems almost never have perfectly static data flows.
They deal with dynamic configurations, feature toggles, request-specific processing, and more.
In such environments, JIT optimization is far less effective, making raw architecture efficiency far more important.

If you’re building or evaluating a performance-critical library,
make sure your benchmarks reflect reality — not just ideal conditions.

Closing Thought

The next time you see a benchmark claiming "10x faster",
ask how the test was conducted.

Was it a perfectly static pipeline?
Were real-world conditions like dynamic operators, error handling, and state transitions included?
Did they intentionally disrupt JIT optimizations to simulate real production?

Performance claims without context can be misleading.
Always dig deeper.

Optional CTA (Call to Action)

If you’re interested in how I built a streaming library optimized for real-world conditions,
check out Asyncrush and the full benchmark results.

Middleware Stream Architecture: How it Breaks Away from Traditional Streams

miinhho — Fri, 28 Feb 2025 09:31:56 +0000

Hellooo! I’ve been diving deep into async data handling lately, and I couldn’t shake the feeling that traditional stream architectures—like RxJS—weren’t quite cutting it for me.

That’s why I came up with something new: the Middleware Stream Architecture, baked into my project Asyncrush.

It’s my first shot at rethinking how we deal with async streams, and I’m excited to share how it stands apart from the usual suspects. Let’s break it down together and see what’s different!

What’s a “Traditional” Stream Architecture?

First, a quick refresher. If you’ve heard of RxJS or Java’s Reactive Streams, you’ve met the classics. These are built on the observer pattern, which works like this:

You’ve got a “stream” pumping out data over time.
An “observer” catches that data and does something with it.
“Operators” step in to transform or filter the data along the way.

Think of a live chat app: messages roll in, and you chain operators like “filter -> transform -> display.” It’s solid and structured, but it’s got some quirks. So, how does Asyncrush shake things up? Let’s dive into the key differences.

Approach: Operators vs. Middleware

Traditional (Operator-Based): Tools like RxJS lean on predefined “operators.” You chain things like map, filter, or merge to shape your stream. Want to double a value? You’d write stream.pipe(map(x => x * 2)). It’s clean and systematic, but you’re stuck with the operator toolbox they give you.
Asyncrush (Middleware-Based): I flipped the script here. Instead of operators, I went with “middleware”—plain old functions you slot into the stream. Doubling a value? Just stream.use(x => x * 2). No predefined list—you craft whatever function fits your vibe.

What’s Different?: Traditional feels like “pick from their toolkit,” while Asyncrush is “build your own tools.” It’s way more freeing and flexible.

Performance: Heavy & Complex vs. Light & Snappy

Traditional: RxJS is a beast—packed with features, but that comes at a cost. Stack a bunch of operators, and it starts churning out objects and crunching complex logic, slowing things down. Big datasets can really bog it down.
Asyncrush: I wanted lean and mean. Middleware runs as simple functions, and I ditched unnecessary abstractions.

What’s Different?:
Think of traditional as a “jack-of-all-trades longsword”—versatile but hefty. Asyncrush is a “sharp, quick dagger”—laser-focused on performance.

Practicality: Theory-Driven vs. Real-World Ready

Traditional: RxJS is perfection on paper. Rooted in reactive programming math, it’s systematic but can take ages to learn. Even simple tasks might churn out long code.
Asyncrush: I zoomed in on real problems. Need retries after an error? Want to split data to multiple spots? I made that stuff easy, skipping the theory for “how do I fix this now?”

What’s Different?:
Traditional chases “textbook elegance,” while Asyncrush goes for “get-it-done convenience.” It’s built for the trenches.

So, What’s the Big Picture?

Boil it down, and traditional stream architectures are like a “massive toolbox”—powerful, but heavy and a bit of a chore to wield.

Asyncrush’s Middleware Stream Architecture? It’s a “sleek multitool”—packing just what you need to move fast and free.

Complexity: Operator chains vs. middleware chains.
Speed: Bulky and slow vs. light and zippy.
Control: Add-on tools vs. built-in flow mastery.
Goal: Theoretical polish vs. practical wins.

Why This Matters to Me (and Maybe You)

Asyncrush came from me scratching my head over traditional limits, wondering, “Can’t this be better?” I wanted stream handling to feel fast, simple, and real—less stress, more joy.

It’s my first go at this, so it’s not perfect yet, but I’d love to hear what you think. Could this flip your async game? Hit me up in the comments—let’s riff on it together!

Middleware Stream Architecture - with Asyncrush

miinhho — Fri, 28 Feb 2025 09:14:13 +0000

Hello everyone!

Async data is everywhere these days—chat apps, IoT, real-time dashboards—and I’ve been thinking there’s got to be a better way to handle it.
So, I came up with something I’m calling the Middleware Stream Architecture, and I’ve built it into a little project called Asyncrush.

It’s my first stab at rethinking async streaming to be faster, more flexible, and honestly, just more fun to work with. If this is your first time hearing about it, stick with me—I’ll walk you through what it’s all about and why I think it’s pretty cool.

Streams + Middleware = Magic

The big idea here is dead simple: take a data stream and plug middleware into it to shape it however you want. You know those moments when messages are flying in or sensor data won’t stop coming? Imagine having a tool that lets you tweak that flow on the fly. That’s where middleware comes in.

If you’ve used Express.js, you’re probably familiar with middleware—those handy little functions that tweak requests as they pass through.
I thought, “Why not bring that vibe to async streaming?” With Asyncrush, you can drop middleware into the stream to transform data, pause it, or even split it off to multiple places. It’s like giving your data stream superpowers.

What Makes It Different?

I’ve played with tools like RxJS (and don’t get me wrong, they’re so awesome), but sometimes they feel like overkill—too complex, too heavy. I wanted to fix that. Here’s how I designed this architecture

Speedy and Light:
I cut out the extra fluff to keep things lean. The more data you throw at it, the more you’ll notice how zippy it is compared to the usual suspects.
Bend It Your Way:
Pause it, slow it down, tweak the data—whatever you need, you’re in control. It’s like a stream you can tune like a guitar.
Real-World Ready:
From handling errors to sending data to multiple spots, it’s built for the messy stuff we actually deal with in real apps.

How fast is it?

(1,000,000,000 events vs RxJS)

Transforms	ops/sec	How much faster
100	4,549,029	+80%
50	8,041,039	+40%
20	27,055,086	+54%
10	43,926,787	+27%
5	85,472,016	+25%
2	167,830,565	+15%

miinhho / Asyncrush

lightweight & fast library for streaming and processing asynchronous events

Asyncrush

High Performance Middleware Streams 🏎️

Asyncrush is a high-performance stream processing library that leverages the middleware pattern inspired by RxJS. Unlike traditional stream libraries, Asyncrush connects middleware using pure functions instead of operators, offering a flexible, efficient, and scalable approach to stream processing. It dramatically improves performance while minimizing memory usage, making it the ideal choice for high-throughput applications.

⚡ Key Features

Blazing Fast Performance: Achieves up to +89% faster performance compared to traditional stream libraries.
Middleware-based Stream Control: Process streams with middleware instead of operators, allowing for dynamic error handling, custom retry policies, and advanced state management.
Memory Efficiency: Minimized object creation and small code size lead to significant reductions in memory consumption.
Developer-Friendly API: The pure function-based API ensures that the library is easy to understand, use, and maintain.
Built-in Error Handling & Backoff: Automatic error handling and backoff strategies allow for…

View on GitHub

Update to more extreme situations (2025-03-02)

How Does It Roll?

Picture a river flowing with data—that’s your stream. Now imagine adding some gear to it:

Middleware: Slap a filter on that river to clean up the water or dye it blue—aka process your data.
Flow Control: Build a dam to hold it back or let it trickle out, keeping things from flooding your app.
Splitting It Up: Divvy the river into streams for different towns—one stream feeding multiple endpoints, no sweat.

The best part? It all works together seamlessly. No crazy setup—just plug in and go.

Where It Shines

Here’s where I see it making a difference:

Chat Apps: Messages streaming in fast? Filter out the trolls with middleware and blast it to every user at once.
Big Data Crunching: Need speed without losing control? Asyncrush handles it like a champ.

Why I’m Hyped About It

Building this, I kept thinking, “I don’t want devs to dread async streams.” Some tools make you jump through hoops or study a novel’s worth of docs. Not this. Asyncrush feels like grabbing a handful of Lego blocks—you snap together what you need, and it just works. Fast. Flexible. Ready for real projects.

What’s Next?

This is my first go at it, so it’s still fresh out of the oven. I’d love for you to kick the tires—tell me what you think, where it could level up. Real-time apps are taking over, and I believe this architecture could be a game-changer for async data. Want to build it with me? Let’s chat in the comments!