Achava que o Postman funcionava só no meu computador, mas houve uma interrupção de serviço

• O Postman enfrentou uma interrupção temporária de serviço devido a uma questão global de nuvem
• O incidente foi causado por problemas no provedor de nuvem, gerando erros funcionais e indisponibilidade intermitente para muitos usuários
• A equipe de engenharia realizou a recuperação em tempo real, com o serviço se recuperando gradualmente
• Falhas em parte da função de busca e problemas de cross-dependency foram monitorados e resolvidos continuamente
• Atualmente, o incidente foi resolvido e o serviço foi restaurado ao normal, com monitoramento adicional de estabilidade em andamento

---

Linha do tempo e processo de recuperação da indisponibilidade do Postman

Identificação e impacto da falha (Oct 20, 05:39 ~ 05:52 PDT)

• O aumento na taxa de erros no Postman causou problemas funcionais
• A causa dessa indisponibilidade foi uma ocorrência crítica do provedor de serviço em nuvem
• A equipe do Postman respondeu em colaboração com o fornecedor de nuvem para uma normalização rápida

Recuperação parcial e monitoramento do serviço (Oct 20, 05:56 ~ 17:17 PDT)

• Foi observada recuperação em alguns sistemas
• Houve monitoramento contínuo de desempenho em vários serviços enquanto o trabalho de restauração completa continuou
• A recuperação da maioria das funcionalidades foi confirmada, com foco em evitar novas falhas por meio de monitoramento contínuo

Recuperação completa e normalização do serviço (Oct 20, 19:00 ~ 20:51 PDT)

• Embora ainda houvessem problemas intermitentes em alguns serviços, a maioria dos sistemas se recuperou de forma estável
• Foram resolvidos progressivamente também os erros de cross-dependency e os problemas relacionados à função de busca
• Após a resolução de todos os problemas e a conclusão da restauração total do serviço, houve monitoramento adicional para garantir a estabilidade

---

Resumo e implicações

• O Postman tem alta dependência de ambiente em nuvem, o que significa que é impactado diretamente por interrupções globais
• Isso destaca a necessidade de preparar ferramentas similares ou serviços com aparência de operação local para lidar com falhas de infraestrutura em nuvem
• Durante uma indisponibilidade, monitoramento e comunicação em tempo real são críticos para a manutenção e confiança dos clientes
• No processo de recuperação gradual do serviço, a resposta rápida da equipe e comunicados transparentes são fundamentais
• Reforça-se a necessidade de estabelecer um sistema de monitoramento para confirmar se todos os serviços estão operando normalmente

[GN⁺]

Opinião do Hacker News

• Fico me perguntando se estou deixando de aproveitar alguma coisa por não usar o Postman; como alternativa, uso o recurso "Edit and Resend" do Firefox e, para exemplos reutilizáveis, scripts curl tradicionais.
  • Na empresa usamos o Postman de leve: compartilhamos um arquivo de coleção com diversas requisições contendo cabeçalhos e body para que os devs carreguem facilmente e testem em seus próprios servidores, e também é possível alternar de servidor com um clique. Como alternativa, poderia ser um repositório Git com scripts curl contendo variáveis de ambiente; até pessoas não técnicas conseguem executar testes no Postman.
  • Não é apenas com o Postman: clientes assim conseguem preparar e salvar vários requests de uma vez, criando suites de teste; alguns oferecem recursos como criação de scripts, encadeamento de requests etc. É uma diferença semelhante à de editor de texto versus IDE, e no fim a escolha depende do nível que você precisa.
  • A funcionalidade mais conveniente é que, ao colar uma URL, os parâmetros são parseados automaticamente e podem ser editados facilmente na UI; fora isso, no fim das contas, não é tão diferente do curl que você já conhece.
  • Recentemente tenho trabalhado com Jupyter Notebook e requests; no fim das contas, até usando o Postman, transformar requests em collections vira uma sensação de programar em uma linguagem limitada.
