DEV Community: Abel Costa

Testes de código: definções e principais aspectos

Abel Costa — Sat, 28 Jan 2023 20:00:00 +0000

Ainda que a abordagem mais conhecida seja a da pirâmide de testes, não necessariamente ela é a mais realista, isso porque na "vida real" do desenvolvimento de software testes se encaixariam muito melhor num espectro do que realmente dentro de uma pirâmide. Uma "pirâmide" reflete fronteiras claras entre o que é exatamente um teste de integração e um teste de unidade, mas essas fronteiras praticamente não existem na vida real. Justamente por isso essa definição do que é um "teste de unidade" e um "teste de integração" quase sempre é uma definição ad hoc feita para cumprir as expectativas de um determinado framework.
No NestJs, por exemplo, um teste de integração é basicamente um teste de fluxo de um endpoint o que também poderiamos definir como um test end to end. As definições do que é um determinado tipo de testes são generalistas e malmente cobrem a realidade.

Na grande maioria dos projetos, nossos testes estarão muito mais próximos do conceito de testes de integração ainda que vejamos eles como unitários. Não é trivial definir uma unidade e muitas vezes elas sequer existem. Variáveis como acoplamento influenciam na forma como os testes são implementados. No geral compreendemos testes unitários como o testes de uma determinada função ou método, ele são mais fáceis de fazer e executam mais rápido.

Testes de integração

Determinam se partes desenvolvidas independentemente funcionam corretamente quando estão conectadas. Muitas pessoas pensam que testes de integração possuem um escopo grande, mas eles podem ser feitos de maneira muito mais efetiva se possuírem um escopo mais reduzido. Antigamente era comum um programador ser responsável por toda a construção de um determinado módulo e essa construção poderia levar meses, todo esse trabalho era feito em isolamento e quando o programador acreditava que o módulo estava pronto ele entregava para o Quality Assurance para que pudesse ser testado.

O ponto sobre testes de integração é testar se módulos que foram desenvolvidos separadamente trabalham juntos como o esperado. Um outro ponto de ver testes de integração é testar se um sistema formado por um conjunto de módulos trabalham como esperado. Mas essas duas coisas podem se fundir facilmente.

Tipos de teste de integração

Temos dois tipos de testes de integração:

narrow: responsável por testar apenas a parte do meu service que se comunica com outra parte externa consistindo em muitos testes de escopo restrito de forma com que se assemelham muito com testes unintários e são marcados pelo uso de doubles
broad: Requerem versões válidas de todos os serviços, requisitando muitos testes de ambiente e acesso a rede, testam um ciclo de vida completo de uma requisição, não apenas código responsável por interações

Para a grande maioria da população dos desenvolvedores testes de integração são necessariamente do tipo broad, o que os deixa um pouco confusos quando se deparam com outra abordagem. Muitos ainda chamam testes broad de testes end to end.

Testes unitários

A pesar de ser muito citado no contexto de desenvolvimento de software o que define um teste unitário ou teste de unidade nunca fica muito claro, o que muitas vezes causa certo tipo de confusão. É muito difícil definir exatamente o que é um teste unitário, porém podemos entender que há alguns padrões que eles seguem.

Testes unitários são:

De baixo nível
Foco numa pequena parte do sistema
Mais rápidos que outros tipos de testes

Porém a pesar de haver essas semelhanças temos diferenças no que as pessoas esperam ser uma “unidade”, designs orientados a objetos tendem a criar uma visão de que uma unidade seria uma classe, enquanto que abordagens procedurais e funcionais fazem parecer que uma função é uma unidade, mas isso não é tão preto no branco quanto parece. O time deve decidir o que é uma unidade com o propósito do entendimento do sistema e de como ele é testado.

A abordagem mais comum que temos é realmente que uma unidade seja uma classe, porém com certa frequência, um conjunto de classes relacionadas também podem ser vistas como uma unidade.

Tipos de testes unitários

Testes unitários podem ser sociáveis ou solitários, imagine uma classe Order que possui o método calculateTotalPrice() e esse método por sua vez precisa invocar métodos nas classes Customer e Product. Para termos testes unitários solitários eu não posso usar a implementação real dessas classes nos meus testes, assim sendo tenho de criar test doubles para que possa fazer o teste solitário do método calculateTotalPrice().

Um teste unitário solitário faz uso de teste doubles, como mocks, stubs, spies e etc…

Mas nem sempre encontramos testes unitários solitários, muitas vezes encontramos testes unitários sociáveis, isto é, um teste unitário que interage com outras classes, que do ponto de vista de alguns seria uma “unidade”.

F.I.R.S.T

É um acrônimo para definir qual a realidade dos testes dentro da aplicação, ele responde a pergunta "o que um teste deve ser?"

Fast: testes devem rodar rápido, para encorajar que eles possam rodar mais de uma vez.
Independent: os testes não devem depender uns dos outros para que possam executar
Repeatable: o resultado deve ser o mesmo independente da quantidade ou da qualidade da execução dos testes
Self-validating: o próprio teste deve possuir uma saída bem definida que é válida ou não, fazendo com que ele passe ou falhe.
Through: um teste deve “atravessar” o caso que testa, testando cenários felizes e de falha, segurança e outros problemas.

Podemos ter mais de uma verificação por teste?

Muito se prega que "devemos ter apenas uma asserção por teste", teoria defendida principalmente no livro Clean Code, mas essa definição não tem muita validade em testes na vida real.

Podemos sim ter mais de uma verificação por testes desde que as asserções verifiquem um mesmo cenário, por exemplo ao cadastrar um novo cliente posso buscar pelo número de telefone e email para verificar se a criação aconteceu devidamente.

Tips and tricks

Lista de cenários: Tenha uma lista de cenários iniciais antes de conceber os seus testes, saiba ao menos 2 ou 3 casos de saída com bases em entradas. Isso vai ajudar bastante a desenvolver a aplicação.
Passos pequenos: Ter passos pequenos é uma das principais características do TDD, devemos fazer as coisas aos poucos até chegar ao resultado desejado, não seja ansioso.
Triangulação: Mesmo já possuindo um código de produção que funciona devemos adicionar testes com corpos parecidos, porém que farão o teste de produção falhar, essa técnica é o que chamamos de triângulação.
Código limpo: Lembre-se que códigos são a melhor forma de documentação do seu sistema, assim sendo é muito importante que eles estejam escritos tão bem quanto o seu código de produção (e se possível até melhores).

Fundamentos de TDD

Abel Costa — Sat, 28 Jan 2023 20:00:00 +0000

