Debugging avançado no Node com Chrome DevTools

console.log resolve boa parte dos problemas do dia a dia, e não tem nada de errado em usar ele. Mas tem uma classe de bug que console.log não dá conta direito: aquele erro que só acontece depois de quinze passos específicos, ou aquela lentidão que você sabe que existe mas não sabe de onde vem. Pra esses casos, o Chrome DevTools conectado no Node é uma ferramenta bem mais poderosa do que a maioria usa no dia a dia.

Conectando o DevTools num processo Node

O Node tem suporte nativo ao protocolo de inspeção do Chrome, só precisa da flag --inspect ao rodar:

node --inspect src/server.js

Isso abre uma porta de debug (por padrão 9229) e imprime no terminal um link pra abrir. O caminho mais direto é abrir o Chrome e digitar chrome://inspect na barra de endereço, onde aparece o processo Node rodando, com um link "inspect" que abre o DevTools completo, do mesmo jeito que você já usa pra depurar uma página web, só que conectado no seu backend.

Se você quer que o processo pare logo na primeira linha, esperando você conectar antes de rodar qualquer coisa, use --inspect-brk no lugar:

node --inspect-brk src/server.js

Breakpoint: pausando a execução onde importa

Um breakpoint pausa o código exatamente naquela linha, permitindo inspecionar o valor de cada variável naquele momento exato. Clicar no número da linha, na aba Sources do DevTools, já coloca o breakpoint ali.

O recurso que faz diferença de verdade é o breakpoint condicional: em vez de parar toda vez que aquela linha rodar, ele só pausa quando uma condição específica é verdadeira. Clicando com botão direito no número da linha e escolhendo "Add conditional breakpoint", você escreve algo como:

usuario.id === "123" && item.quantidade > 10

Isso resolve exatamente o tipo de bug que só aparece com um usuário específico ou um valor específico, sem precisar pausar centenas de vezes até o caso certo aparecer, nem poluir o código com um if temporário só pra debugar.

Watch: acompanhando variável em tempo real

Na aba Sources, o painel Watch permite adicionar qualquer expressão pra acompanhar o valor dela conforme o código avança, passo a passo. Não precisa ser só uma variável simples, dá pra colocar uma expressão inteira:

usuario.pedidos.filter(p => p.status === "pendente").length

A cada passo que você avança na execução (usando os controles de step over, step into, step out), o valor dessa expressão atualiza sozinho no painel, sem precisar reescrever console.log toda vez que quer ver um cálculo diferente.

Call stack: entendendo quem chamou o quê

Quando o código pausa num breakpoint, o painel Call Stack mostra a cadeia completa de funções que levou até ali, cada uma podendo ser clicada pra ver o estado das variáveis naquele nível específico. Isso responde uma pergunta que console.log sozinho não responde bem: não só o que está acontecendo agora, mas o caminho exato que o código percorreu pra chegar nesse ponto, função por função.

Profiler: achando gargalo de performance

Pra lentidão, em vez de adivinhar qual trecho está pesado, a aba Performance grava um perfil real da execução. Você clica em gravar, dispara a operação lenta (uma rota específica, uma função pesada), para a gravação, e o DevTools mostra um gráfico de chamas com o tempo gasto em cada função, em ordem, incluindo quanto do tempo total cada uma consumiu.

Isso troca a suposição por dado real: é comum achar que o gargalo está numa consulta ao banco quando na verdade está num processamento de dado em memória logo depois dela, e o profiler mostra exatamente isso, sem depender de instinto.

Memory: achando vazamento

A aba Memory permite tirar um heap snapshot, uma foto de tudo que está ocupando memória naquele momento. Tirando dois snapshots em momentos diferentes (por exemplo, antes e depois de rodar uma operação repetidas vezes) e comparando os dois, dá pra ver o que cresceu entre eles, um jeito direto de identificar vazamento de memória, tipo um array que só cresce e nunca é limpo.

Quando vale trocar o console.log

Não é sobre abandonar console.log, ele continua sendo o caminho mais rápido pra um problema simples e localizado. Vale trocar por DevTools quando o bug depende de estado que muda ao longo de várias etapas, quando você precisa ver o caminho completo de chamadas até um ponto específico, ou quando o problema é de performance e não dá pra saber de olho nu onde está o gargalo. Nesses casos, o tempo investido em configurar o debugger se paga rápido, comparado a espalhar console.log por todo canto e ficar removendo depois.

Fechando

O Chrome DevTools conectado no Node não substitui o console.log do dia a dia, complementa ele pros casos em que um print não é suficiente: bug condicional difícil de reproduzir, rastro de chamadas complexo, gargalo de performance escondido, vazamento de memória. Saber que essa ferramenta existe, e como ligar ela rápido com --inspect, é o tipo de conhecimento que fica parado a maior parte do tempo, até o dia em que resolve um problema que nenhum console.log resolveria sozinho.