Node.js: o que é e quando usar no back-end

Você abre o README de um projeto no GitHub e a primeira linha de instalação pede "Node.js 22 ou superior". Ou o tutorial do n8n manda rodar npm install. Ou o desenvolvedor da agência avisa que a API do site "é em Node".

Muita gente trata o nome como se fosse mais uma linguagem para aprender. Ele é o programa que roda JavaScript fora do navegador, e entender isso resolve metade das dúvidas sobre quando usar e quando evitar.

Node.js é bom quando o servidor passa a maior parte do tempo esperando banco de dados e rede, e ruim quando passa a maior parte do tempo calculando. Quase toda decisão sobre adotar ou não adotar sai dessa distinção.

O que é Node.js, e por que ele não é linguagem

A própria documentação oficial define o projeto como um ambiente de execução JavaScript de código aberto e multiplataforma, que roda o motor V8 (o mesmo do Google Chrome) fora do navegador. O termo técnico para isso é runtime.

A linguagem é o JavaScript. Ela nasceu para rodar dentro da página, com acesso ao que o navegador permite, como botões e formulários. O runtime pega o mesmo motor e o coloca no sistema operacional, com acesso ao que um servidor precisa: arquivos, portas de rede, variáveis de ambiente e processos.

O Node.js também não é framework. Express, Fastify e NestJS são frameworks que rodam em cima dele e organizam rotas, middlewares e validação. O runtime entrega só o básico, como o módulo http, com o qual um servidor de "Hello World" cabe em poucas linhas.

Essa separação explica uma confusão comum em vaga de emprego. Quem pede "desenvolvedor Node" quer alguém que escreve JavaScript ou TypeScript para servidor e conhece as bibliotecas do npm. A sintaxe é a mesma que roda no navegador.

Como o event loop atende muita gente com uma thread só

A página About do Node.js descreve o projeto como um runtime JavaScript assíncrono e orientado a eventos, feito para construir aplicações de rede escaláveis. O mecanismo por trás disso é o event loop.

Num servidor tradicional baseado em threads, cada conexão ganha uma thread do sistema operacional. Enquanto a consulta ao banco não volta, aquela thread fica parada esperando. Com muitas conexões, o servidor mantém muitas threads, e cada uma consome memória.

O modelo do Node funciona de outro jeito. A requisição chega e a thread principal do JavaScript dispara a consulta ao banco. Em vez de esperar, ela segue para o próximo cliente. Quando o banco responde, o resultado entra numa fila, e o event loop executa o callback que monta a resposta. É o fluxo do diagrama acima.

O guia oficial Don't Block the Event Loop resume a ideia numa frase: o segredo da escalabilidade é usar um número pequeno de threads para atender muitos clientes. O trabalho que o sistema operacional não sabe fazer de forma assíncrona vai para um Worker Pool implementado na biblioteca libuv.

A mesma página traz a regra que define o limite do modelo: o servidor é rápido quando o trabalho de cada cliente, a cada momento, é pequeno. Cada callback precisa terminar rápido. Se um deles demora, todos os outros clientes esperam na fila.

O npm e o calendário de versões

Junto com o runtime vem o npm, o gerenciador de pacotes. Segundo a documentação do npm, ele tem três partes: o site, a linha de comando e o registro, descrito como o maior registro de software do mundo. É do npm que saem os pacotes que aparecem no package.json de qualquer projeto JavaScript.

Esse arquivo é um JSON que lista nome, versão, scripts e dependências. Ler o package.json é o atalho mais rápido para entender um projeto desconhecido, assunto do guia sobre como entender um repositório do GitHub.

As versões seguem um calendário público. Cada versão maior passa seis meses como Current, para que autores de bibliotecas tenham tempo de se adaptar. Até a v26, as versões pares viram LTS (suporte de longo prazo) e as ímpares perdem suporte depois desses seis meses. Uma LTS recebe, em geral, correção de bugs críticos por 30 meses no total. A partir da v27, o projeto anunciou um ciclo anual em que toda versão maior vira LTS.

O repositório de releases mostra a situação em outubro de 2026:

• v22 (Jod): em manutenção desde 21 de outubro de 2025, fim de vida em 30 de abril de 2027
• v24 (Krypton): Active LTS até 20 de outubro de 2026, depois manutenção até 30 de abril de 2028
• v26: Current desde maio, entra em Active LTS em 28 de outubro de 2026

