Actualización de DTOs con mapped types en NestJS para perfil y usuario

Contenido del curso

Fundamentos y Primer CRUD

Base de Datos y Persistencia con TypeORM

Autenticación y Autorización

Tu API Completa

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0038:56

Actualización de DTOs con mapped types en NestJS para perfil y usuario

Curso de Backend con NestJS

Clase 16 de 35

Clase 16 / 35

Recursos

Si trabajas con NestJS y manejas relaciones uno a uno entre entidades como usuario y perfil, seguramente te has topado con el dolor de duplicar DTOs para crear y actualizar. Aquí te muestro cómo resolverlo con Mapped Types, una utilidad oficial de NestJS que te permite reutilizar validaciones, mantener tu código limpio y propagar cambios en cascada sin escribir el doble.

¿Qué problema resuelven los Mapped Types en NestJS?

Cuando ya tienes un CreateUserDTO con validaciones estrictas (email, password, perfil anidado), crear un UpdateUserDTO desde cero implica copiar cada decorador y solo cambiarlos a opcionales. Eso es duplicación pura.

¿Qué es Mapped Types en NestJS? Es un paquete oficial que transforma DTOs existentes en variantes nuevas (parciales, omitidas, seleccionadas) reutilizando sus validaciones. Lo instalas con npm i @nestjs/mapped-types.

La documentación oficial lo ubica en techniques > validation > Mapped Types [01:05]. Tiene una advertencia sobre conflictos con Swagger y GraphQL, pero esos se resuelven después.

¿Cómo usar PartialType para crear un UpdateDTO sin duplicar código?

La idea es simple: en lugar de clonar manualmente, extiendes el DTO original. PartialType toma todos los campos requeridos del DTO base y los marca como opcionales conservando el resto de validaciones.

El flujo queda así:

Separas tus DTOs en una carpeta dtos/ con user.dto.ts y profile.dto.ts.
Defines CreateProfileDTO con sus validaciones (@IsNotEmpty, @IsURL para el avatar, etc.).
Exportas UpdateProfileDTO como PartialType(CreateProfileDTO).

Con eso, todos los campos del create se vuelven opcionales en el update sin reescribir un solo decorador. Si necesitas que algún campo siga siendo obligatorio en el update, lo sobrescribes y listo.

¿Cuándo conviene usar OmitType junto con PartialType?

Aquí aparece un caso interesante. Si tu CreateUserDTO tiene un perfil anidado validado contra CreateProfileDTO, al hacer PartialType(CreateUserDTO) heredas esa validación estricta del perfil. Resultado: cuando intentas actualizar solo el nombre dentro del perfil, NestJS te exige el lastName completo [12:30].

La solución elegante combina dos utilidades de Mapped Types:

OmitType(CreateUserDTO, ['profile']) para sacar el perfil del DTO base.
PartialType sobre ese resultado para volver opcionales email y password.
Redefines profile con UpdateProfileDTO, que ya es parcial.

Así logras flexibilidad real: el cliente envía solo lo que quiere actualizar, sin inventarse campos ni cargar con validaciones que no aplican.

¿Por qué activar whitelist en el ValidationPipe?

Por defecto, NestJS ignora los campos que no están en el DTO. Eso es permisivo y puede esconder errores del cliente.

¿Qué hace whitelist en NestJS? Activa el modo estricto del ValidationPipe para que rechace cualquier propiedad que no esté declarada en el DTO. Se configura en el main.ts junto con forbidNonWhitelisted: true.

Con esa configuración, si alguien manda age en un update donde no existe ese campo, recibe un error claro: property age should not exist. Mejor feedback, menos bugs silenciosos.

¿Cómo manejar errores y relaciones en el update con TypeORM?

Aquí hay dos detalles que rompen muchas implementaciones reales.

¿Por qué tu try-catch no atrapa errores en save?

Si haces return this.userRepo.save(user) sin await, devuelves la promesa antes de que se resuelva. NestJS la ejecuta fuera del scope de tu try-catch, así que cualquier error termina como un 500.

La corrección es directa:

Usa const updated = await this.userRepo.save(user); dentro del try.
Devuelve updated al final.
En el catch, lanza una excepción controlada como bad request con un mensaje descriptivo [25:40].

¿Cómo evitar que el merge sobrescriba el perfil con undefined?

Cuando haces findOneBy({ id }) sin cargar la relación del perfil y luego haces merge, TypeORM completa el perfil con undefined. Al guardar, intenta poner lastName: null y choca con el constraint not null.

La fix es cambiar a findOne({ where: { id }, relations: ['profile'] }). Así el merge tiene los datos previos del perfil y solo reemplaza lo que viene en el payload.

¿Vale la pena cargar relaciones siempre o solo cuando se necesita?

Esta decisión es un trade-off clásico de ingeniería. Cargar la relación en findOne simplifica el código (lo reutilizas en update y en getById), pero también lo arrastra a operaciones donde no la necesitas, como un delete.

Dos enfoques válidos:

Pureza de código: dejas findOne con la relación y lo reutilizas en todos lados.
Performance: en delete haces un query directo con el id y evitas el join innecesario.

En bases de datos pequeñas o con tráfico moderado, optimizar ese join es overengineering. La diferencia se nota cuando hablas de millones de requests concurrentes en un data warehouse robusto. Para cientos o miles de peticiones, prioriza claridad.

