NestJS — Enterprise Node.js

Microservice Pipeline: Filters, Pipes, Guards & Interceptors

18 min Lesson 69 of 80

Microservice Pipeline: Filters, Pipes, Guards & Interceptors

Microservice handlers still need validation, authorization, error mapping, and tracing. NestJS lets you use pipes, guards, interceptors, and exception filters in RPC contexts, but the response model differs from HTTP.

Core idea

This feature is about controlling how the application is organized and how it behaves at runtime. These are the points a developer should understand before using it in a real project:

Pipes validate and transform message payloads before @MessagePattern handlers run.
Guards can authorize messages based on payload metadata, headers, or broker context.
Interceptors wrap handler execution and are useful for tracing, timing, and response mapping.
RpcException communicates structured errors back through the microservice layer.
Filters for microservices should emit transport-appropriate error payloads, not HTTP responses.

Practical example

The following example shows the idea in a practical NestJS project. The goal is not to memorize the snippet, but to understand where it belongs in the architecture:

@UseFilters(new RpcValidationFilter())
@Controller()
export class BillingMessageController {
  @MessagePattern({ cmd: 'invoice.create' })
  @UseGuards(ServiceTokenGuard)
  @UsePipes(new ValidationPipe({ transform: true }))
  createInvoice(@Payload() dto: CreateInvoiceMessage) {
    return this.billingService.createInvoice(dto);
  }
}

throw new RpcException({ code: 'CUSTOMER_NOT_FOUND', message: 'Customer does not exist' });

Design note: A microservice pipeline should be just as deliberate as an HTTP pipeline. The only difference is the transport contract: message in, response or event out, no browser status code.

Production checklist

Use DTOs for message payloads, not anonymous objects.
Map domain errors to stable machine-readable error codes.
Add tracing interceptors to both client and server sides.
Avoid throwing raw framework or database errors through broker responses.

Rule of thumb: If the feature makes boundaries clearer and tests easier, it is probably the right choice. If it hides dependencies or makes tracing harder, redesign.

Summary

This lesson covers an advanced NestJS area that matters when building enterprise applications. Focus on clear boundaries, testable behavior, and choosing the right tool for the context instead of using every feature everywhere.