A recomendação oficial é rodar produção só em Active LTS ou Maintenance LTS. Para projeto novo neste mês, a v24 é a escolha segura, e a v26 passa a ser opção assim que virar LTS.

Onde ele funciona bem e onde sofre

O padrão de uso acompanha a tese. O Node.js vai bem onde o servidor espera mais do que calcula:

• API que consulta banco e chama outros serviços. O tempo de cada requisição é quase todo espera de rede.
• Tempo real. Chat, painel ao vivo e notificação mantêm muitas conexões abertas que trocam pouca coisa.
• Ferramentas de build. Empacotadores, compiladores de TypeScript e geradores de site estático rodam nele na máquina do desenvolvedor.
• Automação. O n8n é um exemplo: a documentação de instalação via npm exige uma versão entre a 20.19 e a 24.x.

O problema aparece quando a requisição precisa calcular. A documentação oficial lista exemplos de operações que travam o event loop: versões síncronas de criptografia, como crypto.pbkdf2Sync, compressão síncrona com zlib, JSON.parse de objetos muito grandes e expressões regulares vulneráveis a backtracking. Num exemplo da própria página, fazer o parse de uma string de 50 MB leva 1,3 segundo. Durante esse tempo, o servidor não atende nenhum outro cliente.

Há saídas. O módulo cluster e o child_process.fork() distribuem processos entre os núcleos, e worker threads tiram o cálculo da thread principal. Elas funcionam, mas acrescentam código e operação que o Go, por exemplo, resolve com goroutines.

Node.js, Python, PHP ou Go no back-end

A comparação abaixo resume as diferenças que costumam pesar na escolha. É uma visão geral, e cada linguagem tem frameworks que mudam parte do quadro.

A vantagem que mais pesa a favor do Node costuma ser usar a mesma linguagem no front-end e no back-end. Para equipe pequena, isso reduz troca de contexto e permite compartilhar validação e tipos entre as duas pontas.

Deno e Bun: as alternativas que rodam o mesmo JavaScript

Deno e Bun são runtimes concorrentes. Os dois executam JavaScript e TypeScript e aceitam pacotes do npm.

O Deno se descreve como um runtime de JavaScript, TypeScript e WebAssembly com padrões seguros (secure defaults, nas palavras do projeto). A documentação dele afirma compatibilidade com projetos Node existentes e permite misturar imports npm: com módulos nativos.

O Bun se apresenta como um kit completo e substituto direto do Node. Ele usa o motor JavaScriptCore em vez do V8, e já traz gerenciador de pacotes, bundler e test runner no mesmo binário.

Para projeto pessoal ou ferramenta interna, testar um dos dois custa pouco. Em sistema de produção com dependências antigas, o Node.js continua sendo a referência de compatibilidade, porque é contra ele que as bibliotecas são testadas.

Como começar sem se perder

Se a ideia é rodar um projeto de terceiro ou começar o seu, esta ordem evita os erros mais comuns:

1. Instale por um gerenciador de versões. Ferramentas como nvm ou fnm permitem ter a v22 e a v24 lado a lado e trocar por projeto, o que evita conflito quando cada repositório pede uma versão.
2. Confira a versão pedida. O campo engines do package.json ou um arquivo .nvmrc dizem qual versão o projeto espera.
3. Use npm ci em vez de npm install em servidor. Ele instala exatamente o que está no package-lock.json, sem atualizar dependência por conta própria.
4. Rode em contêiner quando for para produção. Uma imagem com a versão fixa elimina a diferença entre a máquina do desenvolvedor e o servidor, tema do guia sobre Docker.
5. Meça antes de culpar o runtime. Se o servidor ficou lento, verifique se algum trecho faz cálculo síncrono na requisição. Um gargalo comum é uma operação síncrona que deveria ir para um worker.
6. Planeje a troca de versão. Anote no calendário a data de fim de vida da versão que você usa. Rodar versão sem suporte significa ficar sem correção de segurança.

O Node.js tem uma regra simples de aplicar: se o seu servidor passa o dia esperando banco e API, ele atende bem e barato. Se passa o dia calculando, outra ferramenta vai dar menos trabalho. E quem instalar hoje a v24 tem correções garantidas pelo calendário oficial até 30 de abril de 2028.