Testes automatizados são a única forma que temos de garantir que um código realmente funciona. Eles nos permitem adotar um processo de desenvolvimento sustentável que ao longo do tempo não venha se tornar caótico. Teste te dão a coragem de refatorar quando for necessário, na verdade, adicionar uma suite de testes significativas deve ser o primeiro passo de uma refatoração. Muitas vezes o design e a tecnologia escolhidas para o projeto dificultam a introdução de testes automatizados, por isso nem sempre é possível utilizá-los, ainda que esse seja o cenário ideal de desenvolvimento ágil de software.

O que é um teste automatizado?

Um teste automatizado é nada além da execução automatizada de um trecho de código especifico que compara as entradas com a saida (retorno) e verifica se a mesma está de acordo com o que se era esperado.

Dado um conjunto de entradas, quando algo acontecer a saida deve cumprir as expectativas.

Na natureza do TDD temos três fases distintas:

given/arrange: Onde se definem todas as informações necessárias para executar o comportamento que será testado;
when/act: execução do comportamento testado
then/assert: verificação da execução, comparando os retornos com expectativas.

Exemplo

Deve ser feito um pedido com três itens:

Dado um novo pedido com 3 itens associados, um livro de R$ 50, um CD de R$ 20, e um DVD de R$ 30.

Quando o pedido for realizado

Então deve ser retornado uma confirmação do pedido contendo o valor total do mesmo e status aguardando pagamento.

Como funciona um TDD?

TDD não é um método de teste, mas sim uma metodologia de construção de um código fonte em pequenas etapas, onde os testes são escritos antes do código final. Dentro de um determinado ciclo.

As três leis do TDD

Você não pode escrever nenhum código até ter escrito um teste que detecte uma possível falha.
Você não pode escrever mais testes do que o suficiente para detectar uma falha
Você não pode escrever mais testes o suficiente para atender os requisitos de sucesso

São basicamente esses três pontos que permitem você entender o TDD:

Escreva código de testes antes do código de produção
Escreva um código de produção para atender os requisitos do teste
Escreva um código de teste que faz o cenário atual de código de produção falhar (triângulação)

Refatorando Ifs Aninhados com Chain of Responsibility

Abel Costa — Sun, 22 Jan 2023 16:00:00 +0000

Funções ideais

Num mundo ideal funções são pequenas, muito bem definidas, possuem uma única responsabilidade e não crescem, mas no mundo real isso não é uma realidade, funções tendem a crescer, mesmo que tenham uma única função de fato.

Imagine uma função de uma aplicação veterinária que deve dizer ao usuário qual comida é adequada para um determinado animal, de forma simples a função seria mais ou menos dessa forma:

function properFoodForAnimal(anAnimal: string): string {
  let food;

  if ("dog" === anAnimal.toLowerCase()) food = "beef meat";

  if ("cat" === anAnimal.toLowerCase()) food = "fish meat";

  if ("owl" === anAnimal.toLowerCase()) food = "rat meat";

  if ("monkey" === anAnimal.toLowerCase()) food = "banana";

  if ("horse" === anAnimal.toLowerCase()) food = "corn";

  return `Animal ${anAnimal} will eat ${food}`;
}

Note que a medida em que a veterinária "expandir o seu mercado" e novos animais forem atendidos essa função tende a crescer ganhando novos ifs.
Para evitar que isso aconteça podemos aplicar o design pattern chain of responsibility.

Chain of Responsibility

É um padrão de projeto comportamental muito utilizado quando temos uma cadeia (chain) de situações que lidam com o mesmo escopo como a escolha de uma comida, calculo de um preço, filtragem de campos dentre outras.
Esse padrão permite que vários objetos manipulem a solicitação sem que haja acoplamento entre o trecho de código que envia a requisição e seus receptores. Podemos facilmente identificar esse padrão no nosso código através da interface a qual a solução é implementada.

interface Handler {
    setNext(handler: Handler): Handler;

    handle(request: string): string;
}

Procedimento

Sempre que vamos começar a refatorar um trecho de código temos de nos certificar que aquele trecho possui uma suite de testes robusta que vai nos assegurar de não causar nenhum bug, então a primeira coisa que vamos fazer é justamente escrever os testes para a função.

describe("Proper food for animal", () => {
  it("should return the correct phrase containing the proper for a dog", () => {
    let phrase = properFoodForAnimal("dog");

    expect(phrase).toBe("Animal dog will eat beef meat");
  });

  it("should return the correct phrase containing the proper for a cat", () => {
    let phrase = properFoodForAnimal("cat");

    expect(phrase).toBe("Animal cat will eat fish meat");
  });

  it("should return the correct phrase containing the proper for a owl", () => {
    let phrase = properFoodForAnimal("owl");

    expect(phrase).toBe("Animal owl will eat rat meat");
  });

  it("should return the correct phrase containing the proper for a monkey", () => {
    let phrase = properFoodForAnimal("monkey");

    expect(phrase).toBe("Animal monkey will eat banana");
  });

  it("should return the correct phrase containing the proper for a horse", () => {
    let phrase = properFoodForAnimal("horse");

    expect(phrase).toBe("Animal horse will eat corn");
  });
});

Escritos os testes iniciamos a refatoração, primeiramente criando a interface AnimalFoodHandler que é nada além da interface genérica do pattern apresentada anteriormente.

interface ProperFoodHandler {
  setNext(handler: ProperFoodHandler): ProperFoodHandler;

  handle(anAnimal: string): string;
}

Pode parecer desnecessário a primeira vista nomear essa interface de forma tão específica uma vez que a proposta é que ela seja genérica, mas isso impede outros programadores de aplicar handlers não adequados para aquela situação já que o intellisense do ts avisará que os objetos não são do mesmo tipo.
O próximo passo então é criarmos as classes handlers para cada animal que temos no código hoje, como todo handler possui a mesma estrutura e lida com o mesmo domínio podemos fazer o uso de herança e polimorfismo para deixar o nosso código ainda mais claro. Vamos criar uma classe abstrata de handler da qual se derivarão as classes filhas.

export class AbstractFoodHandler implements IFoodHandler {
  private nextHandler: IFoodHandler | undefined;

  next(handler: IFoodHandler): IFoodHandler {
    this.nextHandler = handler;

    return handler;
  }

  handle(anAnimal: string): string | null {
    if (this.nextHandler) {
      return this.nextHandler.handle(anAnimal);
    }

    return null;
  }
}

Agora podemos ter handlers concretos derivado da classe abstrata de forma com que haja um handler para cada situação, assim sendo temos

DogFoodHandler.ts

export class DogFoodHandler extends AbstractFoodHandler {
  handle(anAnimal: string): string | null {
    if ("dog" === anAnimal.toLowerCase())
      return `Animal dog will eat beef meat`;

    return super.handle(anAnimal);
  }
}

