Simulaciones de app
Una simulación de app es la que armas en el navegador: la creas, la llenas de servicios, la despliegas, y responde en su URL. Es la clase por defecto, la que el resto de estos docs da por sentada, y nada de ella exige instalar nada.
Una simulación, muchos servicios
Una simulación es un contenedor de servicios, y cada servicio es una API. Una sola simulación sirve varios lado a lado, igual que tu sistema en producción habla con varias dependencias, así que una URL puede hacer de todo tu backend. Los servicios vienen de tres lugares:
- Tu propia spec OpenAPI, subida y montada en un prefijo de ruta.
- Una spec del catálogo: Stripe, Twilio, Auth0 y las demás, agregadas en dos clics.
- Endpoints estáticos, respuestas escritas a mano que se agrupan en servicios por su primer segmento de ruta.
Se mezclan sin problema. Una simulación típica lleva la API propia del equipo desde una spec, un proveedor de pago del catálogo, y un puñado de endpoints estáticos para el rincón raro que nada más cubre, todo bajo <dominio>/app/<tu-org>/<slug>, cada servicio en su propio prefijo, y todo entregado por un solo despliegue.
Consulta Subir y actualizar una spec OpenAPI, Empezar desde el catálogo y Endpoints y respuestas estáticas.
Todo cuelga de la simulación
Todo lo de una simulación vive en su barra lateral, en grupos:
- Fuentes es lo que sirve: los endpoints, el catálogo para agregar más, y los contextos que dan forma a los datos generados.
- Grabaciones es lo que recuerda: el historial de solicitudes y los replays que capturó.
- Configuración es lo que le da forma: nombre e icono, el runtime del despliegue, quién puede llegar a ella, y la configuración propia de cada servicio.
Dos simulaciones no comparten nada acá. Cada una tiene su URL, su historial y sus grabaciones, su política de acceso, y por eso el corte habitual es una simulación por proyecto o por entorno.
El ciclo
Todo se edita en la app y se guarda mientras escribes; la simulación en marcha sigue sirviendo el último estado desplegado hasta que haces clic en Desplegar, y un despliegue tarda segundos. Esa separación es lo que hace cómodo iterar sobre una simulación de app: prepara todos los cambios que quieras, entrégalos cuando estén listos, y la URL nunca cambia.
Consulta Crear una simulación para la primera, y Despliegue y URLs para saber qué hace un despliegue.
Cuándo encaja mejor otra clase
- Mocks que deben vivir en un repo y revisarse como código: despliégalos desde GitHub.
- El mismo mock sin conexión o dentro de CI: córrelo portable.
- Respuestas que necesitan lógica real: genera una simulación codegen.
Pasarse después es empaquetar los mismos archivos de otra forma: cada despliegue de una simulación de app ya produce el paquete portable, que Correr en local te entrega.