Por que preferi Go para construir o SchemaPing

Tem coisa que só faz sentido depois que você erra. O SchemaPing é uma delas.

A ideia de SaaS

Tudo começou com uma dor muito específica: APIs mudam. A gente integra, testa, deploya e, de repente, o parceiro muda o campo amount de number parastring. O seu sistema quebra. O time de produto fica nervoso. Você descobre a mudança no pior momento possível.

Eu pensei: "e se eu monitorasse a estrutura das respostas de API e avisasse quando algo mudasse?" Uma ferramenta que detectasse schema drift antes que ele virasse dor de cabeça. Legal, né? Foi aí que nasceu a ideia do SchemaPing: um SaaS que observa endpoints JSON, tira snapshots e compara as mudanças.

Por que Go?

Eu já escrevia código em outras linguagens, mas um amigo da faculdade me apresentou Go. A primeira coisa que me encantou foi a simplicidade deliberada. Não tem mágica. O código é explícito, rápido de compilar, e a concorrência é simples de raciocinar. Para uma ferramenta que precisa fazer requisições, comparar JSON e rodar em intervalos, Go parecia perfeito.

Além disso, eu queria que o SchemaPing fosse um CLI primeiro. Go é praticamente feito para isso: binário único, cross-compilação fácil, dependências mínimas. Rodar um agente em um servidor ou no notebook de alguém não deveria exigir Docker, Python, Node — nada. Só um executável e um arquivo de configuração.

Decisões técnicas

O primeiro desafio foi comparar JSONs de forma útil. Eu não queria só dizer "mudou". Queria dizer o que mudou: campo adicionado, removido, tipo alterado, nullability diferente. Por isso o diff do SchemaPing trabalha em cima do schema da resposta, não do valor exato.

Outra escolha importante foi manter tudo local. Os snapshots são arquivos JSON em ~/.schemaping/snapshots/. Sem banco, sem servidor, sem lock-in. A pessoa tem o controle total. Se quiser, conecta webhooks para receber alertas no Slack, Discord ou onde preferir.

Ah, e claro: CI desde o primeiro commit. Mesmo projeto pequeno merece testes automatizados, lint e build garantido. Isso me salvou várias vezes enquanto eu pivotava a ideia.

O pivot

Construir um SaaS é mais do que código. É preciso entender mercado, precificação, modelo de distribuição, suporte. Em algum momento percebi que a proposta comercial não estava funcionando. Não era falta de utilidade — a ideia era útil. Mas a forma como eu estava oferecendo não fazia sentido para quem tinha a dor.

Aí eu decidi abrir o código. Se a ferramenta é útil, ela pode ajudar mais gente sendo open source. E se não der certo comercialmente, pelo menos o código continua vivo e acessível. Foi um alívio. Open source tirou a pressão do pitch perfeito e colocou o foco no que eu realmente gosto de fazer: resolver problemas com código bem feito.

"Open source não é plano B. Às vezes é o plano que deixa a ideia respirar."

A estrela do esquisitão

Dias depois de publicar no GitHub, apareceu uma estrelinha. Uma. De um usuário que eu não conheço. Até hoje não recebi mensagem dele. Só imagino que ele achou útil, deu a estrela e seguiu a vida. E sabe de uma coisa? Foi uma das conquistas mais legais que já tive como dev. Alguém, em algum lugar do mundo, viu valor no que eu construí.

O SchemaPing não virou unicorn. Não me rendeu dinheiro. Mas me ensinou sobre Go, sobre open source, sobre pivotar em público e sobre como uma ferramenta pequena pode gerar uma história grande. E isso, para mim, já valeu demais.

Se quiser ver o código, está aberto no GitHub. Fique à vontade para abrir uma issue, mandar um PR ou só dar uma estrela — sem mensagem, também vale.