DEV Community

Cover image for Construindo minha primeira CLI com Node.js (consumindo a API do GitHub)
Marcos Filipe
Marcos Filipe

Posted on

Construindo minha primeira CLI com Node.js (consumindo a API do GitHub)

#beginners #cli #github #node

Recentemente, desenvolvi uma CLI simples em Node.js para visualizar a atividade recente de usuários do GitHub direto pelo terminal.

O objetivo foi praticar fundamentos de backend na prática, sem depender de bibliotecas externas, focando em entender cada etapa do processo.

💡 O que a aplicação faz

A ferramenta permite executar:

github-activity <username>
Enter fullscreen mode Exit fullscreen mode

E retorna algo como:

Pushed commits to user/repo
Opened a new issue in user/repo
Starred user/repo
Enter fullscreen mode Exit fullscreen mode

Os dados são obtidos através da API pública do GitHub:

GET /users/:username/events
Enter fullscreen mode Exit fullscreen mode

⚠️ Desafio encontrado: dados incompletos da API

Inicialmente, a ideia era exibir a quantidade exata de commits em cada push:

Pushed 3 commits to user/repo
Enter fullscreen mode Exit fullscreen mode

Porém, durante os testes, observei que a API de eventos do GitHub nem sempre retorna os dados completos.

Em vários PushEvent, o payload vinha assim:

{
  "ref": "refs/heads/main",
  "head": "commit_hash",
  "before": "commit_hash"
}
Enter fullscreen mode Exit fullscreen mode

Sem os campos:

"commits": []
"size": number
Enter fullscreen mode Exit fullscreen mode

Ou seja:

  • Não há lista de commits
  • Não há quantidade (size)
  • Apenas o intervalo (before → head)

🧠 Análise técnica

Isso mostra que a API de eventos:

  • Funciona como um feed resumido de atividades
  • Não garante consistência nos dados
  • Pode omitir informações dependendo do contexto

Uma alternativa mais precisa seria usar:

GET /repos/:owner/:repo/compare/:before...:head
Enter fullscreen mode Exit fullscreen mode

Que retorna o número real de commits. Porém, isso exigiria:

  • múltiplas requisições por evento
  • controle de rate limit
  • maior complexidade

Para este projeto, optei por manter a simplicidade.

✅ Solução adotada

Implementei um fallback:

Pushed commits to user/repo
Enter fullscreen mode Exit fullscreen mode

Quando a quantidade de commits não está disponível.

Isso evita exibir dados incorretos e mantém a saída consistente.

🧠 Aprendizados principais

🔹 Entrada via CLI

Uso de process.argv para capturar argumentos do terminal.

🔹 Consumo de API

Utilização do fetch nativo do Node.js para requisições HTTP.

🔹 Manipulação de JSON

Filtragem e transformação de dados complexos em uma saída legível.

🔹 Tratamento de erros

  • usuário não encontrado
  • falhas de requisição
  • propriedades indefinidas

🔹 Limitações de sistemas externos

Nem sempre o problema está no código — às vezes está na fonte de dados.

⚙️ Decisões de implementação

  • Sem bibliotecas externas
  • Código simples e direto
  • Foco em aprendizado ao invés de abstrações

🚀 Próximos passos

  • Adicionar flags (--limit, --type)
  • Melhorar a formatação da saída
  • Adicionar cores no terminal
  • Publicar como pacote global (npm)

📌 Conclusão

Esse projeto mostrou, na prática, que:

APIs nem sempre entregam dados completos ou consistentes.

E mais importante:

Um bom software não depende de dados perfeitos — ele se adapta a eles.

🔗 Repositório

https://github.com/mffdeo/github-activity-cli

Top comments (0)