Conceptos clave

Mockomat está construido alrededor de un principio central: la intención del dominio debe permanecer visible desde el modelo hasta el runtime.

Cada decisión que tomas — nombrar una entidad, definir un tipo de campo, establecer una relación — fluye a través de una pipeline conectada: desde tu modelo de dominio, a través de la definición de API, hacia el comportamiento de runtime en vivo, y finalmente hacia un backend generado que te pertenece. Esta página explica las capas conceptuales que hacen esto posible.

1. Capa de dominio: lo que el sistema significa

La capa de dominio es la base semántica de tu proyecto. Define la estructura y el significado de tus datos antes de que se decida cualquier detalle de API o implementación.

Entidades y tablas

Una entidad (o tabla) representa un concepto de negocio real: Customer, Order, Invoice, Subscription. Cada entidad tiene un nombre, un conjunto de atributos (columnas) y opcionalmente una o más relaciones con otras entidades.

El nombrado importa. Mockomat te anima a usar el lenguaje de negocio real de tu equipo en lugar de nombres genéricos de ejemplo. Un modelo construido con Customer y Subscription comunica la intención mucho mejor que Table1 y Table2.

Atributos

Cada atributo tiene:

• Nombre — un identificador descriptivo (ej. firstName, totalAmount, isActive)
• Tipo — el tipo de dato: string, number, boolean, date, json
• Flag de obligatorio — si el campo debe tener siempre un valor
• Flag de sortable — si el campo puede usarse para ordenar resultados
• Flag de searchable — si el campo participa en consultas de búsqueda
• Flag de filterable — si el campo soporta operaciones de filtro

Estos flags influyen directamente en cómo la capa de API expone tus datos. Un campo marcado como sortable: true queda disponible para operaciones de ordenamiento en consultas GraphQL. Un campo marcado como filterable: true soporta expresiones de filtro.

Relaciones

Las relaciones conectan entidades y expresan patrones de propiedad o referencia de negocio:

• One-to-One (1:1) — ej. User → Profile
• One-to-Many (1:n) — ej. Customer → Order[]
• Many-to-Many (m:n) — ej. Product ↔ Category

Cada relación tiene una dirección y una cardinalidad. La definición de la relación determina cómo el runtime resuelve las consultas: cuando consultas un Order, los datos relacionados de Customer se ensamblan desde la fuente de datos subyacente basándose en estas definiciones.

Por qué esta capa es importante

• Reduce la divergencia de nombrado — todos en el equipo usan el mismo vocabulario.
• Mejora la alineación entre equipos — los desarrolladores de frontend y backend comparten un único modelo de verdad.
• Hace la arquitectura revisable — la intención del dominio es explícita, no está enterrada en el código.
• Habilita la automatización — la generación de código, la exposición de API y el comportamiento de runtime se derivan de esta capa.

cc-01-domain-layerMissing

Modelo de la capa de dominio con entidades y relaciones.

2. Capa de definición API: cómo se expone el sistema

La capa de API traduce la intención del dominio en una superficie de consultas y operaciones. Mockomat utiliza un enfoque code-first GraphQL: las definiciones de tu modelo se traducen automáticamente en un esquema GraphQL completamente tipado.

Generación dinámica de esquema

Cuando se activa un proyecto, Mockomat genera un esquema GraphQL de forma dinámica:

1. Cargar definiciones del modelo — leer todas las entidades, atributos, relaciones y configuración del proyecto.
2. Construir tipos GraphQL — cada entidad se convierte en un tipo de objeto GraphQL; cada atributo se convierte en un campo tipado.
3. Construir puntos de entrada de consulta — se generan consultas de lista y detalle para cada entidad.
4. Registrar resolvers — los resolvers a nivel de campo manejan la recuperación de datos, el mapeo y las consultas de relaciones.
5. Aceptar solicitudes — el esquema está listo para servir consultas inmediatamente.

Esto significa que nunca escribes archivos de esquema manualmente. El esquema siempre está sincronizado con tu modelo.

Estructura de consultas

Cada entidad genera automáticamente dos tipos de consulta:

• Consulta de lista — devuelve una colección paginada con filtrado y ordenamiento opcionales.
• Consulta de detalle — devuelve un único elemento por su identificador.