CatFoodHandler.ts

export class CatFoodHandler extends AbstractFoodHandler {
  handle(anAnimal: string): string | null {
    if ("cat" === anAnimal.toLowerCase())
      return `Animal cat will eat fish meat`;

    return super.handle(anAnimal);
  }
}

OwlFoodHandler.ts

export class OwlFoodHandler extends AbstractFoodHandler {
  handle(anAnimal: string): string | null {
    if ("owl" === anAnimal) return `Animal owl will eat rat meat`;

    return super.handle(anAnimal);
  }
}

MonkeyFoodHandler.ts

export class MonkeyFoodHandler extends AbstractFoodHandler {
  handle(anAnimal: string): string | null {
    if ("monkey" === anAnimal.toLowerCase())
      return `Animal monkey will eat banana`;

    return super.handle(anAnimal);
  }
}

HorseFoodHandler.ts

export class HorseFoodHandler extends AbstractFoodHandler {
  handle(anAnimal: string): string | null {
    if ("horse" === anAnimal.toLowerCase()) return `Animal horse will eat corn`;

    return super.handle(anAnimal);
  }
}

Ainda podemos criar um arquivo index.ts para facilitar a exportação de arquivos.

import { CatFoodHandler } from "./CatFoodHandler";
import { DogFoodHandler } from "./DogFoodHandler";
import { MonkeyFoodHandler } from "./MonkeyFoodHandler";
import { OwlFoodHandler } from "./OwlFoodHandler";
import { HorseFoodHandler } from "./HorseFoodHandler";

const catHandler = new CatFoodHandler();
const monkeyHandler = new MonkeyFoodHandler();
const owlHandler = new OwlFoodHandler();
const horseHandler = new HorseFoodHandler();

const handler = new DogFoodHandler();

handler
  .next(catHandler)
  .next(owlHandler)
  .next(monkeyHandler)
  .next(horseHandler);

export { handler };

O código final da nosssa aplicação ficará assim:

export function properFoodForAnimal(anAnimal: string): string | null {
  return handler.handle(anAnimal);
}

Assim, se quisermos adicionar uma nova condição dentro desse fluxo de código basta criarmos uma nova classe concreta de Handler, inicializá-la e colocá-la na cadeia dentro do arquivo index.ts.

Código fonte

Padronização de commits em projetos Typescript

Abel Costa — Mon, 08 Aug 2022 03:54:00 +0000

Porque escrever uma boa mensagem de commit?

Mensagens de commit servem para comunicar o motivo da adição, remoção ou alteração de um determinado trecho de código. Boas mensagens de commit são uma ótima documentação para um projeto, elas podem servir como um histórico de como o código foi construído e evoluiu ao longo do tempo, ter isso em mãos pode ser muito útil em algumas situações onde estamos tentando entender decisões arquiteturais ou como alguma funcionalidade foi implementada.

Mas como escrever boas mensagens de commit?

A melhor forma de escrever uma mensagem de commit é seguindo um determinado padrão, um dos padrões mais conhecidos é o conventional-commits, uma especificação focada em versionamento semântico que tem o intuito de propor mensagens de commit mais informativas o possível.

Padronizando commits em um projeto Typescript

Para usarmos padronização de commits em nossos projetos temos de fazer uso de uma funcionalidade do git que permite executar um determinado script quando algumas ações ocorrem, chamamos essa função de hooks, os tipos mais comuns de hooks são:

pre-commit: é o primeiro hook a ser executado, ou seja, ele é executado antes mesmo da escrita da mensagem de commit, com ele podemos analisar o que está para ser "commitado", ou seja, podemos analisar todo o código que foi adicionado com o comando git add. É o hook ideal para rodar linters como o eslint, por exemplo.
prepare-commit-msg: é um hook que é disparado antes do editor de mensagens de commit ser executado, aqui podemos definir o padrão da nossa mensagem de commit.
commit-msg: é um hook que recebe um parâmetro que é o caminho do arquivo com a mensagem de commit escrita pelo usuário, um script é executado usando esse arquivo como referência, como ele podemos validar se a mensagem foi escrita corretamente.
post-commit: hook executado quando todo o processo de commit foi concluído, geralmente é usado para notificação ou algo similar.
pre-push: vai ser executado durante o git push, depois das validações de referências remotas (se o repositório realmente existe, por exemplo), mas antes de qualquer objeto ser transferido, muitas vezes utilizado para executar testes unitários do projeto.

Instalando e configurando ferramentas

As ferramentas utilizadas serão:

husky: permite criar hooks no git de maneira simplificada
commitlint: permite validar nossas mensagens de commit
lint-staged: executa um script em arquivos que estão na staged area
commitizen: é uma ferramenta de linha de comando que pode ser utilizada para auxiliar na criação das mensagens de commit.

Instalando, configurando e criando primeiro hook

lint-staged

Para instalar o lint-staged temos de executar o comando npm install lint-staged --save-dev que vai salva-lo como dependência de desenvolvimento. O lint-staged precisa saber qual comando será executado e em que código, para isso ele usa um arquivo que deve estar no diretório raiz da aplicação chamado .lintstagedrc.json, como queremos executar o nosso linter em todos os nossos arquivos typescript do projeto temos de colocar a seguinte configuração dentro desse arquivo:

{
  "*.ts": ["npm run lint"]
}

commitlint

Para instalar o commitlint temos de executar o comando npm install @commitlint/{cli,config-conventional} --save-dev e para a sua configuração, assim como o lint-staged, vamos precisar de um arquivo dentro do diretório raiz do projeto, esse arquivo pode ter distintos nomes e extensões:

commitlint.config.js
.commitlintrc.js
.commitlintrc
.commitlintrc.json

E temos de popular esse arquivo com o tipo de convenção que estamos utilizando nas nossas mensagens de commit, para isso podemos executar o seguinte comando: echo "{'extends': ['@commitlint/config-conventional']}" >> .commitlintrc, esse comando cria um arquivo devidamente populado com o padrão utilizado nos nossos commits.

Husky

Para instalar o husky usamos npm install husky --save-dev, após a instalação temos de habilitar a criação de hooks e para isso usamos o comando npx husky install, após executar esse comando será criado um diretório .husky onde ficarão os nossos arquivos de script de hooks. Para termos os hooks disponíveis temos de executar npm pkg set scripts.prepare="husky install", assim teremos dentro de package.json:

// package.json
{
  "scripts": {
    "prepare": "husky install"
  }
}

Criando primeiro hook

O primeiro hook que vamos criar é o de pre-commit, ele vai ter a função de formatar código que está na nossa staged area, para criar o hook executamos o seguinte código:

