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

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.