Simulações de app

Uma simulação de app é a que você monta no navegador: você cria, enche de serviços, faz o deploy, e ela responde na URL dela. É o tipo padrão, o que o resto destes docs assume sem dizer, e nada nela exige instalar nada.

Uma simulação, vários serviços

Uma simulação é um contêiner de serviços, e cada serviço é uma API. Uma simulação só serve vários lado a lado, do mesmo jeito que o seu sistema em produção fala com várias dependências, então uma URL pode fazer o papel do seu backend inteiro. Os serviços vêm de três lugares:

• O seu próprio spec OpenAPI, subido e montado em um prefixo de caminho.
• Um spec do catálogo: Stripe, Twilio, Auth0 e o resto, adicionados em dois cliques.
• Endpoints estáticos, respostas escritas na mão que se agrupam em serviços pelo primeiro segmento do caminho.

Eles se misturam sem problema. Uma simulação típica leva a API do próprio time a partir de um spec, um provedor de pagamento do catálogo, e um punhado de endpoints estáticos para aquele canto esquisito que mais nada cobre, tudo sob <domínio>/app/<sua-org>/<slug>, cada serviço no próprio prefixo, e tudo entregue por um deploy só.

Veja Subir e atualizar um spec OpenAPI, Começar pelo catálogo e Endpoints e respostas estáticas.

Tudo pendura na simulação

Tudo de uma simulação fica na barra lateral dela, em grupos:

• Fontes é o que ela serve: os endpoints, o catálogo para adicionar mais, e os contextos que dão forma aos dados gerados.
• Gravações é o que ela lembra: o histórico de requisições e os replays que ela capturou.
• Configurações é o que dá forma a ela: nome e ícone, o runtime do deploy, quem pode alcançar ela, e a configuração de cada serviço.

Duas simulações não dividem nada aqui. Cada uma tem a própria URL, o próprio histórico e as próprias gravações, a própria política de acesso, e é por isso que o corte de sempre é uma simulação por projeto ou por ambiente.

O ciclo

Tudo é editado no app e salvo enquanto você digita; a simulação no ar continua servindo o último estado publicado até você clicar em Fazer deploy, e um deploy leva segundos. Essa separação é o que deixa uma simulação de app confortável de iterar: prepare quantas mudanças quiser, entregue quando estiverem prontas, e a URL nunca muda.

Veja Criar uma simulação para a primeira, e Deploy e URLs para o que um deploy faz.

Quando outro tipo encaixa melhor

• Mocks que devem viver em um repo e ser revisados como código: faça o deploy deles pelo GitHub.
• O mesmo mock offline ou dentro do CI: rode ele portable.
• Respostas que precisam de lógica de verdade: gere uma simulação codegen.

Trocar depois é empacotar os mesmos arquivos de outro jeito: todo deploy de uma simulação de app já produz o pacote portable, que o Rodar localmente entrega para você.