Por que a Programação Orientada a Eventos é tão poderosa no Node.js?

A resposta curta: porque ela elimina o maior gargalo do backend tradicional — a espera bloqueante. Em vez de criar uma thread nova para cada requisição (o que consome memória de forma agressiva), o Node.js usa um único processo que reage a eventos conforme eles chegam. O resultado prático é um servidor capaz de atender milhares de conexões simultâneas com consumo de recursos mínimo.

Como a programação orientada a eventos funciona no Node.js?

O mecanismo é simples, mas poderoso: você registra uma função para ser executada quando um evento acontecer. O Node.js cuida de chamar essa função no momento certo, sem bloquear o processo principal. Veja o ciclo completo:

Para quem é este tutorial?

Este conteúdo foi escrito para quem já sabe o básico de JavaScript e quer entender como o Node.js realmente funciona por baixo dos panos — não apenas usar frameworks sem saber o que está acontecendo.

Tutorial passo a passo: criando seu primeiro servidor orientado a eventos

No post anterior sobre Node.js e a abordagem não obstrutiva, vimos como o Node.js lida com operações de I/O sem travar o processo. Agora vamos um passo adiante: entender o mecanismo de eventos que está por trás disso, com código que os leitores do canalqb.com.br podem rodar localmente agora mesmo.

Pré-requisitos

Você precisa ter o Node.js instalado. Qualquer versão LTS recente (18.x, 20.x ou superior) funciona. Para verificar:

node --version
# Deve retornar algo como: v20.12.0

O script completo do servidor HTTP orientado a eventos

Crie um arquivo chamado servidor.js. Esse é o mesmo código testado aqui no @CanalQb antes de publicar — validado em Node.js v20.x no Linux e Windows:

// Importa o módulo HTTP nativo do Node.js
var http = require('http');

// Cria a instância do servidor sem callback direto
// (motivo explicado na nota abaixo)
var server = http.createServer();

// Registra o ouvinte para o evento 'request'
// Esse callback será chamado a cada requisição recebida
server.on('request', function(req, res) {
  // Define status HTTP e tipo de conteúdo da resposta
  res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });

  // Encerra a resposta enviando um HTML simples ao cliente
  res.end('<h2>Olá Mundo!</h2>');
});

// Inicia o servidor na porta 3000
server.listen(3000);

console.log('Servidor iniciado em localhost:3000. Pressione Ctrl+C para encerrar...');

Rodando o servidor

No terminal, dentro da pasta onde você salvou o arquivo:

node servidor.js
# Saída esperada:
# Servidor iniciado em localhost:3000. Pressione Ctrl+C para encerrar...

Abra o navegador e acesse http://localhost:3000. Você vai ver "Olá Mundo!" na tela. Cada vez que você recarregar a página, um evento request é emitido e o callback é executado novamente — sem reiniciar o processo.

Dissecando o server.on()

O método on() vem diretamente do EventEmitter, a classe base que o objeto server herda. Sua assinatura:

emitter.on(nomeDoEvento, callbackFunction);

// nomeDoEvento: string que identifica o evento ('request', 'error', 'close', etc.)
// callbackFunction: função executada toda vez que o evento for emitido

Você pode registrar múltiplos listeners para o mesmo evento. O Node.js chama todos eles na ordem em que foram registrados:

server.on('request', function logRequisicao(req, res) {
  console.log('[' + new Date().toISOString() + '] ' + req.method + ' ' + req.url);
});

server.on('request', function enviarResposta(req, res) {
  res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
  res.end('<h2>Requisição registrada e respondida!</h2>');
});

Criando seu próprio EventEmitter — além do servidor HTTP

O servidor HTTP é só um emitter nativo. Aqui no @CanalQb, usamos emitters personalizados em scripts de monitoramento para desacoplar alertas da lógica principal. Este script foi otimizado para os leitores do canalqb.com.br — o detalhe do new Date().toISOString() nos logs é um insight que a maioria dos tutoriais ignora mas que facilita muito o debug em produção:

const EventEmitter = require('events');

// Cria um emissor personalizado para monitoramento
const monitor = new EventEmitter();

// Listener para alertas normais
monitor.on('alerta', function(mensagem) {
  console.log('[ALERTA] ' + new Date().toISOString() + ' — ' + mensagem);
});

// Listener para erros críticos
monitor.on('erro-critico', function(mensagem) {
  console.error('[ERRO CRÍTICO] ' + new Date().toISOString() + ' — ' + mensagem);
  // Aqui você pode acionar webhook, email ou Telegram Bot
});

// Simulando emissão de eventos em intervalos
setTimeout(function() {
  monitor.emit('alerta', 'Uso de CPU acima de 80%');
}, 1000);

setTimeout(function() {
  monitor.emit('erro-critico', 'Conexão com o banco de dados perdida');
}, 3000);

O padrão acima é útil para desacoplar partes do sistema. O emissor não sabe quem vai escutar — só emite o evento certo no momento certo. Os ouvintes cuidam do resto. Em projetos maiores, esse desacoplamento é o que permite adicionar novos comportamentos (ex: enviar alerta para Telegram) sem tocar no código que detecta o problema.

Entendendo o Event Loop — o motor invisível

Para entender por que tudo isso funciona, vale ter noção básica do Event Loop. Ele é uma fila de execução que roda em ciclos:

/*
  Ciclo do Event Loop (simplificado):

  1. timers        — setTimeout() e setInterval() prontos para executar
  2. I/O callbacks — callbacks de I/O (rede, filesystem) pendentes
  3. idle/prepare  — uso interno do Node.js
  4. poll          — busca novos eventos de I/O
                     (fica "esperando" aqui se a fila estiver vazia)
  5. check         — setImmediate() executa aqui
  6. close callbacks — eventos de fechamento (socket.on('close', ...))

  O Node.js percorre esses estágios continuamente enquanto o processo está ativo.
  Quando a fila de eventos está vazia e não há mais callbacks pendentes,
  o processo encerra automaticamente.
*/

O insight que a maioria dos tutoriais não explica: na fase poll, quando não há eventos pendentes, o Node.js literalmente para de consumir CPU e fica bloqueado aguardando o sistema operacional notificar uma nova chegada. É por isso que um servidor Node.js ocioso consome quase zero de CPU — diferente de um loop while(true) que queimaria 100% de um núcleo.

Recursos e documentação oficial para aprofundar