Melhores ferramentas CLI leves para desenvolvimento

A maior parte do dia de um desenvolvedor backend é composta por ciclos pequenos e rápidos. Disparar uma requisição para um endpoint, ler o JSON, ajustar, repetir. Se você usar uma GUI pesada para isso, gastará mais tempo esperando carregar do que realizando o trabalho.

Ferramentas CLI leves invertem essa situação. Elas são distribuídas como um único binário ou um pacote `npx` (que pode ser executado com `npx`), iniciam em menos de um segundo e fazem um único trabalho sem um assistente de configuração. Você as integra em scripts shell e tarefas de CI, e elas não atrapalham. Para trabalho com API e backend, um pequeno conjunto delas cobre a maior parte do ciclo: enviar requisições, analisar respostas, expor uma porta local e executar sua suíte de testes.

Este guia escolhe dez ferramentas que merecem um lugar no `PATH` de um desenvolvedor backend. Cada seção mostra o comando que prova seu funcionamento. O tema é "pegada" (footprint): o que instala rápido, inicia rápido e exige quase nada antes de ser útil. Para uma visão mais ampla de como elas se encaixam, o guia de desenvolvimento de API define o contexto.

O que torna uma ferramenta CLI "leve" para desenvolvimento

Leveza é sobre "pegada" (footprint) e atrito, não sobre quantos recursos uma ferramenta agrupa. Ao decidir o que pertence ao seu kit, considere quatro coisas:

• Tamanho e formato da instalação. Um único binário estático ou um pequeno pacote `npx` é melhor do que qualquer coisa que traga um runtime e um lockfile.
• Velocidade de inicialização. A ferramenta deve estar em execução antes que você volte para o seu editor. Binários Rust e Go iniciam frios em milissegundos, o que é importante quando você os chama em um loop.
• Configuração para o primeiro resultado. Zero configuração para um padrão útil é o ideal. Se precisar de um arquivo de projeto, uma conta e um dashboard antes, não é leve.
• Componibilidade. Ela lê stdin, escreve stdout, define um código de saída real e pode ser encadeada com a próxima ferramenta. É isso que faz uma ferramenta pequena valer mais do que seu tamanho.

As ferramentas abaixo estão listadas aproximadamente da menor e mais focada em uma única tarefa para as mais completas. curl já está na sua máquina; o restante pode ser instalado rapidamente.

curl

curl é a base contra a qual todas as outras ferramentas HTTP são medidas. Ele já está em quase todas as máquinas, fala todos os protocolos que você irá tocar e faz exatamente o que você manda. Para uma verificação rápida de que um endpoint está ativo, nada é mais rápido para usar.

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue"}'

O -s silencia o medidor de progresso para que a resposta seja encadeada de forma limpa. Adicione -i para ver os cabeçalhos, -w '%{http_code}' para imprimir apenas o código de status e --fail para fazer o curl retornar uma saída diferente de zero em caso de 4xx ou 5xx, que é o que você quer dentro de uma verificação de CI.

Melhor para: scripts, verificações de saúde de CI e qualquer requisição que você queira copiar, colar e compartilhar. Um comando curl funciona na máquina de qualquer colega de equipe.

Limitações sinceras: a sintaxe dos flags é densa e o tratamento do corpo JSON é manual. Para requisições interativas rápidas, as próximas duas ferramentas são mais amigáveis.

HTTPie

HTTPie (http) é o curl com as arestas afiadas removidas, feito para humanos digitarem requisições manualmente. JSON é o padrão, a saída é colorida e formatada, e você constrói uma requisição a partir de itens simples key=value em vez de memorizar flags.

http POST httpbin.org/post name=apidog role=api-tool active:=true

Isso envia um corpo JSON de {"name": "apidog", "role": "api-tool", "active": true}. O = define uma string, := define um valor JSON bruto e header:value define um cabeçalho. Sem precisar colocar um blob JSON entre aspas, sem a contabilidade de -H e -d. A resposta retorna formatada e bonita (pretty-printed).

Melhor para: exploração interativa de API onde a legibilidade é prioridade.

Limitações sinceras: é um pacote Python, então inicia mais lentamente do que um binário nativo e precisa de Python na máquina. Se a velocidade de inicialização for importante, use xh.

xh

xh é a sintaxe do HTTPie em um único binário Rust. Ele reimplementa o estilo de item de requisição do HTTPie, então name=value e := funcionam da mesma forma, mas ele é distribuído como um arquivo estaticamente linkado sem tempo de execução (runtime) e inicia cerca de 30% mais rápido. Ele também suporta HTTP/2 e HTTP/3.

xh POST httpbin.org/post name=apidog age:=24