npx husky add .husky/pre-commit "npx lint-staged"

O comando npx lint-staged vai ser responsável por executar o comando npm run lint, que foi estabelecido dentro do array no arquivo .lintstagedrc.json.

Agora temos um arquivo pre-commit dentro do diretório .husky e o seu conteúdo:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx lint-staged

commitizen

Para instalar o commitizen usamos o seguinte comando: npm install commitizen --save-dev e temos também de inicializar a especificação do conventional-commits e para isso temos de executar: npx commitizen init cz-conventional-changelog --save-dev --save-exact, como o commitizen é a ferramenta de linha de comando que vai ser executada antes de termos uma mensagem de commit temos de adicionar o hook prepare-commit-msg para a sua execução, assim sendo temos:

npx husky add .husky/prepare-commit-msg "exec < /dev/tty && npx cz --hook || true"

Esse comando vai fazer com que o terminal abra uma ferramenta de linha de comando onde é possível escolher o tipo de modificação que está sendo feita e também escrever uma mensagem apropriada para a modificação que está sendo commitada.

Criando hook para a mensagem de commit

Agora que temos os dois hooks anteriores ao commit já criados, temos de criar um hook que vai ser utilizado para a mensagem escrita, aqui vamos validar se realmente a mensagem está como deveria estar. Executando o comando:

npx husky add .husky/commit-msg "npx --no -- commitlint --edit $1".

O objetivo desse hook é analisar o commit escrito, e se ele realmente segue os padrões estabelecidos na convenção escolhida. Se a mensagem não foi escrita adequadamente temos a seguinte saída:

NodeJs EventEmitter

Abel Costa — Mon, 07 Feb 2022 14:09:00 +0000

O uso comum de javascript: browser, nos permite entender que grande parte da interação que o usuário faz com a máquina se dá através de eventos, exemplos de eventos são:

cliques de mouse
apertar um botão no teclado
mover o mouse

Do lado do backend entretanto, podemos ter outros tipos de eventos, o NodeJs nos permite construir um sistema de eventos similiar, usando o módulo nativo events. Esse módulo fornece a classe EventEmitter que pode ser usada para lidar com eventos.

Dentro da família de manipuladores de eventos do NodeJs o EventEmitter é o mais popular, isso porque tudo que acontece no NodeJs acontece a partir de eventos. O EventEmitter é usado para ações contínuas.

Na verdade EventEmitter é uma classe que nos permite implementar o pattern pub/sub no NodeJS. Com um event emitter, nós podemos simplesmente lançar um novo evento de uma parte distinta da aplicação e o listener vai escutar esse evento lançado e performar uma determinada ação para aquele evento.

Criando um EventEmitter

Para lidar com um EventEmitter temos de instanciar a classe que faz parte do módulo events, nativo do NodeJS, a classe vem com vários métodos, os mais usados são:

addListener
once
on
off
removeListener
emit

Manipulando os eventos com o EventEmitter

A melhor forma de manipular nossos eventos com o EventEmitter é criando uma classe que extenda a classe original do EventEmitter que faz parte do módulo do NodeJs. Como podemos ver no código abaixo:

const EventEmitter = require('events');
const { clearInterval } = require('timers');

class Emitter extends EventEmitter {

}

const emitter = new Emitter();

const event = 'usuario:click';

emitter.on(event, function (click) {
  switch (click) {
    case 'barra de rolagem':
      console.log(`está subindo ou descendo a página`);
      break;
    case 'barra lateral':
      console.log(`está rolando a página para o lado`);
      break;
    case 'botao submit':
      console.log(`enviando informações em um formulário`);
      break;
    case 'botao cancel':
      console.log(`cancelando uma ação`);
      break;
    default:
      break;
  }
});

const userEvents = ['barra de rolagem', 'barra lateral', 'botao submit', 'botao cancel'];

setInterval(() => {
  const random = Math.floor(Math.random() * (userEvents.length - 1));
  emitter.emit(event, userEvents[random]);
}, 1000);

Teremos um log diferente para cada um dos eventos que um usuário pode executar.

Sincronia em aplicações Javascript

Abel Costa — Wed, 02 Feb 2022 23:38:29 +0000

No javascript todas as funções que dependem de execução externa são executadas em background. Assim sendo a forma com que seu código é escrito não necessariamente é a forma com que ele é executado, por isso, mesmo que você escreva um código de foram estruturada, ele não vai executar de cima para baixo, da esquerda para a direita.

O que é uma função assíncrona?

O código Javascript escrito é executado dentro de uma única thread, isso significa que esse código só pode fazer uma única coisa de cada vez a maioria do código javascript que escrevemos é executado de cima para baixo, passo a passo de forma completamente síncrona, é esse sincronismo faz com que quando chamarmos duas funções a execução da segunda só é realizada após a execução da primeira.

O código síncrono espera uma ação ser finalizada antes de partir para a próxima ação.

Porém com a popularização do Ajax a ideia de assincronismo foi popularizada, código assíncrono até o começo do século não era, digamos, popular, a grande maioria das aplicações tinha suas regras de negócio completamente no backend. Muitas gambiarras foram feitas para que houvesse a possibilidade de enviar dados para o backend sem que a página atual fosse recarregada, até que em 2005 surgiu o ajax e [quase] todo mundo começou a gostar da ideia de código assíncrono.

Callbacks

Geralmente se deseja realizar uma tarefa quando uma determinada operação assíncrona é concluída. No começo do ajax tínhamos os callbacks, um callback é nada além de uma função que é passada como argumento de uma outra função, essa outra função é chamada de higher-order function e é executada quando alguma operação é concluída ou quando um evento específico ocorre. Par casos mais simples, os callbacks são extremamente efetivos, o problema surge quando temos de fazer diversas operações assíncronas e ai caímos no callback hell, esse anti-pattern é caracterizado por um código em formato de pirâmide, com diversas funções aninhadas umas dentro das outras.

Trabalhando com callbacks

Temos um código que tem como objetivo buscar um usuário por id, depois ele tem de buscar o telefone desse usuário e por último tem de buscar o endereço desse usuário, como podemos ver abaixo:

function getUser(id) {
  setTimeout(function () {
    return {
      id: 1,
      name: "Aladin",
      dateOfBirth: new Date()
    }
  }, 1000)
}

function getUserPhone(id) {
  setTimeout(() => {
    return {
      phone: "322234545",
      ddd: "11"
    }
  }, 2000)
}


function getUserAddress(id) {
  setTimeout(() => {
    return {
      address: "Rua voluntários da Pátria",
      number: 90
    }
  }, 3000)
}

const user = getUser();
const phone = getUserPhone(user.id);

console.log(`usuário ${user}`);
console.log(`phone: ${phone}`);

