Pitch: EasyQueue – criei um app desktop pra debugar filas de mensagem sem precisar abrir 5 abas ao mesmo tempo · sousadiego11

Existe um ritual que todo dev back-end conhece.

Você suspeita que uma mensagem está presa na fila. Abre o console da AWS pra ver o SQS. Abre o management UI do RabbitMQ em outra aba. Checa o log da aplicação. Roda um rabbitmqctl list_queues no terminal. Talvez abra um script Python que você escreveu meses atrás pra consumir mensagens manualmente.

Tudo isso pra inspecionar um único payload.

Passei tempo demais nesse ciclo até decidir que precisava fazer alguma coisa a respeito. O resultado é o EasyQueue: um app desktop provider-agnostic pra inspeção, publicação e debug de filas de mensagem — tudo num lugar só.

Hoje suporta RabbitMQ e AWS SQS. Mas o ponto não é "suporta dois brokers". O ponto é que a arquitetura foi desenhada pra receber qualquer broker novo sem tocar na UI. Azure Service Bus e Google Pub/Sub já estão no roadmap, e a razão pela qual isso é viável tem a ver com uma decisão de design que vou explicar mais abaixo.

O que dá pra fazer

Antes de entrar na parte técnica, uma lista rápida do que o app faz hoje:

Conecta em múltiplos brokers simultaneamente
Lista filas da conexão
Inspeciona payloads com um JSON viewer formatado
Publica mensagens com headers customizados
Consome, faz replay, libera, deleta e purga filas
Filtra e ordena mensagens
Dark e Light theme
Credenciais encriptadas no disco local
Cross-platform: Windows, macOS (Intel e Apple Silicon), Linux

Tudo rodando local. Nenhum dado sai da sua máquina.

As decisões técnicas que moldaram o projeto

Por que Electron e não uma web app?

A primeira pergunta que me fiz foi essa. Uma web app com backend local parecia mais leve.

O problema é que "backend local" cria fricção invisível: o usuário precisa ter Node instalado, precisa rodar um servidor, precisa lembrar de iniciar antes de usar. Pra uma ferramenta de debug que você quer abrir rápido, isso mata a experiência.

Electron resolve dois problemas de uma vez: acesso nativo ao sistema de arquivos (essencial pra guardar conexões encriptadas) e distribuição como instalador — o usuário baixa, clica, usa. Sem Docker, sem porta exposta, sem npm install manual.

O custo é bundle size maior. Mas pra uma ferramenta que fica aberta o dia todo, esse trade-off vale.

A decisão que torna o provider-agnostic real

Essa foi a mais importante, e ela não é óbvia de início.

O problema com ferramentas multi-broker é que cada broker tem um modelo de dado completamente diferente. Se você deixar esses detalhes vazarem pra UI, você acaba com código cheio de if broker === 'rabbitmq' e a adição de qualquer novo broker vira uma cirurgia.

A solução foi criar uma camada de abstração no pacote core que todos os providers implementam:

packages/
  core/               → contratos: QueueClient, QueueMessage, Connection
  provider-rabbitmq/  → implementação RabbitMQ
  provider-sqs/       → implementação SQS
  shared/             → utilitários compartilhados

apps/
  desktop/            → Electron + React, fala só com as interfaces do core

A UI nunca importa nada de provider-rabbitmq ou provider-sqs diretamente. Ela chama client.getMessages(), client.publishMessage(), client.releaseMessage() — e não sabe o que acontece por baixo.

Adicionar um novo broker é criar um novo pacote de provider. A UI não muda exceto pela criação de novas conexões, onde conhecer os parametros necessários para criar uma conexão através da UI é obrigatório.

O problema que eu não esperava: normalizar mensagens

Aqui foi onde eu realmente aprendi algo.

RabbitMQ e SQS têm estruturas de mensagem que parecem não ter nada em comum. No RabbitMQ, uma mensagem carrega exchange, routing_key, properties (headers, content-type, delivery_mode, correlation_id...) e o payload em buffer. No SQS, você tem MessageId, Body, MessageAttributes — e um modelo de visibilidade completamente diferente: a mensagem consumida fica invisível por um tempo, não é deletada imediatamente.

Isso não é só uma diferença de nomenclatura. É um modelo de entrega diferente. E essa diferença aparece em operações concretas: o que o RabbitMQ chama de "release" (devolver uma mensagem pra fila) é um nack com requeue: true. No SQS, é setar o VisibilityTimeout pra zero.

A solução foi criar uma QueueMessage no core que normaliza tudo: id, payload sempre como JSON stringificado, headers, e um campo metadata pra campos broker-específicos que não têm equivalente universal. Cada provider é responsável por mapear a estrutura nativa pra esse formato.

O resultado é que a UI chama client.releaseMessage(msg) e ponto. O provider decide o que "release" significa pra aquele broker. A UI não sabe e não precisa saber.

Parece simples depois que está pronto. Mas descobrir onde traçar essa linha — o que pertence ao contrato comum e o que é detalhe do broker — levou algumas iterações.

Credenciais: o detalhe que não dá pra ignorar

As conexões ficam salvas num arquivo local. Host, porta, credenciais, região, access key — tudo isso. Salvar em JSON puro seria um erro óbvio.

A solução foi encriptar o arquivo com uma chave derivada de um identificador da máquina antes de persistir. Mesmo que alguém tenha acesso ao arquivo, não consegue ler as credenciais diretamente sem acesso à mesma máquina.

Estado atual e roadmap

Versão 1.3.0, lançada essa semana. RabbitMQ e SQS funcionando com todas as operações descritas acima. Build automatizado via GitHub Actions pro Windows, macOS e Linux.

O que vem por aí:

Azure Service Bus
Redis Streams
Google Pub/Sub
Message diff (comparar dois payloads lado a lado)
Re-drive (re-publicar pra uma fila diferente)
Sistema de plugins pra providers externos

Como instalar

Releases no GitHub: https://github.com/sousadiego11/easyqueue/releases

Plataforma	Pacote
Windows	`.exe` / `.msi`
macOS Intel	`.dmg`
macOS Apple Silicon	`.dmg`
Linux	`.AppImage` / `.deb`

Contribuições

O projeto é MIT e PRs são bem-vindos. Se você usa RabbitMQ ou SQS no dia a dia e sentiu falta de algo, abre uma issue. Se quiser implementar suporte a um broker do roadmap, tem um AGENTS.md com as diretrizes arquiteturais pra facilitar.

GitHub: https://github.com/sousadiego11/easyqueue

Construí isso pra resolver um problema real do meu dia a dia. Se o ritual das 5 abas soa familiar, espero que o EasyQueue poupe esse tempo pra você.