Por ejemplo, si modelas una entidad Product, las consultas generadas podrían verse así:

query {
  products(offset: 0, limit: 20, filter: { ... }, sort: { ... }) {
    id
    name
    price
    category {
      id
      name
    }
  }
}

query {
  product(id: "abc-123") {
    id
    name
    price
    description
  }
}

Filtrado

El sistema de filtros soporta expresiones componibles y con tipado seguro:

Operador	Descripción	Tipos aplicables
equals	Coincidencia exacta	Todos los tipos
notEquals	Negación	Todos los tipos
contains	Coincidencia de subcadena	Strings
greaterThan / greaterThanOrEqual	Rango (superior)	Numbers, Dates
lessThan / lessThanOrEqual	Rango (inferior)	Numbers, Dates
in	Valor en conjunto	IDs, Enums
isNull / isNotNull	Verificación de nulo	Todos los tipos

Los filtros pueden combinarse usando operadores lógicos AND y OR, y pueden anidarse para expresiones complejas.

Ordenamiento

Los campos marcados como sortable: true en el modelo de dominio pueden usarse en operaciones de ordenamiento. La dirección de ordenamiento es ascendente (ASC) o descendente (DESC).

Paginación

Mockomat utiliza paginación basada en offset:

• offset — número de elementos a omitir (por defecto: 0)
• limit — número de elementos a devolver (por defecto: 20)

Este modelo es simple y funciona bien para la mayoría de los casos de uso. La respuesta incluye el arreglo de datos junto con metadatos de paginación.

cc-02-endpoint-configMissing

Vista de definición y configuración de endpoints API.

3. Capa de runtime: cómo se valida el comportamiento

La capa de runtime es donde tus decisiones de modelo y API se prueban contra la ejecución real de consultas. Responde a la pregunta: ¿se comporta el sistema de la manera que pretendías?

Cómo funciona el mock runtime

El motor de mock runtime es el núcleo del valor de Mockomat. Acepta consultas GraphQL y las traduce en operaciones MongoDB a través de una pipeline de cuatro etapas:

1. GraphQL Request Parser — parsea la cadena de consulta entrante en un árbol de sintaxis abstracta (AST).
2. Query Planner — analiza el AST junto con los metadatos del modelo para crear un plan de ejecución.
3. MongoDB Query Builder — traduce el plan de ejecución en una pipeline de agregación MongoDB.
4. Result Assembler — reestructura los resultados de MongoDB para que coincidan con la estructura de respuesta GraphQL esperada.

Esta pipeline se ejecuta en cada consulta. Debido a que MongoDB almacena datos en colecciones planas (desnormalizadas), el runtime simula estructura relacional — uniendo datos relacionados, resolviendo campos anidados y ensamblando la respuesta final como si proviniera de un backend completamente relacional.

Previsualización vs consumo externo

El mismo endpoint de runtime sirve a dos audiencias:

• Previsualización — la página de Runtime dentro de la aplicación donde pruebas consultas, inspeccionas las formas de respuesta y validas el comportamiento durante el modelado.
• Consumidores externos — tu aplicación frontend, suite de pruebas o pipeline CI llamando al mismo endpoint de mock API.

Ambos usan el mismo endpoint REST: POST /mock/{slug}/graphql. Esto significa que lo que validas en la previsualización es exactamente lo que los consumidores externos recibirán.

Qué significa la validación en la práctica

La validación en runtime no es solo "¿devuelve datos la consulta?". Confirma:

• Formas de campos — ¿son los tipos y estructuras devueltos los que esperas?
• Consultas de relaciones — ¿se resuelven correctamente los objetos anidados?
• Comportamiento de paginación — ¿producen offset y limit segmentos consistentes?
• Estabilidad de ordenamiento — ¿produce el ordenamiento en un campo un orden predecible?
• Precisión de filtros — ¿coinciden las expresiones de filtro con el subconjunto correcto de datos?
• Manejo de nulos — ¿se representan correctamente los campos opcionales como nulos cuando no existen datos?

cc-03-runtime-flowMissing

Flujo modelo-a-runtime con puntos de control de validación.