Ao executar o código acima podemos ver que a variável user é undefined isso ocorre primeiramente porque o console.log é executado antes da função de obter usuário getUser. Como já sabemos tudo aquilo que depende de execução externa é executada em background, e a melhor forma de lidar com ela é com um callback.

Vamos supor agora que temos uma lista de usuários, e que temos de obter um determinado usuário dentro dessa lista, podemos então trabalhar com callbacks. Para trabalhar com callbacks temos de fazer duas funções a primeira responsável por realizar a ação que tem de ser realizada, e a segunda responsável por resolver a primeira, é essa que chamamos de callback. Uma função que recebe um callback também pode receber outros parâmetros que podem, ou não, serem repassados ao callback.

Veja o código abaixo, usado para obter um usuário de uma lista:

let users = [
  {
    id: 1,
    name: "Aladin",
    dateOfBirth: new Date()
  },
  {
    id: 2,
    name: "John",
    dateOfBirth: new Date()
  },
  {
    id: 3,
    name: "Maycon",
    dateOfBirth: new Date()
  },
  {
    id: 4,
    name: "Andreas",
    dateOfBirth: new Date()
  },

  {
    id: 5,
    name: "Nicole",
    dateOfBirth: new Date()
  },
];

function getUser(id, cb) {
  setTimeout(() => {
    cb(null, users.filter(user => user.id === id))
  }, 2000)
}

// esse é o callback
function resolveUser (error, user) {
  if (error)
    throw new Error('Failed to get user')

  console.log(user);
}

getUser(3, resolveUser)

A função de callback deve seguir um padrão, este é: o primeiro parâmetro da mesma sempre deve ser um erro, o segundo deve ser o valor a ser resolvido. E a função que deve receber um callback sempre deve o receber por último, quaisquer outros parâmetros devem o anteceder.

Agora vamos supor que temos uma base de dados para trabalhar, onde temos as entidades de usuário, telefone e endereço, e temos de obter todas as informações de um determinado usuário especificado pelo id, teremos um fluxo parecido com este:

let users = [
  {
    id: 1,
    name: "Aladin",
    dateOfBirth: new Date(),
  },
  {
    id: 2,
    name: "John",
    dateOfBirth: new Date(),
  },
  {
    id: 3,
    name: "Maycon",
    dateOfBirth: new Date(),
  },
  {
    id: 4,
    name: "Andreas",
    dateOfBirth: new Date(),
  },

  {
    id: 5,
    name: "Nicole",
    dateOfBirth: new Date(),
  },
];

let addresses = [
  {
    id: 1,
    address: "Rua Voluntários da Pátria, 92",
    userId: 1
  },
  {
    id: 2,
    address: "Rua Azul, 92",
    userId: 2
  },
  {
    id: 3,
    address: "Rua A, 92",
    userId: 3
  },
  {
    id: 4,
    address: "Rua B, 76",
    userId: 4
  },
  {
    id: 5,
    address: "Rua Maracaiba, 32",
    userId: 5
  }
]

let phones = [
  {
    id: 1,
    phone: '32903290',
    userId: 1
  },
  {
    id: 2,
    phone: '90097878',
    userId: 2
  },
  {
    id: 3,
    phone: '21902190',
    userId: 3
  },
  {
    id: 4,
    phone: '77777777',
    userId: 4
  },
  {
    id: 5,
    phone:  '10101010',
    userId: 5
  }
]

function getUser(id, cb) {
  setTimeout(() => {
    cb(null, users.find(user => user.id === id))
  }, 2000)
}

function getPhone(userId, cb) {
  setTimeout(() => {
    cb(null, phones.find(phone => phone.userId === userId))
  }, 2000)
}

function getAddress(userId, cb) {
  setTimeout(() => {
    cb(null, addresses.find(add => add.userId === userId))
  }, 2000)
}

// callback
function resolveUserPhone(error, phone) {
  if (error)
    throw new Error("Failed to get phone number")

  console.log(phone);
}

// outro callback
function resolveUserAddress(error, address) {
  if (error)
    throw new Error("Failed to get address")

  console.log(address);

  getPhone(address.userId, resolveUserPhone)
}

// outro callback
function resolveUser (error, user) {
  if (error)
    throw new Error('Failed to get user')

  console.log(user);

  getAddress(user.id, resolveUserAddress)
}

getUser(3, resolveUser)

Note que no código acima nos resolvemos o problema de sincronização que tínhamos, porém agora temos o problema de aninhamento de código, o nosso código está acoplado. Se a lógica foir mais complexa (se por exemplo adicionarmos mais elementos a serem buscados) lidar com o código será muito difícil.

Promises

A ideia das promises é justamente de representar esses fluxos assíncronos de execução de forma sequencial, resolvendo o problema do callback hell, além disso usar promises favorece bastante o tratamento de exceções.

Promises são como cheques, um cheque é uma forma de um pagador te garantir que vai te pagar um determinado valor no dia estipulado. As promises, representam um valor, que vai ser retornado, em algum momento. Quando a função concluir o processamento necessário para retornar aquilo que foi prometido.

Quando trabalhamos com promises fazemos o uso de dois callbacks para tratar o nosso fluxo:

resolve: executado quando a promise foi “cumprida”, ela vai receber como argumento justamente o resultado que vai ser retornado por uma promise. Quando uma promise é resolvida o primeiro .then da cadeia é chamado.
reject: executado quando há alguma falha, por exemplo, quando a conexão com a internet cai, ou quando um endpoint está indisponível, ao executá-la você está sinalizando justamente que a operação falhou e que as outras promises que dependem da mesma não podem ser executadas. Quando a promise é rejeitada, então o método .catch é executado

Estados de uma Promise

As promises permitem trabalhar toda a assincronia do Javascript a partir da ideia de estados, os estados de uma promise são:

pending: estado inicial, significa que a atividade ainda não foi iniciada, ou ainda não foi rejeitada
fulfilled: quando executou todas as operações com sucesso, não podemos manipular o estado de fulfilled, mas podemos passar o valor para ser manipulado por uma função, essa função é o que vai estar dentro de .then
rejected: quando a operação falhou, ela vai ser tratada dentro de .catch

Podemos tratar erros em promises tanto com .catch quanto com o segundo parâmetro de .then, usamos o primeiro para tratar erros genéricos e o segundo para tratar erros mais específicos da ação que está sendo realizada.

Refatorando de callbacks para Promises

Para refatorar para Promises temos de mudar um pouco a forma como os nossos métodos foram escritos, mantendo a mesma lógica de buscar um usuário por id.

