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.

La estructura
Hoy todo vive en un monorepo:
apps/api(NestJS),apps/web(Next.js) yapps/mobileen el mismo repositorio.packages/sharedguarda 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.


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.

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
Míralo también en
¿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.