4. Fuentes de datos y asociación de campos

Cada atributo en tu modelo necesita una fuente de datos. Mockomat soporta varios tipos de asociación que determinan de dónde provienen los valores de los campos:

OFF_FIELD — Campos de datasets reales

Asocia un atributo a un campo de un dataset del mundo real (ej. Open Food Facts). Esto te da a tu mock API datos realistas y diversos que se comportan como datos de producción.

Usa esto cuando desees:

• Nombres de productos, categorías o medidas realistas
• Grandes volúmenes de datos variados
• Datos que se sientan auténticos en demos y pruebas

FAKE — Datos generados (Faker)

Asocia un atributo a un generador Faker que produce datos sintéticos realistas: nombres, emails, direcciones, fechas, precios y más.

Usa esto cuando desees:

• Datos personales (nombres, emails, números de teléfono)
• Datos financieros (precios, números de cuenta)
• Datos temporales (fechas, marcas de tiempo)
• Cualquier tipo de dato no cubierto por datasets reales

CONST — Valores constantes

Asocia un atributo a un valor fijo que es el mismo para cada registro.

Usa esto cuando desees:

• Valores de estado por defecto (ej. "active")
• Valores de configuración fijos
• Datos provisionales durante el modelado temprano

COMPUTED — Valores derivados (futuro)

Permitirá definir valores de campo mediante expresiones basadas en otros campos. Esto está planificado para una versión futura.

cc-04-data-sourcesMissing

Configuración de asociación de campos con diferentes tipos de fuente de datos.

Disponibilidad de fuentes de datos

Free User

Los usuarios free tienen acceso a todos los tipos de asociación (OFF_FIELD, FAKE, CONST) y datasets públicos. La carga de datasets personalizados está disponible en los planes Enterprise.

5. Aislamiento de proyectos y multi-tenancy

Cada proyecto de Mockomat opera en su propio contexto aislado:

• Espacio de datos separado — cada proyecto tiene sus propias colecciones MongoDB para datos mock.
• Esquema independiente — el esquema GraphQL se genera por proyecto basándose en su modelo específico.
• Endpoints basados en slug — cada proyecto obtiene una ruta URL única (/mock/{slug}/graphql).
• Alcance por tenant — todo el acceso a datos se filtra por tenant, asegurando un aislamiento estricto entre organizaciones.

Esto significa que múltiples equipos pueden trabajar en diferentes proyectos simultáneamente sin ningún riesgo de fuga de datos o conflictos de esquema.

Aislamiento enterprise

Enterprise User

Los tenants enterprise obtienen garantías de aislamiento adicionales: colecciones de datos dedicadas, límites de sesión configurables, limitación de tasa personalizada y deploy on-premise opcional para soberanía completa de datos.

6. IA + Arquitectura juntos

La IA acelera la creación. Mockomat preserva la calidad de la estructura y la explicabilidad mientras los requisitos evolucionan.

La plataforma está diseñada para trabajar junto con herramientas de IA, no para reemplazarlas. Mientras la IA puede generar fragmentos de código rápidamente, Mockomat proporciona el contexto estructural que el código generado por IA a menudo carece:

• Consistencia de esquema — tu modelo de dominio es la única fuente de verdad, ya sea que lo construyas manualmente o con asistencia de IA.
• Verificación en runtime — cada cambio puede validarse a través de la pipeline de previsualización antes de que llegue a producción.
• Decisiones trazables — los cambios en el modelo son explícitos y revisables, no están enterrados en código generado por IA.

Perspectiva del integrador

Developer / Integrator

Trata los artefactos generados como puntos de partida, no como verdad final. Mantén el modelo como la fuente de intención y deja que el comportamiento de runtime confirme la calidad. Al integrar flujos de trabajo asistidos por IA, usa el modelo de Mockomat como el contrato al que los consumidores generados por IA deben ajustarse.

Perspectiva enterprise

Enterprise User

El valor a largo plazo proviene de la arquitectura repetible, no solo de una producción inicial rápida. La continuidad del dominio es el punto de control para la evolución multi-equipo. Usa los modelos de Mockomat como artefactos de gobernanza que sobreviven a los ciclos de sprint individuales.