let users = [
  {
    id: 1,
    name: "Aladin",
    dateOfBirth: new Date(),
  },
  {
    id: 2,
    name: "John",
    dateOfBirth: new Date(),
  },
  {
    id: 3,
    name: "Maycon",
    dateOfBirth: new Date(),
  },
  {
    id: 4,
    name: "Andreas",
    dateOfBirth: new Date(),
  },

  {
    id: 5,
    name: "Nicole",
    dateOfBirth: new Date(),
  },
];

function getUser(id) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const user = users.find(user => user.id === id);

      if (!user)
        reject(`User not found`)
      else
        resolve(user)
    }, 2000)
  })
}

getUser(3)
  .then(user => console.log(user))
  .catch(err => console.error(err));

Note que o corpo da função anterior foi totalmente movido para dentro da promise, além disso também foi precioso mudar a foram como estávamos buscando pelo usuário dentro da nossa “base de dados”. Mas note como o código fica muito mais legível dessa forma e como podemos tratar melhor os erros que podem vir a ocorrer.

Porém um outro problema ocorre quando temos de lidar com muitos fluxos de dados distintos, se quisermos buscar o endereço e o telefone do usuário, por exemplo. Dentro de um .then é possível passar um dado para que seja usado em um outro .then, assim sendo podemos chamar várias funções que retornam promises de forma encadeada.

let users = [
  {
    id: 1,
    name: "Aladin",
    dateOfBirth: new Date(),
  },
  {
    id: 2,
    name: "John",
    dateOfBirth: new Date(),
  },
  {
    id: 3,
    name: "Maycon",
    dateOfBirth: new Date(),
  },
  {
    id: 4,
    name: "Andreas",
    dateOfBirth: new Date(),
  },

  {
    id: 5,
    name: "Nicole",
    dateOfBirth: new Date(),
  },
];

let addresses = [
  {
    id: 1,
    address: "Rua Voluntários da Pátria, 92",
    userId: 1
  },
  {
    id: 2,
    address: "Rua Azul, 92",
    userId: 2
  },
  {
    id: 3,
    address: "Rua A, 92",
    userId: 3
  },
  {
    id: 4,
    address: "Rua B, 76",
    userId: 4
  },
  {
    id: 5,
    address: "Rua Maracaiba, 32",
    userId: 5
  }
]

let phones = [
  {
    id: 1,
    phone: '32903290',
    userId: 1
  },
  {
    id: 2,
    phone: '90097878',
    userId: 2
  },
  {
    id: 3,
    phone: '21902190',
    userId: 3
  },
  {
    id: 4,
    phone: '77777777',
    userId: 4
  },
  {
    id: 5,
    phone:  '10101010',
    userId: 5
  }
]

function getUser(id) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const user = users.find(user => user.id === id);

      if (!user)
        reject(`User not found`)
      else
        resolve(user)
    }, 2000)
  })
}

function getPhone(userId) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const phone = phones.find(phone => phone.userId === userId)

      if (!phone)
        reject(`Phone not found`)
      else  
        resolve(phone)
    }, 2000)
  })
}

function getAddress(userId) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const address = addresses.find(address => address.userId === userId)

      if (!address)
        reject(`Address not found`)
      else 
        resolve(address)
    }, 3000)
  })
}

getUser(3)
  .then(user => {
    getAddress(user.id)
      .then(address => {
        getPhone(address.userId)
          .then(phone => console.log(user, phone, address))
      })
  })
  .catch(err => console.error(err));

No momento estamos convertendo para promise cada função de callback que temos, mas podemos fazer isso através de um módulo interno do próprio Node, ele nos permite seguir as já estabelecidas convenções de código usando callback, porém em um código que usa promises.

No momento o nosso código com callbacks é escrito da seguinte forma:

let users = [
  {
    id: 1,
    name: "Aladin",
    dateOfBirth: new Date(),
  },
  {
    id: 2,
    name: "John",
    dateOfBirth: new Date(),
  },
  {
    id: 3,
    name: "Maycon",
    dateOfBirth: new Date(),
  },
  {
    id: 4,
    name: "Andreas",
    dateOfBirth: new Date(),
  },

  {
    id: 5,
    name: "Nicole",
    dateOfBirth: new Date(),
  },
];

function getUser(id, callback) {
  setTimeout(() => {
    callback(null, users.find(user => user.id === id))
  }, 3000)
}

function resolveUser(error, user) {
  if (error)
    throw new Error(error)

  console.log(user);
}

getUser(2, resolveUser)

Fazendo o uso da biblioteca util onde temos a possibilidade de usar a função promisify que transforma um método em uma promise, o nosso código fica da seguinte maneira:

const util = require("util"); // import do módulo

let users = [
  {
    id: 1,
    name: "Aladin",
    dateOfBirth: new Date(),
  },
  {
    id: 2,
    name: "John",
    dateOfBirth: new Date(),
  },
  {
    id: 3,
    name: "Maycon",
    dateOfBirth: new Date(),
  },
  {
    id: 4,
    name: "Andreas",
    dateOfBirth: new Date(),
  },

  {
    id: 5,
    name: "Nicole",
    dateOfBirth: new Date(),
  },
];

function getUser(id, callback) {
  setTimeout(() => {
    callback(null, users.find(user => user.id === id))
  }, 3000)
}

const getUserAsync = util.promisify(getUser)

getUserAsync(3)
  .then(user => console.log(user))
  .catch(error => console.log(error))

Async functions

O intuito original das Promises era garantir um código assíncrono que fosse claro e manutenível, as funções async tornaram isso ainda mais presente. Diferentemente da abordagem de migração de callbacks para promises, aqui temos uma forma de escrever o código de maneira mais linear.

Temos no javascript as palavras reservadas async e await, com elas podemos resolver as nossas funções de maneira mais linear, o código dessa forma é quase idêntico ao código de uma função comum, não assíncrona.

O significado

Começando pela palavra async, quando temos uma função marcada com essa palavra significa que temos uma função que sempre retorna uma promise. Porém essa promise já estará resolvida.

async function getOne() {
    return 1
}

console.log(getOne()); // Promise { 1 }

Depois temos a palavra await, sua função é fazer o Javascript esperar até que se tenha uma resposta obtida de um processamento assíncrono.

A utilização delas:

Facilita o trabalho com código assíncrono
Não altera a performance da aplicação desde que seja usado de forma correta
Use apenas quando for necessário tratar a resposta da chamada

A implementação do padrão async/await surgiu primeiramente no typescript, o superset que provém tipagens ao javascript, isso aconteceu porque o typescript é mantido principalmente pela Microsoft, que também mantém o C#, de onde se originou o padrão.

O código de busca por usuário pode ser feito da seguinte forma:

