Node.js Por Baixo dos Panos #1 - Conhecendo nossas ferramentas
Tags: node, javascript, cpp, advanced
Published: 2019-09-03 17:14:53

> Esta é uma tradução do meu [artigo original](https://dev.to/khaosdoctor/node-js-under-the-hood-1-getting-to-know-our-tools-1465)

Recentemente eu fui convidado para fazer uma palestra em uma das maiores conferências brasileiras, a [The Conf](https://theconf.club). E essa série de artigos foi criada para essa palestra em específico.

{% embed https://www.youtube.com/watch?v=xUO__XJbY0A&list=PLnOICPAPShyRZd7nnbC7h8kCQwM-6K3KW&index=25&t=2s&pp=iAQB %}

O objetivo da conferência é criar conteúdo em inglês, de forma que todas as pessoas do mundo possam se beneficiar deste conteúdo no futuro assistindo as palestras gravadas on-line. E não apenas nós, brasileiros que falamos Português.

Eu estava sentindo que o conteúdo que eu entregava nas minhas outras palestras não estavam tão avançados e profundos quanto eu gostaria que eles fossem. Então eu decidi fazer uma palestra sobre Node.js, JavaScript e como todo o ecossistema do Node.js, de fato, funciona. Isto porque a maioria dos programadores hoje em dia apenas **usa** as coisas, mas ninguém nunca para para pensar como elas funcionam ou o que elas fazem.

No mundo atual isto é até "aceitável", nós temos um monte de libs que removeram a necessidade que tínhamos de ler livros e mais livros sobre arquitetura de processadores só para que pudéssemos criar um relógio escrito em assembly. No entanto, isso nos tornou preguiçosos, usar coisas sem saber nada sobre elas criou uma atmosfera onde todos só sabem o suficiente e só leem o suficiente para criar o que precisam, e esquecem sobre todos os conceitos que vem junto com aquilo. Afinal de contas, copiar e colar código do Stack Overflow é muito mais simples.

Então, com isso em mente, eu decidi dar um mergulho nos internals do Node.js, pelo menos para mostrar como tudo se conecta e como a maioria dos nossos códigos realmente é executado no ecossistema Node.js.

Este é o primeiro de vários artigos sobre este tema em particular, o qual compilei e estudei para poder criar a minha palestra. Eu não vou postar todas as referências bibliográficas neste primeiro artigo, uma vez que são **muitas mesmo**. Ao invés disso, vou dividir todo este conteúdo em vários artigos, cada um deles contendo uma parte do estudo e, no último artigo, vou por as referências e os slides para a minha palestra.

Espero que gostem :D

## Objetivos

O objetivo dessa série é tornar possível e mais tangível o entendimento de como o Node.js funciona internamente, isto é mais por conta de que o Node e o JavaScript são celebridades mundiais por conta de suas **libs**, mas ninguém sabe, de fato, como eles funcionam embaixo do capô. Para explicar tudo isso, vamos cobrir uma série de tópicos:

1. O que é o Node.js
   1. Breve história
   2. Breve história do JS em si
   3. Elementos que são parte do Node.js
2. Um exemplo com uma chamada de leitura de arquivos
3. JavaScript
   1. Como funciona?
      1. Callstack
   2. Alocação de memória
4. Libuv
   1. O que é a libuv?
   2. Para que precisamos dela?
   3. EventLoop
   4. Microtasks e Macrotasks
5. V8
   1. O que é o v8
   2. Overview
      1. Abstract Syntax Tree usando Esprima
   3. Pipeline de compilação antiga
      1. O full codegen
      2. Crankshaft
         1. Hydrogen
         2. Lithium
   4. Nova pipeline de compilação
      1. Ignition
      2. TurboFan
         2. Hidden Classes e alocação de variáveis
   5. Garbage collection
6. Otimizações de compilação
   1. Constant Folding
   2. Análise de indução de variáveis
   3. Rematerialização
   4. Removendo recursão
   5. Deflorestamento
   6. Otimizações Peephole
   7. Expansão inline
   8. Cache Inline
   9. Eliminação de código morto
   10. Reordenação de blocos de código
   11. Jump Threading
   12. Trampolines
   13. Eliminação de sub-expressões comuns

## O que é o Node.js

O Node.js é definido por Ryan Dahl (o criador original) como um "conjunto de bibliotecas que são executadas no mecanismo V8, permitindo executar o código JavaScript no servidor", a Wikipedia define como "um runtime JavaScript open-source, multi-plataforma que executa código fora de um navegador ".

Essencialmente, o Node.js é um runtime que nos permite executar o JS fora do domínio do navegador. No entanto, essa não é a primeira implementação do Javascript no servidor. Em 1995, a Netscape implementou o chamado Netscape Enterprise Server, que permitia aos usuários executar o LiveScript (o jovem JavaScript) no servidor.

### Breve história do Node.js

Node.js foi lançado pela primeira vez em 2009, escrito por Ryan Dahl, que mais tarde foi patrocinado pela Joyent. Toda a origem do runtime começa com as possibilidades limitadas do Apache HTTP Server - o servidor da web mais popular na época - para lidar com muitas conexões simultâneas. Além disso, Dahl criticou a maneira de escrever código, que era sequencial, isso poderia levar a um bloqueio inteiro do processo ou várias pilhas de execução no caso de várias conexões simultâneas.

O Node.js foi apresentado pela primeira vez na JSConf EU, em 8 de novembro de 2009. Combinou o V8, um event-loop fornecido pela - recentemente escrita - libuv e uma API de I/O de baixo nível.

### Breve história do JavaScript

O Javascript é definido como uma "linguagem de script interpretada de alto nível" que está em conformidade com a especificação ECMAScript e é mantida pelo TC39. Criado em 1995 por Brendan Eich enquanto trabalhava em uma linguagem de script para o navegador Netscape. O JavaScript foi criado exclusivamente para atender à idéia de Marc Andreessen de ter uma "linguagem cola" entre HTML e web designers, que deve ser fácil de usar para montar componentes como imagens e plug-ins, de forma que o código fosse escrito diretamente no markup da página da web.

Brendan Eich foi recrutado para implementar a linguagem Scheme no Netscape, mas, devido a uma parceria entre a Sun Microsystems e a Netscape, a fim de incluir o  Java no navegador Netscape, seu foco foi mudado para a criação de uma linguagem com uma sintaxe semelhante à Java. Para defender a idéia do JavaScript contra outras propostas, Eich escreveu, em 10 dias, um protótipo funcional.

A especificação da ECMA veio um ano depois, quando a Netscape enviou a linguagem JavaScript à ECMA International para criar uma especificação padrão, que outros fornecedores de navegadores poderiam implementar com base no trabalho realizado na Netscape. Isso levou ao primeiro padrão ECMA-262 em 1997. O ECMAScript-3 foi lançado em dezembro de 1999 e é a linha de base moderna da linguagem JavaScript. O ECMAScript 4 foi estagnado porque a Microsoft não tinha intenção de cooperar ou implementar o JavaScript de forma correta no IE, apesar de não terem nenhuma ideia para substituir o JS e terem uma implementação parcial, mas divergente, da linguagem .NET no lado do servidor.

Em 2005, as comunidades de código aberto e desenvolvedores começaram a trabalhar para revolucionar o que poderia ser feito com JavaScript. Primeiro, em 2005, Jesse James Garret publicou o rascunho do que seria chamado AJAX, o que resultou no renascimento do uso do JavaScript liderado por bibliotecas de código aberto como jQuery, Prototype e MooTools. Em 2008, depois que toda a comunidade começou a usar o JS novamente, o ECMAScript 5 foi anunciado e lançado em 2009.

### Elementos que compõem o Node.js

O Node.js é composto de algumas dependências:

- V8
- Libuv
- http-parser
- c-ares
- OpenSSL
- zlib

A imagem abaixo tem a explicação perfeita:

![Take from Samer Buna's Pluralsight course: Advanced Node.js](https://github.com/khaosdoctor/my-notes/raw/master/node/assets/nodejs-components.png)

Tendo mostrado isso, podemos dividir o Node.js em duas partes: V8 e a libuv. O V8 é mais ou menos 70% em C++ e 30% em JavaScript, enquanto a libuv é completamente escrita em C.

## Nosso exemplo - Uma chamada de leitura de dados

Para alcançar nosso objetivo (e ter um roteiro claro do que vamos fazer), começaremos escrevendo um programa simples que lê um arquivo e o imprime na tela. Você verá que esse código não será o código ideal que um programador pode escrever, mas cumprirá o propósito de ser um objeto de estudo para todas as partes pelas quais devemos passar.

Se você olhar mais de perto o [fonte do Node.js.](https://github.com/nodejs/node), notará duas pastas principais: `lib` e `src`. A pasta `lib` é a que contém todas as definições de todas as funções e módulos que precisamos em nossos projetos, porém escritas em JavaScript. A pasta `src` é a **implementação em C ++** que vem junto com elas, é aqui que reside a Libuv e o V8 e também onde todas as implementações para módulos como `fs`, `http`, `crypto` e outras acabam ficando.

Seja este programa simples:

```js
const fs = require('fs')
const path = require('path')
const filePath = path.resolve(`../myDir/myFile.md`)

// Parseamos o buffer em string
function callback (data) {
  return data.toString()
}

// Transformamos a função em uma promise
const readFileAsync = (filePath) => {
  return new Promise((resolve, reject) => {
    fs.readFile(filePath, (err, data) => {
      if (err) return reject(err)
      return resolve(callback(data))
    })
  })
}

(() => {
  readFileAsync(filePath)
    .then(console.log)
    .catch(console.error)
})()
```

> Sim, eu sei que existe o `util.promisify` e o `fs.promises`, porém, eu queria converter manualmente o callback da função em uma promise de forma que possamos ter um melhor entendimento da parte interna das coisas.

Todos os exemplos que teremos neste artigo estarão relacionados a este programa. E isso se deve ao fato de que `fs.readFile` **não ** faz parte da V8 ou do JavaScript. Esta função é implementada apenas pelo Node.js, como uma binding C++ para o sistema operacional local, no entanto, a API de alto nível que usamos como `fs.readFile (path, cb)` é totalmente implementada em JavaScript, que chama esses bindings. Aqui está o código fonte completo dessa função `readFile` especificamente  (porque o arquivo inteiro tem 1850 linhas, mas está nas referências):

```js
// https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/lib/fs.js#L46
const binding = internalBinding('fs');
// https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/lib/fs.js#L58
const { FSReqCallback, statValues } = binding;

// https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/lib/fs.js#L283
function readFile(path, options, callback) {
  callback = maybeCallback(callback || options);
  options = getOptions(options, { flag: 'r' });
  if (!ReadFileContext)
    ReadFileContext = require('internal/fs/read_file_context');
  const context = new ReadFileContext(callback, options.encoding);
  context.isUserFd = isFd(path); // File descriptor ownership

  const req = new FSReqCallback();
  req.context = context;
  req.oncomplete = readFileAfterOpen;

  if (context.isUserFd) {
    process.nextTick(function tick() {
      req.oncomplete(null, path);
    });
    return;
  }

  path = getValidatedPath(path);
  binding.open(pathModule.toNamespacedPath(path),
               stringToFlags(options.flag || 'r'),
               0o666,
               req);
}
```

> **Disclaimer:** Estou colando as referências de código nos links de origem do Github a partir do commit `0e03c449e35e4951e9e9c962ff279ec271e62010`, que é o mais recente no momento, desta forma, este documento sempre apontará para a implementação correta no momento em que o escrevi.

Vê a linha 5? Temos uma chamada `require` para `read_file_context`, outro arquivo JS (que também está nas referências). No final do [código fonte](https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/lib/fs.js) para `fs.readFile`, temos uma chamada para `binding.open`, que é uma chamada C++ para abrir um file descriptor, passando o caminho, os sinalizadores `fopen` do C++, as permissões do modo de arquivo no formato octal (`0o` [é o formato octal no ES6](https://2ality.com/2015/04/numbers-math-es6.html)) e, por último, a variável `req`, que é o callback assíncrono que receberá a nossa resposta.

Junto com tudo isso, temos o `internalBinding`, que é um loader para um binding interno privado do C++, que não é acessível aos usuários finais (como nós) porque eles estão disponíveis no `NativeModule.require`, é isso que realmente carrega código C++. E é aqui que [dependemos MUITO do V8](https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/src/node_file.cc#L54-L79).

Então, basicamente, no código acima, estamos dando um `require` em um binding `fs` com `internalBinding('fs')`, que chama e carrega o arquivo [`src/node_file.cc`](https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/src/node_file.cc) (porque todo esse arquivo está no [`namespace fs`](https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/src/node_file.cc#L52)) que contém todas as implementações em C++ para as funções `FSReqCallback` e `statValues`.

A função `FSReqCallback` é o callback assíncrono que passamos quando chamamos `fs.readFile` (quando usamos `fs.readFileSync`, existe outra função chamada `FSReqWrapSync` que é definida [aqui](https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/src/node_file.cc#L681)) e todos os seus métodos e implementações estão definidos [aqui](https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/src/node_file.cc#L449-L475) e expostos como bindings [aqui](https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/src/node_file.cc#L2218-L2228):

```cpp
// https://github.com/nodejs/node/blob/0e03c449e35e4951e9e9c962ff279ec271e62010/src/node_file.cc

FileHandleReadWrap::FileHandleReadWrap(FileHandle* handle, Local<Object> obj)
  : ReqWrap(handle->env(), obj, AsyncWrap::PROVIDER_FSREQCALLBACK),
    file_handle_(handle) {}

void FSReqCallback::Reject(Local<Value> reject) {
  MakeCallback(env()->oncomplete_string(), 1, &reject);
}

void FSReqCallback::ResolveStat(const uv_stat_t* stat) {
  Resolve(FillGlobalStatsArray(env(), use_bigint(), stat));
}

void FSReqCallback::Resolve(Local<Value> value) {
  Local<Value> argv[2] {
    Null(env()->isolate()),
    value
  };
  MakeCallback(env()->oncomplete_string(),
               value->IsUndefined() ? 1 : arraysize(argv),
               argv);
}

void FSReqCallback::SetReturnValue(const FunctionCallbackInfo<Value>& args) {
  args.GetReturnValue().SetUndefined();
}

void NewFSReqCallback(const FunctionCallbackInfo<Value>& args) {
  CHECK(args.IsConstructCall());
  Environment* env = Environment::GetCurrent(args);
  new FSReqCallback(env, args.This(), args[0]->IsTrue());
}

// Create FunctionTemplate for FSReqCallback
Local<FunctionTemplate> fst = env->NewFunctionTemplate(NewFSReqCallback);
fst->InstanceTemplate()->SetInternalFieldCount(1);
fst->Inherit(AsyncWrap::GetConstructorTemplate(env));
Local<String> wrapString =
    FIXED_ONE_BYTE_STRING(isolate, "FSReqCallback");
fst->SetClassName(wrapString);
target
    ->Set(context, wrapString,
          fst->GetFunction(env->context()).ToLocalChecked())
    .Check();
```

Nesta última parte, há uma definição de um construtor: `Local<FunctionTemplate> fst = env->NewFunctionTemplate(NewFSReqCallback)`. Isso basicamente diz que, quando chamamos `new FSReqCallback ()`, a função `NewFSReqCallback` será chamada. Agora veja como a propriedade `context` aparece na parte `target->Set(context, wrapString, fst->GetFunction)` e também como o `oncomplete` também é definido e usado no `::Reject` e `::Resolve`.

Também é importante notar que a variável `req` é criada a partir do resultado da chamada `new ReadFileContext`, que é referenciada como `context` e definida como `req.context`. Isso significa que a variável `req` também é uma representação do binding do C++ de um callback criado com a função `FSReqCallback()` e configura seu contexto para nosso callback e ouve um evento `oncomplete`.

## Conclusão

No momento, não vimos muito. No entanto, em artigos posteriores, iremos abordar cada vez mais como as coisas realmente funcionam e como podemos usar nossa função para entender melhor nossas ferramentas!

Não deixe de acompanhar mais do meu conteúdo no [meu blog](https://blog.lsantos.dev/?utm_source=devto&utm_medium=article&utm_campaign=node_under_the_hood) e se [inscreva na newsletter](https://blog.lsantos.dev/signup?utm_source=devto&utm_medium=article&utm_campaign=node_under_the_hood) para receber notícias semanais!