تركيب Decorators باستخدام applyDecorators

In a real NestJS enterprise API, almost every route handler ends up carrying a tall stack of decorators: Swagger docs, auth guards, role checks, and response shaping. Repeating that stack on every endpoint is verbose and error-prone.

• Duplication: the same six lines copied onto dozens of handlers.
• Drift: someone forgets @ApiBearerAuth() on one route and the docs lie.
• Noise: the actual business intent is buried under cross-cutting concerns.

This lesson teaches how to collapse a recurring decorator stack into a single reusable @ApiSecureEndpoint() using NestJS's applyDecorators.

applyDecorators is a helper from @nestjs/common. It takes any number of decorators and returns one new decorator that applies all of them in order when used.

• It works with method decorators, class decorators, and property decorators.
• The decorators run top-to-bottom, exactly as if you had written them by hand.
• It does not change behavior — it only composes. Whatever the original stack did, the composed decorator does identically.

Think of it as function composition for the decorator world.

Before composing, recall the shape of a custom decorator. A method decorator is a function that receives the target, the property key, and the property descriptor. NestJS decorators like UseGuards() are decorator factories: calling them returns such a function.

This plain-TypeScript example shows the mechanics with no framework involved — a logging decorator factory applied to a class method.

To appreciate applyDecorators, see what manual composition looks like in pure TypeScript. A composer returns a single method decorator that loops over the inner decorators and invokes each.

This standalone snippet mirrors how NestJS's applyDecorators works under the hood — running every decorator against the same target.

Now bundle the realistic stack. Our goal decorator @ApiSecureEndpoint() should attach JWT auth, role enforcement, the Swagger bearer scheme, and the common error responses.

• UseGuards wires the runtime protection.
• ApiBearerAuth tells Swagger UI to send the token.
• The ApiUnauthorizedResponse / ApiForbiddenResponse document the failure modes once and for all.

With the composer in place, the controller collapses to a single intent-revealing line per route. The four concerns are still active — they are just declared once inside the factory.

Compare this to scene 1: the same protection and documentation, far less noise.

The real ergonomic win comes from parameterizing the factory. Because ApiSecureEndpoint is a function, it can accept options and forward them to the inner decorators — for example the required roles and a summary string.

This lets one decorator express the full security + docs contract of a route in a single, readable call.

Enterprise endpoints also document their success payload. applyDecorators can fold in a typed ApiOkResponse, and you can combine it with a serialization interceptor so the contract is enforced both in code and in the docs.

• type drives the Swagger response schema and example.
• Adding UseInterceptors(ClassSerializerInterceptor) guarantees the DTO transforms apply.

Within a composed decorator, the relative order of UseGuards and UseInterceptors matters at runtime. NestJS runs guards before interceptors regardless, but when you list multiple guards their execution order follows the array, and multiple interceptors nest in declaration order.

• Put authentication guards before authorization guards so an unauthenticated request short-circuits with 401, not 403.
• Swagger-only decorators (ApiOperation, ApiOkResponse) have no runtime ordering effect — they only attach metadata.

Because a composed decorator is a plain factory function, you can unit-test that it wires the metadata you expect without booting Nest. Use the Reflector or read metadata keys directly off the decorated method.

This standalone TypeScript example demonstrates the underlying idea — reading back metadata that a decorator attached via Reflect.defineMetadata.

Composition is powerful but can hide important details. Reach for a composed decorator only when the stack is genuinely repeated and stable.

• Do compose a fixed security + docs envelope used across many routes.
• Avoid composing highly route-specific details like a unique ApiOperation summary or one-off query params — pass those as arguments or leave them inline.
• Avoid burying rarely-used behavior; a reader should still grasp what a route does from its decorators.

Good composed decorators reduce noise without becoming a black box.

You want a single @ApiSecureEndpoint() that applies a JWT guard, a roles guard, the Swagger bearer scheme, and shared error responses. Which approach is idiomatic in NestJS?

You learned to collapse a repetitive decorator stack into one ergonomic decorator.

• applyDecorators from @nestjs/common composes any number of decorators into a single one that applies them in order.
• A composed decorator is just a factory function, so it can accept options (roles, summary, response type) and forward them to the inner decorators.
• Bundle stable cross-cutting concerns — UseGuards, ApiBearerAuth, shared ApiUnauthorizedResponse/ApiForbiddenResponse — and keep route-specific details as arguments or inline.
• Mind guard ordering: authentication before authorization so a missing token yields 401, not 403.
• Because it is plain TypeScript, the composed decorator stays testable via reflected metadata.

Result: controllers that read as intent (@ApiSecureEndpoint({ summary, roles })) instead of a wall of boilerplate.