let users = [
  {
    id: 1,
    name: "Aladin",
    dateOfBirth: new Date(),
  },
  {
    id: 2,
    name: "John",
    dateOfBirth: new Date(),
  },
  {
    id: 3,
    name: "Maycon",
    dateOfBirth: new Date(),
  },
  {
    id: 4,
    name: "Andreas",
    dateOfBirth: new Date(),
  },

  {
    id: 5,
    name: "Nicole",
    dateOfBirth: new Date(),
  },
];

let addresses = [
  {
    id: 1,
    address: "Rua Voluntários da Pátria, 92",
    userId: 1
  },
  {
    id: 2,
    address: "Rua Azul, 92",
    userId: 2
  },
  {
    id: 3,
    address: "Rua A, 92",
    userId: 3
  },
  {
    id: 4,
    address: "Rua B, 76",
    userId: 4
  },
  {
    id: 5,
    address: "Rua Maracaiba, 32",
    userId: 5
  }
]

let phones = [
  {
    id: 1,
    phone: '32903290',
    userId: 1
  },
  {
    id: 2,
    phone: '90097878',
    userId: 2
  },
  {
    id: 3,
    phone: '21902190',
    userId: 3
  },
  {
    id: 4,
    phone: '77777777',
    userId: 4
  },
  {
    id: 5,
    phone:  '10101010',
    userId: 5
  }
]

// retorna uma promise
function getUserById(id) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const user = users.find(user => user.id === id);

      if (!user)
        reject("User not found")
      else 
        resolve(user)

    }, 5000);
  });
}

// retorna uma promise
function getAddressByUserId(id) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const address = addresses.find(address => address.userId === id);

      if (!address)
        reject("Address not found")
      else
        resolve(address)

    }, 5000)
  });
} 

// retorna uma promise
function getPhoneByUserId(id) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const phone = phones.find(phone => phone.userId === id);

      if (!phone)
        reject("Phone not found")
      else 
        resolve(phone)

    }, 5000)
  });
}

async function main(id) {
  try {
    const user = await getUserById(id);
    const phone = await getPhoneByUserId(user.id);
    const address = await getAddressByUserId(user.id);

    console.log(`
      Nome: ${user.name},
      Telefone: ${phone.phone},
      Endereço: ${address.address}
    `);
  } catch (error) {
    console.log(error);
  }
}

main(2);

Note que estamos lidando apenas com funções que retornam promises, entretanto ainda temos um problema, o código acima se executado leva muito tempo para terminar. Podemos mensurar o tempo que está sendo utilizando na execução do código usando console.time, como podemos ver abaixo:

async function main(id) {
  try {
    console.time('promises-execution')
    const user = await getUserById(id);
    const phone = await getPhoneByUserId(user.id);
    const address = await getAddressByUserId(user.id);

    console.log(`
      Nome: ${user.name},
      Telefone: ${phone.phone},
      Endereço: ${address.address}
    `);
    console.timeEnd('promises-execution')
  } catch (error) {
    console.log(error);
  }
}

Vamos ter como resposta:

node index.js

      Nome: John,
      Telefone: 90097878,
      Endereço: Rua Azul, 92

promises-execution: 15.032s

Tempo de execução de 15 segundos...

Esse tempo de execução está muito grande pelo fato de que temos de lidar com várias chamadas assíncronas que independem umas das outras, assim sendo, podemos fazer o uso de Promise.all, ele recebe como parâmetro um array de promises e retorna uma única promise que ao ser resolvida retorna um array de resultados das promises colocadas no parâmetro, em ordem. Essa promise vai ser resolvida quando todas as promises dentro do array forem resolvidas. E vai ser rejeitada imediatamente no momento em que uma das promises dentro do array é rejeitada.

Esse método pode ser muito útil quando temos de lidar com várias promises, é tipicamente usado quando existem muitas atividades assíncronas que o código em geral depende de todas para funcionar com sucesso. Isso nos permite reduzir drasticamente o tempo de execução das nossas promises.

async function main(id) {
  try {
    console.time('promises-execution')

    const result = await Promise.all([
      getUserById(id),
      getPhoneByUserId(id),
      getAddressByUserId(id)
    ]);

    console.log(`
      Nome: ${result[0].name},
      Telefone: ${result[1].phone},
      Endereço: ${result[2].address}
    `);

    console.timeEnd('promises-execution')
  } catch (error) {
    console.log(error);
  }
}

Se verificarmos o tempo de execução desse código temos que é de 5 segundos.

Porque esse tempo reduziu tanto? Simples, porque dentro de Promise.all as promises são processadas paralelamente, então antes tínhamos 3 promises de 5 segundos, onde cada uma delas era resolvida de forma sequencial, então o tempo de execução vai ser a soma da execução das três promises individualmente, agora temos apenas 5 segundos de execução porque todas são executadas dentro desses 5 segundos.

Caso as promises dentro do array do parâmetro tenham tempos distintos de execução, o tempo de execução de Promise.all recai sobre o worst case scenario, ou seja, o tempo total de execução vai ser o maior tempo de execução de uma promise individual.

TL;DR

Existem três abordagens distintas de se lidar com código assíncrono em Javascript:

callbacks: convenção mais antiga usada na comunidade, principalmente graças ao ajax, é uma abordagem que pode ser usada para resolver pequenos problemas mas no geral é vista como antiquada por gerar um código muito aninhado (callback hell)
promises: resolve o problema de código aninhado criado com os callbacks, porém ainda temos a dificuldade de um código não linear e que nem sempre é claro de ser lido, além de dificultar o tratamento de erros
async/await: trata o problema das promises de fomra mais linear se comparado as outras duas opções, permite um código mais flat e um melhor tratamento de erros, porém se usado de forma inadequada pode resultar em um impacto negativo da performance da aplicação.

bibliografia:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

https://medium.com/@alcidesqueiroz/javascript-assíncrono-callbacks-promises-e-async-functions-9191b8272298

https://javascript.info/async-await

https://erickwendel.teachable.com/courses/448292/lectures/6939052

https://erickwendel.teachable.com/courses/448292/lectures/6939053

https://erickwendel.teachable.com/courses/448292/lectures/6939055

NodeJs, introdução e conceitos centrais

Abel Costa — Mon, 31 Jan 2022 03:04:21 +0000

Você nunca pode entender tudo, mas você deve se esforçar para entender o sistema - Ryan Dahl, criador do NodeJs

O que é Nodejs?

Para começar vamos colocar que NodeJs, não é:

Uma linguagem
Um framework

NodeJs pode ser definido como um ambiente de execução (runtime) de códigos Javascript server-side. Os principais motivos para a sua adoção se dão pela fácil escalabilidade, baixo custo e flexibilidade o que torna o seu uso adequado para a programação de microsserviços e componentes de uma arquitetura serverless.

