Pare de esperar o backend: mocks HTTP no seu próprio subdomínio

Agnaldo do Nascimento Pereira — Thu, 10 Sep 2026 19:32:41 +0000

Você já ficou parado por causa de uma API?

Se você trabalha em projetos com vários times e precisa integrar com uma API que raramente fica pronta no prazo; se quer validar uma ideia sem montar um backend completo (nem esperar alguém montar); ou se precisa exercitar fluxos de sucesso e erro do seu app sem depender de outro time — mock local, JSON no Slack e “roda só na minha máquina” param de dar conta rápido.
O time de front quer seguir. O mobile quer cobrir 401, 500 e o happy path. O contrato existe no papel. A API real, não.
É exatamente esse tipo de atrito que me fez construir o MockarIo.

O que ele resolve (na prática)

Você cadastra os endpoints que o seu app consome e define quantas variantes de resposta quiser (sucesso, validação, timeout simulado, body diferente). Na hora do teste, seleciona a resposta ativa e segue — sem pedir deploy, sem abrir ticket, sem esperar o outro squad.
Cada conta trabalha com subdomínio próprio para servir os mocks. Também dá para criar organizações e trazer mais de um usuário — útil quando o mock deixa de ser “só meu” e vira referência do time.
Fluxo mental simples:

Você descreve o contrato (método, path, respostas).
O app (ou o Postman) chama a URL do seu subdomínio. O seu app pode ter uma variante que apenas troca o host da aplicação apontando para o host mockar.io da sua conta, isso é que eu recomendaria.
Você troca a variante de resposta e retesta o fluxo — ainda sem depender do backend real. Editor no browser (app.mockar.io), serve em {org}.server.mockar.io.

Por que isso importa em time

Mock compartilhado “de todo mundo” vira colisão de path, fixture errada e “quem mudou minha response?”. Isolar por organização/subdomínio deixa claro: este host é o nosso contrato, não o sandbox genérico da empresa.
E o ponto central não é ter “mais um painel de mocks” — é destravar o trabalho quando a API ainda não existe, está instável ou não cobre o cenário que você precisa hoje.

Vale a pena se…

Seu front/mobile está bloqueado no backend
Você quer prototipar ou demo com URL HTTPS de verdade
Precisa de vários cenários (ok / erro / vazio) sem pedir favor a outro time # Talvez não seja o que você quer se…
Prefere só um framework open source self-hosted e infinitamente customizável
Não precisa de URL compartilhada — um mock 100% local já resolve

O meu motivador

Como desenvolvedor android de grandes projetos com vários times, por vezes de N empresas diferentes, para conseguir utilizar o app de forma fluida (já que o homologação era complicado) eu desenvolvi esse projeto, assim o app apenas troca o host e eu consigo navegar por todos os fluxos do app, fluxos felizes e de erro para validar cada possível ponta de integração antes mesmo da api estar no ar

Experimente

Estou lançando a plataforma como um saas, não se preocupe, tem plano free :)

Se testar, me conta qual dor ainda sobra no seu fluxo (cenários, auth, import de OpenAPI, etc.) — feedback de quem vive o bloqueio de API todo dia é o que mais importa.
Obrigado por ler.