Workspace
El workspace es donde las decisiones de dominio, API y runtime permanecen conectadas en un único flujo operativo. Es el entorno central donde construyes, configuras, validas e iteras sobre tu proyecto de mock API.
Esta página recorre cada área principal del workspace y explica qué hace cada área, cómo usarla eficazmente y qué aspectos tener en cuenta.
Áreas del workspace
El workspace está organizado en áreas distintas, cada una enfocada en una parte específica del flujo de trabajo de modelado y diseño de API. Puedes moverte entre estas áreas en cualquier momento — los cambios en un área se reflejan inmediatamente en las demás.
1. Contexto de proyecto y navegación
El contexto de nivel superior del workspace controla en qué proyecto estás trabajando y cómo navegas entre las diferentes vistas.
Qué puedes hacer
- Cambiar entre proyectos activos — si tienes múltiples proyectos, el selector de proyecto te permite cambiar de contexto sin perder tu lugar.
- Mantener el contexto de modelado estable — el workspace recuerda qué tabla, vista o panel de configuración tenías abierto.
- Moverte entre vistas — navega entre el board de modelado, el editor de tablas, el diseño de API y la previsualización de runtime.
Configuración del proyecto
Cada proyecto tiene un slug único que determina la URL de tu endpoint API:
POST /mock/{slug}/graphqlEl slug se genera automáticamente a partir del nombre de tu proyecto, pero puedes personalizarlo. Mantén los slugs cortos, en minúsculas y con guiones (ej. customer-portal, ecommerce-demo).
Barra de contexto de proyecto y cambio de vista.
2. Board de modelado
El board de modelado es el área de diseño estructural — un canvas visual donde creas y organizas tus entidades de dominio y sus conexiones.
Trabajar con tablas
El board muestra cada entidad como una tarjeta de tabla. Puedes:
- Crear nuevas tablas — agregar entidades que representan conceptos de negocio (ej.
Product,Customer,Order). - Posicionar tablas — arrastrar y soltar tarjetas de tabla para organizarlas espacialmente. Agrupa entidades relacionadas para mayor claridad visual.
- Editar propiedades de tabla — renombrar tablas, configurar opciones de visualización y gestionar metadatos.
- Eliminar tablas — quitar entidades que ya no se necesitan.
Líneas de relación visual
Las relaciones entre tablas se muestran como líneas visuales que conectan las entidades relacionadas. Las líneas indican:
- Dirección — qué entidad posee la relación (dirección de la flecha).
- Cardinalidad — el tipo de relación (1:1, 1:n, m:n) mostrado mediante anotaciones en la línea.
- Puntos de conexión — qué columnas están involucradas en la relación.
Esta representación visual facilita la revisión de tu estructura de dominio de un vistazo y la detección de relaciones faltantes o incorrectas.
Controles del board
- Zoom y desplazamiento — navega boards grandes con el zoom de la rueda del ratón y arrastra para desplazarte.
- Ajuste a cuadrícula — la alineación opcional a cuadrícula mantiene las tablas posicionadas de forma ordenada.
- Auto-layout — organiza automáticamente las tablas para una legibilidad óptima.
Board de modelado con entidades de dominio conectadas.
3. Configuración de tablas y atributos
Cuando seleccionas una tabla en el board de modelado, el panel de editor de tabla se abre con opciones de configuración detalladas para la entidad y sus atributos.
Propiedades de tabla
Cada tabla debe tener:
- Un nombre claro — usa sustantivos en singular que coincidan con tu lenguaje de negocio (
Invoice, noinvoices_table). - Una descripción — opcional pero útil para la comunicación del equipo y la documentación.
Configuración de atributos
Para cada atributo (columna), configura:
| Propiedad | Descripción | Impacto |
|---|---|---|
| Nombre | El identificador del campo | Se convierte en el nombre del campo GraphQL |
| Tipo | string, number, boolean, date, json | Determina los operadores de filtro y la validación |
| Obligatorio | Si el campo debe tener un valor | Afecta la nulabilidad en GraphQL |
| Sortable | Si el campo soporta operaciones de ordenamiento | Habilita el parámetro sort en consultas |
| Searchable | Si el campo participa en búsqueda | Incluido en la resolución de consultas de búsqueda |
| Filterable | Si el campo soporta expresiones de filtro | Habilita el parámetro filter en consultas |
| Asociación | Fuente de datos: OFF_FIELD, FAKE o CONST | Determina qué datos devuelve el campo |
Convenciones de nombrado
Un nombrado consistente hace tu modelo legible y tu código generado predecible:
- Atributos — usa
camelCase(ej.firstName,totalAmount,isActive) - Tablas — usa
PascalCasesingular (ej.Customer,OrderItem) - Evita abreviaciones —
descriptiones mejor quedesc,quantityes mejor queqty
Selección de objetos de datos
Al asociar un atributo a un campo de dataset real (OFF_FIELD), se abre un panel lateral con:
- Búsqueda — encuentra objetos de datos por nombre o etiqueta
- Filtros de etiquetas — reduce los resultados por categoría
- Previsualización de muestra — ve valores de ejemplo antes de confirmar una asociación
Esto asegura que elijas la fuente de datos correcta para cada atributo.
Editor de tabla con panel de configuración de atributos.
Panel de selección de objetos de datos con búsqueda y previsualización.
4. Definición de relaciones
Las relaciones conectan tus entidades y definen cómo fluyen los datos entre ellas. Establecer correctamente las relaciones es crítico — determinan cómo las consultas anidadas se resuelven en runtime.
Tipos de relación
| Tipo | Ejemplo | Significado |
|---|---|---|
| One-to-One (1:1) | User → Profile | Cada usuario tiene exactamente un perfil |
| One-to-Many (1:n) | Customer → Order[] | Cada cliente tiene múltiples pedidos |
| Many-to-Many (m:n) | Product ↔ Category | Los productos pertenecen a múltiples categorías y viceversa |
Lista de verificación de calidad
Antes de finalizar una relación, haz estas preguntas:
- ¿Propiedad o referencia? — ¿Representa esta relación una propiedad real (un cliente posee sus pedidos) o una referencia (un pedido referencia un método de pago)?
- Claridad de dirección — ¿Es obvio cuál entidad es el padre y cuál es el hijo?
- Comportamiento de consulta — Cuando consultas el padre, ¿deberían incluirse los datos del hijo por defecto? ¿Y en la dirección inversa?
- Corrección de cardinalidad — ¿Es esto realmente 1:n, o podría ser m:n en el futuro?
Cómo las relaciones afectan al runtime
En runtime, las relaciones determinan cómo el motor de consultas ensambla datos anidados. Cuando consultas:
query {
customers(limit: 5) {
id
name
orders {
id
totalAmount
}
}
}El runtime usa la definición de relación para buscar los registros de Order relacionados para cada Customer. Si la relación está mal configurada (dirección incorrecta, referencia de clave foránea faltante), los datos anidados estarán vacíos o serán incorrectos.
Configuración de relación y cardinalidad.
5. Integración del diseño API
El área de diseño API te permite controlar cómo tu modelo de dominio se expone como una API GraphQL. No todas las entidades u operaciones necesitan ser públicas — la vista de diseño API te ayuda a exponer solo lo que tiene sentido para la fase actual.
Nombrado de consultas
Mockomat genera nombres de consulta automáticamente a partir de los nombres de tus entidades, pero puedes personalizarlos:
- Consulta de lista — por defecto usa la forma plural (ej.
products,customers) - Consulta de detalle — por defecto usa la forma singular (ej.
product,customer)
Elige nombres que coincidan con cómo tu equipo de frontend piensa sobre los datos. El nombre de la consulta se convierte en el punto de entrada en cada solicitud GraphQL.
Exposición de operaciones
Tú controlas qué operaciones están disponibles:
- Habilitar/deshabilitar consultas de lista — decide si los consumidores pueden obtener colecciones.
- Habilitar/deshabilitar consultas de detalle — decide si los consumidores pueden obtener registros individuales.
- Configurar valores predeterminados de paginación — establece el tamaño de página predeterminado y los límites máximos.
Principios de diseño
- Comienza restringido — expón menos operaciones primero, luego amplía a medida que el modelo se estabilice.
- Nombre con intención — los nombres de consulta son parte de tu contrato API. Cambiarlos después afecta a todos los consumidores.
- Valida antes de exponer — usa la previsualización para confirmar el comportamiento antes de compartir el endpoint con tu equipo.
Vista de diseño API alineada con las tablas del modelo.
6. Previsualización y flujo de indicaciones
La previsualización debe ser parte de cada iteración de modelado, no un paso final. Es el ciclo de retroalimentación que mantiene la honestidad de tu modelo.
Cómo funciona la previsualización
Cuando abres la previsualización, Mockomat:
- Genera un esquema GraphQL a partir de tu modelo actual.
- Ejecuta una consulta de ejemplo contra tus datos asociados.
- Devuelve los resultados junto con indicaciones de disponibilidad.
La previsualización muestra tanto la respuesta de datos como cualquier problema que necesite atención.
Tipos de indicaciones
Las indicaciones son señales accionables que te ayudan a identificar y corregir problemas del modelo:
| Indicación | Significado | Acción |
|---|---|---|
| Atributo sin asociar | Un campo no tiene fuente de datos configurada | Asigna una asociación OFF_FIELD, FAKE o CONST |
| Metadatos de endpoint faltantes | Una consulta u operación carece de configuración requerida | Abre la vista de diseño API y completa la configuración |
| Inconsistencia de configuración | Un campo está marcado como sortable pero no tiene un tipo de dato compatible | Revisa la combinación de tipo y flag del atributo |
| Advertencia de relación | La entidad o columna destino de una relación no existe | Verifica la definición de relación en el editor de tabla |
Flujo de trabajo de iteración
El flujo de trabajo más productivo sigue un ciclo ajustado:
- Haz un cambio en el modelo — agrega una tabla, modifica un atributo, crea una relación.
- Abre la previsualización — ejecuta una consulta e inspecciona los resultados.
- Revisa las indicaciones — resuelve cualquier advertencia o error.
- Actualiza el diseño API — ajusta los nombres de consulta o la exposición de operaciones si es necesario.
- Repite — continúa hasta que el modelo sea estable y la previsualización esté limpia.
Este ciclo debe tomar segundos, no minutos. Cuanto más rápido iteres, mayor será la calidad de tu modelo final.
Vista de previsualización con indicaciones de disponibilidad accionables.
7. Vistas y navegación por enlaces cruzados
Las vistas proporcionan diferentes perspectivas sobre el mismo modelo subyacente. En lugar de navegar a través de menús, puedes moverte entre contextos relacionados usando enlaces cruzados.
Vistas disponibles
- Vista de board — el canvas visual de modelado que muestra tablas y relaciones.
- Vista de detalle de tabla — vista enfocada en una sola entidad con configuración completa de atributos.
- Vista de diseño API — configuración de consultas y operaciones para la entidad seleccionada.
- Previsualización de runtime — ejecución de consultas en vivo e inspección de respuestas.
Navegación por enlaces cruzados
Cuando estás trabajando en una vista, los enlaces a contextos relacionados están disponibles en línea. Por ejemplo:
- Desde una vista de detalle de tabla, puedes saltar directamente a la previsualización de runtime para probar las consultas de esa tabla.
- Desde la previsualización de runtime, puedes regresar al editor de tabla si notas un problema con un campo.
- Desde la vista de diseño API, puedes saltar al board de modelado para revisar la estructura completa del dominio.
Este modelo de navegación te mantiene en flujo — nunca necesitas volver "al dashboard" para cambiar de contexto.
Navegación por enlaces cruzados entre vistas del workspace.