Saltar al contenido
Todas las publicaciones

P4

Monorepo, un solo modelo

De tres repos con tres copias del modelo de datos a un monorepo donde el compilador avisa en la API, la web y el móvil a la vez.

El problema: tres copias del mismo modelo

Trabajo en una plataforma de gestión clínica para un centro de fisioterapia en Lima. Empezó en 2023 como una app en Angular y fue creciendo: una API, una web y una app móvil, cada una en su propio repositorio y cada una con su propia copia del modelo de datos.

El síntoma siempre era el mismo: cambiabas un campo en un repo y los otros dos quedaban desfasados sin que nadie se enterara.

Fotograma del video: tres repos con su propia copia del tipo Cita; al cambiar uno, los otros quedan desfasados

La estructura

Hoy todo vive en un monorepo:

  • apps/api (NestJS), apps/web (Next.js) y apps/mobile en el mismo repositorio.
  • packages/shared guarda el esquema y los tipos que usan las tres.

La idea es simple: lo que usa una sola app se queda en su carpeta, y lo que necesitan dos o más sube a packages/shared. El modelo de datos es el caso más claro de lo segundo, porque es el contrato entre todas las piezas.

Un solo modelo, un solo lugar

El modelo vive en Prisma. Si agrego un campo, por ejemplo estadoPago en una cita, TypeScript marca en la API, la web y el móvil todo lo que tiene que cambiar. Nada queda a medias: el compilador hace de revisor.

Fotograma del video: el modelo compartido cambia y las tres apps se enteran
Fragmento de ejemplo: el modelo Cita en Prisma y un tipo compartido derivado de él para la API y la web

La API es la única puerta

Hay una regla que cuido tanto como el monorepo: ni la web ni el móvil hablan con la base de datos. Todo pasa por la API, así que las reglas de negocio viven en un solo lugar y no se duplican en cada cliente.

Las migraciones están versionadas y se aplican con prisma migrate deploy en el mismo orden en cualquier entorno. Así el esquema siempre es reproducible.

Fotograma del video: la API como única puerta a los datos y las migraciones aplicadas en orden

Por qué monorepo

  • Un cambio, una sola revisión. El campo nuevo, la API que lo expone y las pantallas que lo usan viajan juntos.
  • El error aparece al compilar, no cuando alguien usa la app.
  • Menos duplicación: el tipo se define una vez y se comparte.

Lo que aprendí

El monorepo no es una moda: es una forma de que el compilador haga de revisor. El costo existe: pide más disciplina en la estructura de carpetas y en los límites entre paquetes, para que "compartido" no termine significando "todo depende de todo".

¿Y tú?

¿Prefieres monorepo o repos separados? ¿Por qué?

  • #SoftwareArchitecture
  • #TypeScript
  • #NestJS
  • #Monorepo
  • #DesarrolloDeSoftware

¿Necesitas algo parecido en tu equipo o tu producto?

Cuéntame el contexto y te respondo en menos de 24 horas. Si prefieres revisar la trayectoria antes, el CV está a un clic.