A mesma ergonomia do HTTPie, inicialização quase instantânea. Por ser um único binário sem dependências, ele se encaixa em uma imagem de CI leve ou em um contêiner sem precisar do Python. O projeto xh no GitHub distribui binários pré-construídos para Linux, macOS e Windows.

Melhor para: desenvolvedores que gostam da sensação do HTTPie, mas querem velocidade nativa e uma instalação sem dependências para scripts e contêineres.

Limitações sinceras: ele cobre a superfície comum do HTTPie, não todos os plugins. Para quase todo o trabalho de requisição, essa lacuna nunca aparece.

jq

jq torna todas as outras ferramentas HTTP mais úteis. É um único binário que filtra e reformata JSON na linha de comando, permitindo extrair um campo de uma resposta de API em vez de analisar todo o "blob".

curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'

Isso imprime apenas a contagem de estrelas. jq possui uma linguagem de consulta completa: .items[] | .name mapeia sobre um array, select(.active) filtra, e -r fornece saída bruta sem aspas para que você possa encadeá-la em uma variável shell. É a cola entre uma chamada de API e o restante do seu script.

Melhor para: extrair e transformar campos de respostas JSON em scripts e CI.

Limitações sinceras: a sintaxe da consulta tem uma curva de aprendizado, e transformações profundamente aninhadas podem se tornar enigmáticas. Para acesso simples a campos, é trivial.

gh (GitHub CLI)

gh traz a API do GitHub para o seu terminal sem que você precise escrever uma única chamada curl contra ela. Ele lida com a autenticação uma vez via gh auth login, então encapsula pull requests, issues, releases e repositórios em comandos simples. Para equipes de backend cujo fluxo de deploy e revisão vive no GitHub, ele remove uma aba do navegador do ciclo.

gh pr create --title "Add rate limiting" --body "Closes #42" --base main

Isso abre um PR da sua branch atual. gh pr checks monitora o CI, gh run watch acompanha um workflow ao vivo, e gh api oferece um cliente autenticado e paginado para qualquer endpoint que os comandos encapsulados não cobrem.

Melhor para: scripts no próprio GitHub: abrir PRs do CI, criar releases e consultar a API sem gerenciar tokens manualmente.

Limitações sinceras: é apenas para GitHub, então uma empresa que usa GitLab ou Bitbucket não tirará proveito.

ngrok

ngrok expõe uma porta local a uma URL pública através de um túnel seguro. Construindo um manipulador de webhook, ou precisa que alguém acesse seu servidor de desenvolvimento de fora da sua rede? Ele transforma o localhost em um link compartilhável em um único comando. O agente é um binário sem dependências que roda em qualquer lugar.

ngrok http 8080

Isso encaminha uma URL pública https:// para a sua porta local 8080 e a imprime no terminal. Ele também executa um inspetor de tráfego em http://127.0.0.1:4040 onde você pode reproduzir cada requisição que passou, o que é um verdadeiro economizador de tempo ao depurar um pagamento ou um webhook Git que você não controla.

Melhor para: desenvolvimento de webhooks, compartilhar um trabalho em andamento com um colega de equipe e testar callbacks de terceiros contra código local.

Limitações sinceras: é um serviço comercial com um plano gratuito; o plano gratuito rotaciona sua URL a cada sessão e impõe limites de taxa. Para HTTPS local estável com um nome fixo, use mkcert.

mkcert

mkcert cria certificados HTTPS confiáveis localmente com zero configuração. Escrito em Go por Filippo Valsorda, é um único binário que cria uma autoridade de certificação local, a instala nos seus armazenamentos de confiança do sistema e emite certificados que seu navegador aceita sem aviso. É assim que você executa https://localhost localmente sem o temido cadeado vermelho.

mkcert -install
mkcert localhost 127.0.0.1 myapp.local

A primeira linha configura a CA local uma vez. A segunda emite um certificado e uma chave para os nomes que você lista, prontos para serem entregues ao seu servidor de desenvolvimento ou proxy reverso. Sem incantamentos OpenSSL, sem certificado autoassinado que você ignora a cada recarregamento. Testar redirecionamentos OAuth, cookies seguros ou qualquer coisa que se comporte de forma diferente via HTTPS fica muito mais fácil.

Melhor para: obter HTTPS real e confiável em um ambiente de desenvolvimento local para que corresponda à produção.

Limitações sinceras: é apenas para desenvolvimento. Nunca use certificados mkcert em produção e proteja a chave da CA raiz que ele gera; ela pode assinar para qualquer nome em sua máquina.

watchexec

watchexec reexecuta um comando sempre que arquivos são alterados. É um único binário Rust que monitora um diretório e reinicia seu servidor ou reexecuta seus testes no momento em que você salva. Ele respeita o .gitignore por padrão, então não será ativado por artefatos de build.

watchexec -e py -r 'pytest tests/'

