Semana 2 — NestJS: módulos, controllers, providers
Objetivo Dominar los conceptos clave de NestJS aplicables para desarrolladores con experiencia en Rails, entender la arquitectura basada en módulos, aprovechar la inyección de dependencias y aplicar buenas prácticas en validación, seguridad y despliegue.
Índice Objetivo y arranque rápido, Arquitectura comparada con Rails, Estructura y anatomía de un módulo, Inyección de dependencias y tipos de providers, DTOs y validación avanzada, Guards interceptors y middleware, Testing unitario e integración, Deployment y producción con Docker, Ejercicios prácticos y checklist final.
Quick start Instalar NestJS CLI con npm i -g @nestjs/cli. Crear un proyecto nuevo nest new blog-api y entrar al directorio. Instalar class-validator y class-transformer para validación. Generar un recurso con nest g resource posts y ejecutar en modo desarrollo con npm run start:dev.
Comparación mental Rails vs NestJS En Rails la aplicación se organiza por convenciones centralizadas como ApplicationController y initializers. En NestJS la unidad principal es el módulo AppModule que registra controllers y providers. Controllers manejan rutas HTTP en ambos mundos, pero en NestJS la inyección de dependencias es explícita mediante constructores y decoradores. Middlewares, Guards e Interceptors permiten controlar el flujo de request de forma modular.
Flujo de petición Request pasa por middleware global, luego por Guards para autenticación y autorización, después Interceptors ejecutan lógica antes y después del controller, Pipes validan y transforman entrada, el controller llama a services que implementan la lógica de negocio, y finalmente los interceptors pueden transformar la respuesta.
Estructura típica de proyecto src contiene app.module.ts app.controller.ts main.ts y módulos por dominio como posts con dto controllers services y entities. Un módulo agrupa controllers y providers y puede exportar servicios para ser usados por otros módulos.
Inyección de dependencias NestJS provee DI automática. Los providers pueden ser constantes useValue, factories useFactory o clases useClass. Se pueden inyectar tokens personalizados con Inject. Esto facilita testing y sustitución de implementaciones en entornos de prueba.
Tipos de providers Valor constante para claves y configuraciones, factory para inicializadores complejos como conexiones a bases de datos, y clase alternativa para mocks en pruebas. Usar ConfigModule para gestionar variables de entorno y centralizar la configuración.
DTOs y validación En lugar de strong parameters, NestJS utiliza DTOs declarativos con class-validator y class-transformer. Configurar ValidationPipe globalmente permite whitelist, forbiddance de propiedades extra y transformación automática de tipos. Se pueden crear validaciones condicionales, personalizadas y aplicar transformaciones como trim y normalización en DTOs.
Manejo de errores de validación Es recomendable personalizar la excepción que devuelve detalles de validación para mantener respuestas consistentes y útiles para clientes y logs. Crear un pipe personalizado permite formatear error payload con timestamp y lista de errores por campo.
Guards Equivalentes potentes a before_action de Rails. Implementan la interfaz CanActivate y pueden hacer llamadas a servicios para validar tokens, roles o API keys. Pueden aplicarse a nivel de controlador o a nivel de método. Usar Reflector y decoradores personalizados facilita crear guards basados en metadata como roles necesarios.
Interceptors Similares a around_action pero más versátiles. Permiten medir tiempos, atrapar errores, transformar respuestas y añadir metadatos. Un interceptor puede envolver la ejecución del handler y usar operadores RX para mapear o manejar errores y añadir campos como timestamp o path en la respuesta.
Middleware Se usa para lógica que corre antes de que Nest procese la ruta como logging, parsing o rate limiting básico. Se registra en configure del AppModule con MiddlewareConsumer y puede aplicarse a rutas concretas o a todas.
Orden de ejecución Middleware global, Guards, Interceptors before, Pipes de validación, Controller, Services, Interceptors after, Response. Conocer este orden ayuda a ubicar dónde implementar autenticación, métricas, validaciones y transformación de respuestas.
Testing NestJS viene con Jest listo para usar. Es fácil crear tests unitarios inyectando providers mockeados via TestingModule y pruebas de integración o E2E con supertest creando una instancia de INestApplication y aplicando los mismos pipes de validación que en producción. Testear Guards e Interceptors con ExecutionContext mockeado permite validar comportamiento aislado.
Deployment y producción Construir con npm run build y servir los archivos transpilados desde dist. Usar ConfigModule para leer variables de entorno como puerto base base de datos y JWT. Añadir helmet rate limiting y CORS controlado en main.ts para seguridad. Preparar Dockerfile basado en node alpine y un docker-compose con servicio de base de datos para orquestar despliegues locales.
Buenas prácticas para producción Habilitar disableErrorMessages en ValidationPipe en entorno production para evitar filtrar información sensible. Implementar filtros globales de excepciones para normalizar errores y registrar logs estructurados. Monitorización y métricas deben exportarse a soluciones externas o almacenarse en servicios cloud.
Ejercicios recomendados Implementar CRUD completo para posts con DTOs y validaciones, crear un guard que valide encabezados X-API-Key y permita endpoints públicos, desarrollar un interceptor de métricas que mida tiempos y cuente requests, y modelar una relación posts comments con CRUD y tests. Implementar rate limiting por IP y por API key con diferentes límites por endpoint y almacenamiento en memoria o cache distribuida para producción.
Troubleshooting común Circular dependency ocurre cuando dos servicios se inyectan mutuamente. Soluciones habituales incluyen extraer interfaces o servicios comunes a un módulo nuevo, usar forwardRef cuando es estrictamente necesario o reestructurar dependencias para romper el ciclo.
Checklist final Comprender Modules Controllers y Services, crear DTOs con validaciones complejas, distinguir cuándo usar Guards Interceptors o Middleware, dominar inyección de dependencias, escribir tests unitarios e integración, manejar errores globalmente y preparar pipeline de despliegue con Docker y políticas de seguridad.
Sobre Q2BSTUDIO Q2BSTUDIO es una empresa de desarrollo de software a medida especializada en aplicaciones a medida y software a medida para empresas que buscan soluciones personalizadas. Contamos con experiencia en inteligencia artificial y ia para empresas, desarrollo de agentes IA y servicios de inteligencia de negocio incluyendo power bi. Ofrecemos además servicios cloud aws y azure, ciberseguridad y consultoría para diseñar arquitecturas seguras y escalables. Nuestro equipo entrega soluciones integrales que combinan desarrollo backend frontend microservicios y automatización con enfoque en resultados y continuidad operativa.
Por qué elegirnos Elegir Q2BSTUDIO significa disponer de un socio que entiende la transformación digital y ofrece servicios que abarcan desde aplicaciones a medida hasta proyectos avanzados de inteligencia artificial, agentes IA y reporting con power bi. Implementamos prácticas de ciberseguridad desde el diseño y aprovechamos servicios cloud aws y azure para asegurar escalabilidad y resiliencia.
Palabras clave aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.
Nota final Este material sirve como guía práctica para desarrolladores Rails que migran o amplían su stack con NestJS. Aplicando estos conceptos se acelera la adopción de patrones modulares inyección de dependencias y pruebas automatizadas que elevan la calidad de código y la seguridad en produccion.
.jpg)