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, ej. String, Integer, Float, Boolean, Date, JSON, Enum
• Flag de obligatorio — si el campo debe tener siempre un valor
• Flag de searchable — si el campo participa en la búsqueda searchTerm de las operaciones de lista
• Flags de sortable y filterable — se guardan con el modelo; sortable además marca columnas de lista ordenables en la exportación de código

De estos flags, solo searchable cambia la mock API. El ordenamiento funciona con cualquier atributo vinculado a una columna de datos (sortField), y el filtrado usa los parámetros que defines en una operación (ver API Design (en inglés)).

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(page: 1, pageSize: 20, sortField: "price", sortDirection: ASC) {
    items {
      id
      name
      price
      category {
        id
        name
      }
    }
    total
  }
}

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

Filtrado

Los filtros se definen por operación en el diseño de API — filtros de alcance fijos y parámetros de quien llama, cada uno con un operador:

Operador	Descripción	Tipos aplicables
eq	Igual	Todos los tipos
neq	Distinto	Todos los tipos
gt / gte	Mayor que / mayor o igual	Números, fechas
lt / lte	Menor que / menor o igual	Números, fechas
in	Uno de los valores de una lista	Todos los tipos
like	Contiene (sin distinguir mayúsculas)	Cadenas
notIn	Ninguno de los valores de una lista (solo filtros de alcance)	Todos los tipos
isNull / isNotNull	Es null / no es null (solo filtros de alcance)	Todos los tipos

Todos los filtros de una operación se combinan con AND; no hay OR ni anidamiento en el momento de la consulta.

Ordenamiento

Se ordena con sortField (un nombre de atributo) y sortDirection — ascendente (ASC) o descendente (DESC).

Paginación

Mockomat usa paginación por páginas:

• page — número de página, empezando en 1 (por defecto: 1)
• pageSize — registros por página, como máximo 100 (por defecto: el tamaño de página por defecto de la operación, 25 salvo que se cambie)

La respuesta envuelve los registros en items, junto a total, page y pageSize.

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 page y pageSize 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 tres tipos de asociación que determinan de dónde provienen los valores de los campos (el editor de atributos ofrece Fuente de datos y Constante, y solo muestra Calculado en los atributos que ya tienen una asociación calculada):

SOURCE — Columnas de datasets importados

Asocia un atributo a una columna del pool de datos compartido — datasets importados: datos abiertos donde existe una fuente verificada, datos de ejemplo generados para los blueprints. El runtime sirve las filas importadas y nunca inventa valores.

Usa esto cuando desees:

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

CONSTANT — Valores constantes

Fija un valor único en el atributo. El runtime lo devuelve en cada fila, tanto en las filas de datos importados como en las filas compuestas a partir de pools de valores.

Usa esto cuando desees:

• Valores de estado por defecto (ej. "active")
• Valores de configuración fijos

COMPUTED — Valores derivados (no evaluados)

Guarda una expresión sobre otros campos del mismo registro (ej. un nombre completo a partir del nombre y el apellido). El runtime no evalúa expresiones, por lo que un campo calculado no forma parte de la respuesta. El editor de atributos ya no ofrece Calculado; un atributo que ya tiene una asociación calculada la conserva y se marca como no evaluado.

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

Todos los planes, incluidas las sesiones de invitado, tienen los mismos tipos de asociación y el mismo pool de datos compartido.

5. Aislamiento de proyectos y multi-tenancy

Cada proyecto de Mockomat opera en su propio contexto aislado:

• Pool de datos compartido y de solo lectura — los datos mock provienen de un pool compartido de datasets importados; un proyecto solo lee las tablas a las que está vinculado y nunca modifica los datos del pool.
• 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 — modelos, miembros y claves API pertenecen a un tenant, y cada solicitud se comprueba contra él, 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.

Límites enterprise

Enterprise User

El aislamiento es el mismo en todos los planes. Enterprise se acuerda con nuestro equipo comercial: límites como proyectos, solicitudes y tamaño del equipo se ajustan por contrato.

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.