---
title: Sobre a Node.js®
layout: about
---

# Sobre a Node.js®

Como uma execução de JavaScript assíncrona orientada a eventos, a Node.js foi desenhada para construir aplicações de rede escaláveis. No seguinte exemplo de "hello world", muitas conexões podem ser manipuladas simultaneamente. Em cada conexão, a função de retorno de chamada é disparada, mas se não existir trabalho a ser feito, a Node.js dormirá.

```cjs
const { createServer } = require('node:http');

const hostname = '127.0.0.1';
const port = 3000;

const server = createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});
```

```mjs
import { createServer } from 'node:http';

const hostname = '127.0.0.1';
const port = 3000;

const server = createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});
```

Isto contrasta com o modelo de concorrência mais comum atualmente, em que são utilizadas as linhas de processamento do sistema operativo. A conexão de rede baseada em linhas de processamento é relativamente ineficiente e muito difícil de usar. Além disto, os utilizadores da Node.js estão livres de preocupações com o bloqueio do processo, uma vez que não existem bloqueios. Quase nenhuma função na Node.js executa diretamente E/S, pelo que o processo nunca bloqueia, exceto quando as E/S são executadas usando métodos síncronos da biblioteca padrão da Node.js. Uma vez que nada bloqueia, os sistemas escaláveis são muito razoáveis de desenvolver na Node.js.

Se alguma desta linguagem não for familiar, existe um artigo completo sobre [Bloqueio vs. Não Bloqueio](/learn/asynchronous-work/overview-of-blocking-vs-non-blocking).

---

A Node.js é semelhante em desenho a, e influenciada por, sistemas como a [Máquina de Evento](https://github.com/eventmachine/eventmachine) da Ruby e o [Twisted](https://twisted.org/) da Python. A Node.js leva o modelo de evento um pouco mais longe. Esta apresenta um ciclo de eventos como uma construção de execução e não como uma biblioteca. Noutros sistemas, existe sempre uma chamada bloqueante para começar o ciclo de eventos. Tipicamente, o comportamento é definido através das funções de retorno de chamada no início de um programa, e no final um servidor é iniciado através duma chamada bloqueante como `EventMachine::run()`. Na Node.js, não existe essa chama que começa o ciclo de evento. A Node.js simplesmente entra no ciclo de eventos após executar o programa de entrada. A Node.js sai do ciclo de eventos quando não existir mais funções de retorno de chamada para executar. Este comportamento é semelhante ao interpretador de JavaScript do navegador — o ciclo de eventos é oculto ao utilizador.

O protocolo de transferência de hipertexto é um cidadão de primeira classe na Node.js, desenhado com fluxo contínuo e baixa latência em mente. Isto torna a Node.js adequada para a fundação duma biblioteca ou abstração da Web.

O fato da Node.js ter sido desenhada sem linhas de processamento não significa que não possamos tirar partido de vários núcleos no nosso ambiente. Os processos filhos podem ser gerados com o uso da nossa interface de programação de aplicação [`child_process.fork()`](https://nodejs.org/api/child_process.html), e estão desenhadas para serem fáceis de se comunicar. Construída sobre esta mesma interface está o módulo [`cluster`](https://nodejs.org/api/cluster.html), que permite-nos partilhar tomadas entre processos para permitir o balanceio de carga entre os nossos núcleos.
