JavaScript no lado do servidor

Você precisa escrever uma API. Ela recebe uma requisição HTTP, consulta um banco PostgreSQL, chama dois serviços externos, agrega as respostas e devolve JSON. Dos 180 milissegundos que dura esse processamento, o processador talvez trabalhe 4 milissegundos. Todo o resto é espera: a rede, o disco, o banco. Um servidor clássico que aloca uma thread por requisição mantém, então, 176 milissegundos de memória de pilha imobilizada sem fazer nada, multiplicados pelo número de requisições simultâneas. Com mil conexões ativas, isso vira um problema de gigabytes e de trocas de contexto.

O Node.js parte da observação inversa: já que o servidor passa o tempo esperando, melhor ter uma única thread de execução que trata os eventos à medida que ficam prontos. Uma requisição que espera o banco não ocupa uma thread, ocupa uma entrada em uma tabela de callbacks, ou seja, algumas centenas de bytes. É esse compromisso, e somente ele, que explica por que o Node lida muito bem com cargas de entrada e saída e por que ele desmorona assim que um cálculo um pouco longo se instala na thread única. Entender esse acordo antes de escrever a primeira linha vai poupar você de metade dos problemas em produção.