O -e py filtra para arquivos Python, e -r reinicia um processo de longa duração em vez de empilhar novos. Aponte-o para qualquer comando: watchexec -r 'go run .' para um servidor Go, watchexec 'npm test' para uma suíte JS. É agnóstico à linguagem, então uma ferramenta cobre todos os projetos em vez de um observador por stack.

Melhor para: ciclos apertados de edição-execução em um servidor local ou suíte de testes, sem um modo de monitoramento específico de framework.

Limitações sinceras: ele monitora e reexecuta; não faz recarga de módulo a quente (hot-module reload) nem preserva o estado em processo.

Docker CLI

O Docker CLI é a ferramenta mais pesada aqui, e ela conquista seu lugar. Quando você precisa de um Postgres real, Redis ou uma dependência inteira para desenvolvimento local, um único docker run oferece uma instância descartável para jogar fora quando terminar. Sem instalação em nível de sistema, sem serviços remanescentes.

docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16

O --rm exclui o contêiner na saída, -e define a senha e -p mapeia a porta para o seu host. Seu aplicativo se conecta a localhost:5432 e você obtém um banco de dados limpo a cada execução. Troque postgres:16 por redis:7 ou qualquer imagem e o padrão se mantém.

Melhor para: iniciar serviços de apoio para desenvolvimento local e testes de integração, de forma reprodutível, sem poluir sua máquina.

Limitações sinceras: não é leve no sentido binário; precisa de um daemon em execução e de disco e memória reais. Mas o CLI é scriptável e focado no terminal, e para infraestrutura local reprodutível, nada se compara.

apidog-cli

Uma vez que você está trabalhando com API na linha de comando, a peça que falta é o seu projeto de API real: seus endpoints, esquemas, ambientes e cenários de teste. Apidog distribui o apidog-cli, a CLI leve que conecta o terminal a esse projeto. Ele é instalado como um pacote npm e oferece um caminho scriptável para projetar, importar, simular (mock) e testar recursos sem abrir o aplicativo de desktop.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run -t <scenario_id> -e <env_id> -r cli

apidog run executa um cenário de teste salvo contra um ambiente e imprime um resultado passo a passo no terminal. Ele sai com 0 quando todas as asserções são aprovadas e diferente de zero em caso de falha, então ele se encaixa diretamente em um gate de CI. Além dos testes, a CLI cobre grupos de comandos reais: endpoint e schema para design, import e export para mover especificações (OpenAPI, Swagger, Postman) para dentro e para fora, mock para expectativas de mock, e environment e variables para configuração. A saída é um JSON estruturado com agentHints.nextSteps, razão pela qual também se encaixa em assistentes de codificação de IA que desenvolvem APIs. Para a referência completa de comandos, consulte o guia completo do Apidog CLI; o guia de instalação do Apidog CLI explica a primeira execução.

Melhor para: executar seus cenários de teste em CI e gerenciar recursos do projeto a partir de scripts, especialmente em um fluxo de desenvolvimento de API "spec-first" onde o contrato impulsiona tudo.

Observação sincera: Apidog não é de código aberto; é um produto comercial com um plano gratuito. Mas esse plano gratuito, juntamente com a CLI, oferece uma alternativa integrada para montar um cliente de requisições, um servidor de mock e um executor de testes por conta própria, tudo apoiado por um único projeto. A parte leve é o binário apidog-cli; a plataforma Apidog completa é uma GUI sobre o mesmo projeto.

Como escolher

A maioria delas são complementares, não concorrentes. Você provavelmente executará várias: um cliente HTTP, jq, um túnel, um observador e um executor de testes.

Escolha pelo trabalho. Envio de requisições: xh ou HTTPie para trabalho interativo, curl para scripts. Leitura de respostas: sempre jq. Exposição de uma porta: ngrok. HTTPS local: mkcert. Reexecução ao salvar: watchexec. Serviços de apoio: Docker. Execução dos seus testes de API e gerenciamento do projeto: apidog-cli.

Concluindo

Um bom kit leve é um punhado de ferramentas pequenas e rápidas que fazem uma única coisa e se encadeiam. curl e xh enviam requisições, jq as lê, ngrok e mkcert lidam com acesso local, watchexec fecha o ciclo de edição-execução, e Docker oferece infraestrutura descartável. Nenhuma delas exige muito antes de ser útil.

apidog-cli é a peça que conecta o ciclo ao seu projeto de API real, para que os endpoints e testes que você executa no terminal sejam os mesmos que sua equipe projeta e entrega. Baixe o Apidog para configurar um projeto e, em seguida, controle-o pela linha de comando com a CLI em seu pipeline de CI. A mesma ideia de velocidade e pegada, aplicada a todo o ciclo de vida da API em vez de uma requisição por vez.