• Também me surpreende que esse tipo de app tenha virado algo baseado em Electron e nuvem; acho que um app TUI de terminal de 10 MB teria sido suficiente. Ah, e existe uma alternativa chamada posting.sh.
  • Concordo com a história do app TUI de 10 MB; atualmente, no mundo de apps Electron, tudo já pesa em gigabytes. Só para lembrar, o pacote do vim tem 2,3 MB, o do curl 1,2 MB e o do lua 362 KB.
  • O motivo de usar Electron é que começou como extensão do Chrome e depois evoluiu para standalone.
  • Usei hurl(https://hurl.dev/) por alguns anos, mas os arquivos só foram se acumulando como texto solto em pastas; desta vez vou testar o posting.sh.
  • Eu estava procurando uma alternativa ao Postman/Bruno/foo para usar em servidor SSH ou container remoto do VS Code, e o posting.sh parecia perfeito.
• RubyMine e os IDEs da JetBrains (e produtos relacionados) incluem um cliente HTTP robusto (Tools -> HTTP Client). Depois do Postman ficar complexo, ele se encaixa bem em cenários onde só precisamos de requisições web simples; não é intenção diminuir quem gosta do Postman, mas senti que ele ficou exagerado para minhas necessidades.
  • O HTTP Client da JetBrains é realmente bom: ao colar um comando curl, ele converte e formata automaticamente; também dá para copiar de volta para curl o que foi alterado.
• Foi justamente por isso que o Yaak(https://yaak.app) foi criado: totalmente offline, sem telemetria, open source e com suporte a Git.
  • Fico curioso sobre a estrutura de licença comercial do Yaak: se a licença Pro é baseada no chamado "princípio da boa-fé", qual é a diferença em relação à licença MIT? Sempre fico curioso sobre licenças comerciais open source e sobre em que situações cada uma funciona melhor.
  • Já uso o Yaak há 6 a 9 meses; no começo, compilava direto do source, e hoje sou usuário pago. Recentemente vi que o Yaak passou a publicar em open metrics o número de assinantes e a receita, o que achei uma forma bastante transparente de operação.
  • Atualmente uso o Bruno e também li uma comparação entre Bruno e Yaak; se o Bruno oferecer todo recurso que eu precisar, quero saber qual seria o diferencial do Yaak em relação a ele.
  • Fiquei curioso se alguém criou uma nova ferramenta concorrente depois de ter criado e vendido o Insomnia; e se não houve nenhuma restrição na negociação.
  • Como eu adorava o produto antes da aquisição do Insomnia, fiquei muito feliz em ver o Yaak como um sucessor espiritual dele; estou torcendo pelo Greg.
• Dependendo do propósito, muitas vezes nem precisamos de um app separado: JetBrains(info), Visual Studio(info) e VSCode(info) suportam arquivos HTTP.
  • O de VSCode é um plugin feito por um dev anônimo, então é difícil tratá-lo como feature nativa.
  • Na nossa organização, como até QA não técnico usa bastante HTTP API, agora o Bruno está desempenhando esse papel bem.
  • O formato de arquivos HTTP não é exatamente igual em todos os produtos, então nossa equipe usa hurl, o time de QA prefere mais o robot framework e alguns usam Bruno.
  • Conforme o time cresce, usamos collections gigantes do Postman para documentação de API, testes de regressão e QA, principalmente dependendo bastante da biblioteca JavaScript do Postman e de código customizado.
• Acredito que a maioria das pessoas já aceitou que o Postman está ficando cada vez mais inchado, com mais recursos e dependência online.
  • Quando a empresa migrou o Postman para online, recebemos e-mail para todos pedindo a desinstalação do Postman. Hoje, o time de TI o cadastrou como software proibido na wiki; antes era usado literalmente em todo lugar.
  • Como o Postman está se tornando uma ferramenta padrão de mercado, todo mundo acabou se adaptando; até pessoal de negócio usa Postman e o compartilhamento de collection virou padrão. Eu detesto usar Postman, mas quando preciso compartilhar trabalho de API, sou obrigado a usar. Faz bem para o negócio do Postman, mas não me parece bom para todos os usuários.
• Fiz um substituto leve e muito simples de Postman, baseado em YAML, o yapi(https://github.com/jamierpond/yapi), que pode ser usado assim:

  yapi -c ./users.yapi.yaml
  

  Exemplo de arquivo YAML (incluindo schema, url, method, path e forma de declarar query params), e basta executar apenas yapi para encontrar facilmente o arquivo de configuração usando fzf.
  • O conceito é realmente interessante e parece que vai funcionar bem quando a gente se acostuma ao fluxo, mas fico curioso por que as estatísticas do GitHub são tão baixas — provavelmente porque todo mundo ainda usa Postman.
• Usei o Paw por bastante tempo, mas ele foi incorporado pela RapidAPI há alguns anos; apesar de pequeno, cumpre o papel perfeitamente. Recentemente, tenho usado uma combinação de Phoenix LiveBook notebook e pacote Req, e dá para lidar diretamente com a linguagem que quiser e transformar dados com liberdade. Se você não conhece Elixir, Jupyter ou outro notebook também pode ser alternativa.
• Bruno + Git é perfeito para a minha equipe: versionamos collections dentro do repositório e é possível usar offline sem dependência externa; devia ter feito isso antes.
  • Havia um bug estranho no import de colar curl, mas já foi resolvido; fora isso estou 100% satisfeito.
• Suspendo totalmente o uso do Postman desde 2018; achei muito chato precisar fazer login para fazer query de API, e, sinceramente, a usabilidade também não me pareceu atraente.