Seu criador, Ryan Dahl, estava trabalhando numa feature para um sistema que se assemelhava muito com uma barra de progresso, features como essa têm a característica de consumirem muita memória e processamento, isso porque são feitas muitas operações de comunicação com o banco de dados. Naquele momento a grande maioria das plataformas faziam uso de uma abordagem de I/O baseadas em threads, isso significa que operações que precisam esperar por uma resposta, como a query feita ao banco de dados, ficam "presas" dentro de uma thread que tem o seu estado marcado como waiting. Justamente por isso o consumo de memória e processamento da aplicação subia muito, as threads precisam guardar as informações na memória, e o escalonador de processos responsável por fazer a alternância entre as threads consome um bom tempo de processamento.

O principal diferencial do NodeJs para outras tecnologias como PHP, C# e Java é que ele é Single-Thread. Nas outras tecnologias uma thread é criada para cada requisição feita, então se uma dessas threads faz uma operação muito demorada ela vai ficar travada até o final da execução. O modelo Single-Thread é o modelo padrão, mais comum de se encontrar, mais fácil de programar, porém mais oneroso para os recursos computacionais. Já no modelo NodeJs temos apenas uma thread chamada de Event Loop, a princípio as requisições são colocadas na fila de requisições (ou também fila de eventos) e o event loop vai desempilhar cada uma dessas requisições e tratá-las. A máquina virtual do Javascript então verifica o que tem de ser feito, delega a sua execução e volta para atender as outras requisições, quando a atividade delegada termina então ela volta para o fluxo principal para ser devolvida ao requisitante.

A analogia do restaurante

Quando um novo cliente chega num restaurante um garçom vai prontamente atendê-lo, anota o seu pedido e repassa o mesmo para o cozinheiro que começa a prepará-lo então volta para o salão para atender novos clientes que chegam, anota novos pedidos e repassa-os ao cozinheiro, esse ciclo é repetido diversas vezes, então a medida que os pedidos vão ficando prontos eles são entregues aos clientes pelo mesmo garçom. É mais ou menos assim que o Node funciona, podemos ver o garçom como o event loop e o cozinheiro como a worker pool, os clientes são os usuários de uma determinada aplicação, os pratos são os processos de regras de negócio como por exemplo, acessar o banco de dados.

A arquitetura NodeJs

O NodeJs é composto por componentes e cada um deles possui uma função específica, no coração dele temos o V8, uma engine Javascript usada principalmente dentro do navegador Google Chrome, ela vai ser a responsável por executar o código escrito em Javascript, então temos os NodeJs addons, código escrito em C responsável por comunicar (ligar) o V8 com o sistema operacional. Por último, e não menos importante temos a biblioteca libuv, uma biblioteca escrita em C especialmente para o NodeJs que tem como função abstrair operações não bloqueantes de I/O, isso permite que o CPU e outros recursos sejam usados enquanto ainda estão executando operações de entrada e saída.

As threads dentro do NodeJs

A pesar do NodeJs ser em si Single-Thread ele faz uso de outras threads para a execução das atividades, temos dois tipos básicos de threads dentro do Node, a thread do Event Loop e as Threads do Worker Pool.

Qual código é executado dentro do Event Loop?

Os aplicativos NodeJs passam pela fase de inicialização, onde fazem a solicitação dos módulos e registram os callbacks que devem ser executados quando houver a resposta dos eventos. Dentro do event loop as solicitações feitas pelas requisições são respondidas de forma síncrona. O event loop também é responsável por registrar todas as requisições assíncronas para continuar o processamento após a conclusão. Os retornos das funções assíncronas também são executados dentro do event loop.

Em resumo, o Event Loop executa os callbacks JavaScript registrados para eventos e também é responsável por atender solicitações assíncronas sem bloqueio, como entrada e saída de rede.

Qual código é executado dentro do worker pool?

O worker pool é implementado sobre a libuv, que expõe uma api que permite enviar tarefas, porém as tarefas reservadas ao worker pool são aquelas que são "caras" no sentido de processamento, basicamente toda e qualquer tarefa a qual o sistema operacional não fornece de forma não bloqueante. Exemplo: se um programa está consultando o banco de dados, a CPU fica ociosa até que a consulta seja processada, nesse meio tempo o programa fica parado, causando desperdício de recursos do sistema. Para evitar isso, o libuv é usado no NodeJs, o que facilita operações de I/O sem bloqueio.

Como o node decide que código vai ser executado?

Através de filas, o worker pool tem uma fila que armazenas as tarefas a serem executadas, de forma com que ela pega a primeira tarefa dessa fila, trabalha nela e quando termina lança uma evento "At least one task is finished" para o event loop. Este por outro lado, na verdade, não mantém de fato uma fila, mas sim uma coleção de descritores de arquivos que juntamente com o sistema operacional monitora os eventos. Quando o sistema operacional diz que um determinado descritor de arquivo está pronto, o event loop traduz para o evento apropriado e chama o callback associado com ele.

O significado para o design de aplicações

Em sistemas preemptivos que alocam uma thread por cliente como o apache, sempre que uma das threads fica em estado de bloqueado por muito tempo o sistema vai interromper a mesma e passar a vez para outra thread, outro cliente. Mas o Node é não preemptivo, isso significa que nenhuma thread é interrompida. Isso diminui muito o consumo de memória e processamento, porque diminui a incidência de troca de contexto na aplicação.

Em sistemas preemptivos, onde temos um thread por cliente temos de fazer a troca de contexto com uma certa frequência, assim temos de usar muito mais memória se comparado a um sistema não preemptivo. Na imagem acima temos o apache e o nginx, esse último foi de onde o conceito de event loop foi retirado por Ryan Dahl, note que o Apache, preemptivo, que aloca uma thread por requisição, consome muito mais memória que o nginx que possui processamento paralelo.

O processamento paralelo

A libuv é uma biblioteca cross-platform que permite I/O assíncrono, ela foi desenhada primeiramente para lidar com o Nodejs, mas também é usada em outros ambientes como Julia, Luvit e uvloop. Dentre suas principais responsabilidades temos:

Um event loop que é uportado em qualquer plataforma
Disponibilização de sockets TCP e UDP de forma assíncrona
Disponibilização de eventos do file system
Controle de child processes
Thread pool
Signal handling

Bibliografia:

https://www.youtube.com/watch?v=nfrVPzDJZQc

https://stackoverflow.com/questions/36766696/which-is-correct-node-js-architecture

https://www.geeksforgeeks.org/libuv-in-node-js/

https://nodejs.org/en/docs/guides/dont-block-the-event-loop/