2-2-Controller

 @Controller('products')

export class ProductsController { constructor(private readonly productsService: ProductsService) {} @Get() @UseGuards(AuthGuard) findAll(): Product[] { return this.productsService.findAll(); } @Post() @UsePipes(ValidationPipe) create(@Body() createProductDto: CreateProductDto) { return this.productsService.create(createProductDto); } }

¡Claro! Vamos a desglosar el código línea por línea para entender cómo funcionan los decoradores en NestJS y cómo estructuran la lógica de un controlador.

1. @Controller('products')

typescript
Copy
Download
@Controller('products')

  • Función: Define que esta clase es un controlador de NestJS y establece la ruta base /products para todas las rutas dentro de él.

  • Equivalente en Laravel: Sería como definir un grupo de rutas en routes/api.php:

    php
    Copy
    Download
    Route::prefix('products')->group(function () { ... });

  • ¿Por qué va antes de la clase?
    Porque NestJS usa decoradores para configurar metadatos que luego el framework interpreta. Aquí le dice: "Esta clase manejará todas las solicitudes bajo la ruta /products".

2. export class ProductsController

typescript
Copy
Download
export class ProductsController { ... }

  • Función: Define la clase del controlador (similar a un Controller en Laravel).

  • Export: Se usa export para que NestJS pueda inyectar esta clase en otros lugares (como en los módulos).

3. constructor(private readonly productsService: ProductsService)

typescript
Copy
Download
constructor(private readonly productsService: ProductsService) {}

  • Función: Inyecta el servicio ProductsService en el controlador (Dependency Injection).

  • Equivalente en Laravel: Sería como inyectar un Service en el constructor de un controlador:

    php
    Copy
    Download
    public function __construct(private ProductService $productService) {}

  • private readonly:

    • private: Solo accesible dentro de la clase.

    • readonly: No se puede reasignar después de la inyección.

4. @Get()

typescript
Copy
Download
@Get()

  • Función: Define que este método manejará solicitudes HTTP GET en la ruta base (/products).

  • Equivalente en Laravel:

    php
    Copy
    Download
    Route::get('/', [ProductController::class, 'findAll']);

  • ¿Por qué va antes del método?
    Porque le dice a NestJS: "Cuando alguien haga un GET /products, ejecuta este método".

5. @UseGuards(AuthGuard)

typescript
Copy
Download
@UseGuards(AuthGuard)

  • Función: Aplica un guardia (similar a un middleware de autenticación en Laravel) para proteger la ruta.

  • Equivalente en Laravel:

    php
    Copy
    Download
    Route::get('/', [ProductController::class, 'findAll'])->middleware('auth');

  • ¿Qué hace?
    Verifica si el usuario está autenticado antes de ejecutar findAll().

6. findAll(): Product[]

typescript
Copy
Download
findAll(): Product[] {
  return this.productsService.findAll();
}

  • Función: Método que devuelve todos los productos (usando el servicio inyectado).

  • Equivalente en Laravel:

    php
    Copy
    Download
    public function findAll() {
    return $this->productService->all();
}

7. @Post()

typescript
Copy
Download
@Post()

  • Función: Define que este método manejará solicitudes HTTP POST en /products.

  • Equivalente en Laravel:

    php
    Copy
    Download
    Route::post('/', [ProductController::class, 'create']);

8. @UsePipes(ValidationPipe)

typescript
Copy
Download
@UsePipes(ValidationPipe)

  • Función: Aplica un pipe de validación (similar a un Form Request en Laravel).

  • Equivalente en Laravel:

    php
    Copy
    Download
    public function store(StoreProductRequest $request) { ... }

  • ¿Qué hace?
    Valida que los datos enviados en el POST cumplan con las reglas definidas en CreateProductDto.

9. create(@Body() createProductDto: CreateProductDto)

typescript
Copy
Download
create(@Body() createProductDto: CreateProductDto) {
  return this.productsService.create(createProductDto);
}

  • @Body(): Extrae los datos del cuerpo (body) de la solicitud HTTP (similar a $request->all() en Laravel).

  • CreateProductDto: Es un objeto que define la estructura y validación de los datos (como un Form Request en Laravel).

  • Equivalente en Laravel:

    php
    Copy
    Download
    public function create(Request $request) {
    $validated = $request->validate([ ... ]);
    return $this->productService->create($validated);
}

