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; las llamadas desde tu propio código llevan una clave API del proyecto (consulta Integradores):
POST /mock/{slug}/graphql
Authorization: Bearer mck_your_api_keyEl 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 | ej. String, Integer, Float, Boolean, Date, JSON, Enum | Tipo en las exportaciones; elige el tipo de los datos vinculados |
| Obligatorio | Si el campo debe tener un valor | Marcado como obligatorio en la exportación OpenAPI |
| Sortable | Se guarda con el modelo | Marca columnas de lista ordenables en la exportación de código; la mock API ordena por cualquier atributo asociado (sortField) |
| Searchable | Si el campo participa en búsqueda | Incluido en la búsqueda searchTerm de las operaciones de lista |
| Filterable | Se guarda con el modelo | Sin efecto en la mock API — el filtrado usa los parámetros de la operación |
| Asociación | Fuente de datos: SOURCE o CONSTANT; COMPUTED solo en los atributos que ya lo tienen (no se evalúa) | 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
Asociar los datos
En el panel Mappings del board vinculas primero la tabla a una tabla del pool de datos (Tabla canónica): Sugerir propone una, o buscas tú mismo en todas las tablas. Después vinculas sus atributos a sus columnas (SOURCE); Adoptar … seguras acepta de una vez todas las sugerencias seguras. Los atributos que deben quedar vacíos se marcan con No necesita mapeo. Detalles: Data Sources & Field Mapping (en inglés).
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(pageSize: 5) {
items {
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 — establece el tamaño de página predeterminado (como máximo 100 registros por página) y el orden predeterminado.
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:
- Usa el estado actual de tu modelo, tus asociaciones y tus operaciones.
- Ejecuta la operación de lista de la tabla sobre los datos importados.
- Muestra los datos, con una indicación si falta algo.
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 |
|---|---|---|
| Sin asignar a datos importados | La tabla no está vinculada a datos importados; la API no devuelve filas para ella | Vincula la tabla y sus atributos en el panel Mappings |
| Sin enlace de API | La vista no está vinculada a ninguna operación de lista; no se cargan datos | Vincula una operación de lista en los ajustes de la vista |
| Sin campo identificador | La vista no tiene campo identificador; al hacer clic en una fila no se abre la vista de detalle | Define el campo identificador en los ajustes de la vista |
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.