/blog

Todo dev tem aquele projeto que cresce junto com ele. O meu é o NetView, um sistema de monitoramento de rede que nasceu no início de 2023 pra resolver uma dor bem prática onde eu trabalho, e hoje virou um projeto completo com dashboard em tempo real, CLI, integração com WhatsApp e uma arquitetura modular em Node.js.

Esse texto é um relato técnico (e pessoal) dessa jornada: de um script PHP direto ao ponto até uma aplicação extensível e em produção real. O que aprendi no caminho, os erros que corrigi e as soluções que construí estão aqui.

💡 Todo o código, de todas as versões, está disponível no GitHub

O começo de tudo: Vigianet

O NetView começou em 2023 com outro nome: VigiaNet. A ideia era simples: ter uma página que mostrasse, de forma visual, o status dos principais equipamentos de rede do hospital: servidores, impressoras, dvr’s, roteadores, etc.

A stack era bem direta:

• index.html com Vue.js
• Um setInterval que fazia requisição com Axios a cada 20 segundos
• Um devices.php que fazia ping nos dispositivos e devolvia um JSON

Mas o detalhe está na lógica. O backend PHP:

• Mantinha uma lista de dispositivos, com nome, IP e se deveria ser monitorado 24h ou só em horário comercial.
• Avaliava a regra de horário antes de tentar o ping.
• Executava ping -n 1 -w 1 (Windows) via exec(), interpretava o retorno e montava um JSON com os status.
• Dispositivos fora de horário eram marcados como tal, sem tentar ping.

O frontend Vue.js fazia polling, processava o JSON e criava cards coloridos (verde, vermelho, cinza). Tinha até animação blink pro status offline.

Limitações? Várias:

• Latência de até 20s entre a queda e o aviso visual.
• Nenhum alerta proativo.
• Tráfego constante, mesmo sem mudanças.

Mas, pra um projeto que nasceu como um quebra galho, era mais do que funcional. E foi minha porta de entrada pra entender monitoramento de rede.

A primeira virada: Node.js + WebSocket

Com o tempo, surgiu a necessidade de alertas automáticos, via WhatsApp, quando um dispositivo caía. Isso motivou a primeira grande reescrita: sai PHP, entra Node.js, WebSocket e alertas proativos.

Nascia o NetView v2.

A arquitetura ainda era monolítica:

• netview_server.js era o único arquivo responsável por:
  • Iniciar servidor WebSocket
  • Ler config/devices.json
  • Executar pings periodicamente
  • Detectar mudanças de status
  • Enviar mensagens via WhatsApp (usando whatsapp-web.js)

O frontend se conectava via WebSocket e recebia atualizações em tempo real, nada mais de polling. O dashboard era dinâmico e imediato. E foi completamente reformulado.

Mas a v2 ainda tinha limitações:

• Tudo centralizado num único arquivo.
• Configurações sensíveis hardcoded.
• Script auxiliar (achagrupo.js) pra descobrir o ID do grupo do WhatsApp.

Funcionava. Mas adicionar um dispositivo significava editar código manualmente.

Arquitetura de verdade: v3

A partir da versão v3, veio a grande virada arquitetural. O código ficou mais limpo, testável, modular e o NetView virou um sistema de verdade.

Organização por responsabilidades

A lógica foi quebrada em módulos:

NetViewServer: orquestrador de tudo

PingService: cuida dos pings com backoff exponencial

DeviceStateManager: gerencia o status e histórico

NotificationManager: decide quando notificar

WhatsAppClient: integra com o WhatsApp

ConfigManager: observa e carrega a config

Essa separação facilita testes, debugging e extensões futuras.

Ping mais inteligente

O ping agora tem:

• Tentativas com backoff exponencial
• Timeout configurável
• Compatibilidade com Windows e Linux
• Análise de perda de pacotes
• Concorrência com Promise.all

CLI Interativo

Criei um CLI interativo com readline e chalk que permite configurar tudo sem abrir o código:

$ node server.js --cli

device-add → adicionar novo dispositivo

wa-groups → listar grupos do WhatsApp

wa-set → selecionar o grupo para notificações

logs → ver as ultimas 20 linhas do arquivo de log

Por que não usar o Zabbix?

Desde que criei o NetView, vez ou outra me perguntam: “Mas o Zabbix já não faz tudo isso?”

Sim, o Zabbix faz muito mais do que o NetView jamais pretendeu fazer. E tá tudo bem! O NetView nunca foi pensado para competir com ferramentas estabelecidas, ele nasceu para resolver uma dor específica de forma rápida e simples.

Característica	Zabbix	NetView
Complexidade	Alta	Baixa
Setup inicial	Horas	Minutos
Interface	Completa, mas densa	Simples e direta
Alertas	Configuráveis, múltiplos canais	WhatsApp integrado, basta conectar
Extensibilidade	Templates, plugins, APIs	No código
Ideal para	Ambientes que precisam de monitoramento robusto, relatórios, SLA	Quem quer algo funcionando rápido, com alertas diretos

O NetView é mais como um “canivete suíço” para quem precisa de algo funcionando hoje, sem treinamento da equipe ou semanas de configuração. É o projeto que você monta numa tarde e deixa rodando.

Se sua infraestrutura é crítica e você tem tempo para fazer direito, use Zabbix. Se você só quer parar de ficar perguntando “a impressora da recepção tá funcionando?”, o NetView resolve.

Mais que um projeto, uma trilha de aprendizado

O NetView é um reflexo da minha trajetória como dev. Começou resolvendo um problema com um script PHP. Depois virou playground com Node.js. Hoje é um sistema estável, modular, fácil de manter, e cheio de lições no meio do caminho.

É por isso que eu gosto tanto dele. Porque ele cresceu comigo.

O que realmente aprendi

Esse projeto me ensinou muita coisa na prática, não só sobre código, mas sobre evolução de software:

✅ Como organizar sistemas em módulos coesos
✅ CLI com readline e UX de terminal
✅ Lógica de retry com backoff exponencial
✅ WebSocket bidirecional
✅ Integração com APIs não convencionais (WhatsApp Web)
✅ Logs com Winston, histórico com JSONL
✅ Hot reload de arquivos de config
✅ Controle de concorrência com Promises

Mas principalmente: que software bom é software que resolve problemas reais. O NetView não é revolucionário. Não vai mudar o mundo. Mas toda vez que chego e vejo os vários cards no dashboard, sei que aquele script PHP simples de 2023 virou algo útil de verdade.

E talvez seja isso que faz a diferença: não a complexidade do código, mas o problema que ele resolve.