Resumen de flujo

  1. @Controller('products') → Define la ruta base (/products).

  2. @Get() → Maneja GET /products.

  3. @UseGuards(AuthGuard) → Protege la ruta.

  4. findAll() → Llama al servicio para obtener los productos.

  5. @Post() → Maneja POST /products.

  6. @UsePipes(ValidationPipe) → Valida los datos.

  7. @Body() createProductDto → Extrae y valida el cuerpo de la solicitud.

  8. create() → Llama al servicio para crear un producto.

¿Por qué los decoradores van antes?

  • NestJS usa metadatos: Los decoradores agregan información que el framework usa para enrutar, validar y proteger las solicitudes.

  • Similar a anotaciones en otros lenguajes: Como las anotaciones @ en Java Spring o los atributos #[...] en PHP 8+.

  • Laravel lo hace en archivos separados: En Laravel, esto se configura en routes/web.php o con middlewares, mientras que NestJS lo hace directamente en el controlador.

Ejemplo completo comparado con Laravel

NestJS (Decoradores)Laravel (Alternativa)
@Controller('products')Route::prefix('products')
@Get()Route::get('/', ...)
@UseGuards(AuthGuard)->middleware('auth')
@Post()Route::post('/', ...)
@UsePipes(ValidationPipe)StoreProductRequest
@Body()$request->all()

Los decoradores hacen que todo esté autodocumentado y centralizado en el controlador, mientras que en Laravel esta configuración está más distribuida

Comentarios

Publicar un comentario

Entradas más populares de este blog

48. ValidationPipe - Class Validator y Class Transformer

  Validación de Datos en NestJS con ValidationPipe, Class-Validator y Class-Transformer Cuando desarrollamos APIs, una de las tareas más comunes -y a veces tediosas- es validar que los datos que recibimos en las peticiones cumplan con ciertos estándares. ¿No sería genial tener una forma sencilla y automatizada de hacer esto? En NestJS, podemos lograrlo con el  ValidationPipe  junto con las librerías  class-validator  y  class-transformer . Antes: Validación Manual Originalmente, nuestro controlador de autos ( cars.controller.ts ) aceptaba cualquier dato sin validación: typescript Copy Download import { Controller , Get , Param , Post , Body , Patch , Delete , ParseIntPipe } from '@nestjs/common' ; import { CarsService } from './cars.service' ; import { CreateCarDto } from './dto/create-car.dto' ; @ Controller ( 'cars' ) export class CarsController { constructor ( private readonly carsService : CarsService ) { } @ Get...
Leer más

32-Modulos

  directorios que se están usando en el ejemplo : Copy Download src/ │ ├── cars/ │ ├── cars.controller.ts # Controlador (maneja las rutas HTTP) │ ├── cars.module.ts # Módulo (registra controlador y servicio) │ └── cars.service.ts # Servicio (lógica de negocio) │ ├── app.module.ts # Módulo principal de la aplicación └── main.ts # Punto de entrada (configuración de NestJS) Explicación breve : cars/ : Contiene los archivos específicos del recurso  Cars  (controlador, módulo y servicio). app.module.ts : Importa y organiza los módulos de la aplicación (en este caso,  CarsModule ). main.ts : Inicia la aplicación y configura el servidor. Esta estructura sigue las  buenas prácticas de NestJS , separando responsabilidades en capas claras. Módulos en NestJS: La Base de tu Aplicación Introducción Cuando comenzamos a explorar NestJS, es normal encontrarnos con una estructura inicial llena de archivos que no siempre entendemos....
Leer más

49. Pipes Globales - A nivel de Aplicación

  Pipes Globales en NestJS: Validación a Nivel de Aplicación En NestJS, los Pipes son una herramienta poderosa para transformar y validar datos. En este post, exploraremos cómo implementar Pipes a nivel global en nuestra aplicación, lo que nos permite centralizar la validación y mantener un código más limpio y consistente. Estructura del Proyecto Antes de comenzar, veamos la estructura de nuestro proyecto: Copy Download src/ │ ├── cars/ │ ├── dto/ │ │ ├── create-car.dto.ts │ │ └── update-car.dto.ts │ ├── interfaces/ │ │ └── car.interface.ts │ ├── cars.controller.ts │ ├── cars.module.ts │ ├── cars.service.ts │ └── constants/ │ └── car.constants.ts │ ├── common/ │ ├── pipes/ │ │ └── validation.pipe.ts │ └── filters/ │ └── http-exception.filter.ts │ ├── app.module.ts ├── app.controller.ts ├── app.service.ts └── main.ts Antes: Validación por Controlador Inicialmente, teníamos que aplicar el  ValidationPipe  en cada método del contro...
Leer más