¿Cómo exponer el perfil sin anidarlo siempre?

Si no quieres que getUser devuelva el perfil anidado por defecto, crea un endpoint dedicado. Por ejemplo, un método getProfileByUserId en el servicio que reutilice el findOne con relación y devuelva solo user.profile. Luego lo expones como GET /users/:id/profile en el controlador.

Tienes así dos estrategias conviviendo:

Endpoint anidado: una sola request trae usuario y perfil, ideal para tablas en frontend.
Endpoint específico: pides el perfil cuando lo necesitas, sin cargar relaciones innecesarias en otros lugares.

¿Cuál de las dos estrategias usarías tú en producción? Cuéntame en los comentarios cómo resolviste tu propio caso de DTOs anidados.

Carlos Rodríguez

Hace un año

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private usersRepository: Repository<User>,
  ) {}

  async findAll() {
    const users = await this.usersRepository.find({
      relations: ['profile'],
    })

    return users
  }

  async findOne(id: number) {
    const user = await this.findUserById(id)

    return user
  }

  async create(body: CreateUserDto) {
    try {
      const newUser = await this.usersRepository.save(body).catch()

      return newUser
    } catch (error) {
      if (
        error instanceof QueryFailedError &&
        error.message.includes('duplicate key value violates unique constraint')
      ) {
        throw new BadRequestException('Email already exists')
      }

      throw new InternalServerErrorException('Error creating user')
    }
  }

  async update(id: number, body: UpdateUserDto) {
    const user = await this.findUserById(id)

    try {
      const updatedUser = this.usersRepository.merge(user, body)

      const savedUser = await this.usersRepository.save(updatedUser)

      return savedUser
    } catch (error) {
      if (
        error instanceof QueryFailedError &&
        error.message.includes('duplicate key value violates unique constraint')
      ) {
        throw new BadRequestException('Email already exists')
      }

      throw new InternalServerErrorException('Error updating user')
    }
  }

  async delete(id: number) {
    const user = await this.findSingleUserById(id)

    await this.usersRepository.delete(user.id)
  }

  private async findUserById(id: number) {
    const user = await this.usersRepository.findOne({
      where: { id: id },
      relations: ['profile'],
    })

    if (!user) {
      throw new NotFoundException(`User with id ${id} not found`)
    }

    return user
  }

  // Para no hacer una consulta de anidación innecesaria
  private async findSingleUserById(id: number) {
    const user = await this.usersRepository.findOneBy({ id })

    if (!user) {
      throw new NotFoundException(`User with id ${id} not found`)
    }

    return user
  }
}

Comentarios (10)10 comentarios

Daniel Alexander Muelas Rivera

Josué Eliezer Gómez Soto

Andres Martinez

Hace 9 meses

Ulqernesh Karvenae

Hace un mes

Fredy Herrera

Hace 9 meses•editado

Estuardo Leonel Lopez Par

leonel islas gonzález

Hace 2 meses•editado

Maria Alejandra Luna Tito

Alexander Flores Rayme

Jaime David Burbano Montoya

Cristian palacios

Hace 8 meses

Miguel Rodriguez

Fundamentos y Primer CRUD

Crea una API RESTful con NestJS

Instalación del CLI de NestJS y primer proyecto con API

Creación de endpoints dinámicos para consultar usuarios en NestJS

Operaciones CRUD en APIs REST con Postman

Método PUT para actualizar usuarios con ID automático

Manejo de status codes HTTP en NestJS

DTOs y validación automática de datos en APIs con NestJS

Servicios y lógica de negocio en NestJS

Variables de entorno seguras en NestJS

Programación modular en NestJS con UserModule

Base de Datos y Persistencia con TypeORM

Configuración de PostgreSQL con Docker y Docker Compose

Configuración de PostgreSQL con TypeORM en aplicaciones NestJS

Creación de entidades ORM con decoradores en TypeScript

Repository Pattern con TypeORM en NestJS

Relaciones uno a uno entre usuarios y perfiles en PostgreSQL

Actualización de DTOs con mapped types en NestJS para perfil y usuario

Generación automática de módulos CRUD con NestJS y AI

Relación uno a muchos con TypeORM

CRUD de categorías con IA en NestJS

Relaciones many-to-many con TypeORM y validación de arrays

Reutilización de servicios entre módulos en NestJS

Migraciones en TypeORM sin perder datos

Cómo evitar perder datos al migrar columnas

Autenticación y Autorización

Hashing de contraseñas con Bcrypt en NestJS

Excluir campos sensibles con ClassTransformer

Autenticación local con Passport en NestJS

Endpoint de login con Passport en NestJS

Implementación de JSON Web Token para autenticación en NestJS

Rutas protegidas con JWT en NestJS

User ID automático desde JWT en NestJS

Tu API Completa

Autogenera resúmenes e imágenes con OpenAI en NestJS

Documentación automática de APIs con Swagger en NestJS

Preparar tu API NestJS para producción

Desplegar aplicación Node.js a producción con Railway y PostgreSQL

Desarrollo de API REST escalable con NestJS en producción

Actualización de DTOs con mapped types en NestJS para perfil y usuario