DEV Community: Henrique Reis

Síncrono, assíncrono e Async/Await: conectando os pontos

Henrique Reis — Mon, 30 Mar 2026 18:17:44 +0000

Esses dois conceitos são fundamentais para entender como o JavaScript funciona, e mais ainda, como o Node.js lida com tarefas que demoram, como requisições HTTP, acesso a banco de dados ou leitura de arquivos.

No meu último post, que se tratava de como as promises realmente funcionam, citei que o próximo passo seria entender como o async/await se apoiam nesse mecanismos de assíncronicidade para oferecer uma sintaxe mais legível, e hoje vou estar explicando um pouco como isso funciona.

O que é uma operação síncrona?

Síncrono significa que as instruções são executadas umas após a outra, em ordem, bloqueando a execução de outras coisas até que cada etapa atual termine

Uma analogia simples seria uma fila de pessoas sendo atendidas por uma única pessoa no caixa do supermercado. A próxima pessoa só será atendida depois que a anterior terminar.

Exemplo:

console.log("Início");

const result = calcularPeso(); // trava o programa até terminar
console.log(result);

console.log("Fim");

Se calcularPeso() levar 5 segundos, nada mais acontece durante esse tempo, o programa fica "travado". Mas na verdade o Event Loop do Node.js é travado e assim não executa mais nenhuma tarefa mas esse não é o tópico do post.

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

Assíncrono significa que o programa não espera a operação terminar. Ele segue para a próxima instrução, e a operação assíncrona acontece em segundo plano, sendo executada quando possível.

Uma outra pequena simples analogia seria como pedir uma pizza, você faz o pedido (assíncrono) e continua fazendo outras coisas (programa segue) e quando a pizza chega, alguém te avisa (callback/promise).

Exemplo:

console.log("Início");

setTimeOut(() => {
 console.log("Operação assíncrona finalizada")
}, 2000);

console.log("Fim");

Output:

Início
Fim
Operação assíncrona finalizada

Mas porque entender isso é importante no Node.js?

Node.js é single-threaded ou seja, existe apenas uma thread principal executando o código JavaScript (por padrão).

Se você usa funções síncronas, bloqueia tudo (nenhuma requisição é atendida até a atual terminar).

Com operações assíncronas, podemos escalar para milhares de coisas executando sem bloquear o Event Loop.

Recursos assíncronos comuns:

setTimeOut, setInterval
fetch, axios, request
fs.readFile, fs.writeFile
db.query() (uma consulta no banco de dados)
socket.on() (eventos utilizando web socket)
Promise, async e await

Interação de operações async com o Event Loop

O Event loop gerencia essas operações assíncronas

O código assíncrono é enviado para as Web APIs ou Libuv
Ao finalizarem, voltam via Microtask queue (se forem Promises) ou Macrotask queue (se forem callbacks comuns)
A Call Stack vai gerenciando a execução

Conceito do await em funções assíncronas

O await é uma palavra-chave do JavaScript usada dentro de funções assíncronas. Ela serve para esperar a resolução de uma Promise antes de continuar a execução do código, sem bloquear a thread principal do ambiente.

O Node.js apesar de ser single-threaded como dito antes, é concorrente graças à sua arquitetura baseada em eventos

Quando executamos uma operação de I/O, como uma consulta ao banco de dados:

const users = await db.findAll()

O Node.js:

Dispara a operação de I/O
Entrega a tarefa ao libuv, que gerencia um thread pool responsável por lidar com chamadas ao sistema (como consultas, arquivos, sockets e etc)
Enquanto o libuv trabalha, o Event Loop continua livre, processando outras requisições, timer e callbacks
Quando a operação termina, o libuv notifica o Event Loop, que agenda a resolução da Promise na microtask queue
O JavaScript engine retoma a execução da função extamente após o await

Ou seja, quando a operação assíncrona é disparada com o await, o JavaScript entende que devemos "pausar" a execução daquela função para esperar o resultado do que precisamos para prosseguir mas não deixa de executar outras funções por conta disso.

O comportamento do await

async function getUsers() {
  console.log('antes');
  const users = await db.findAll(); // <- pausa lógica
  console.log('depois');
}

O que acontece internamente:

O Node.js executa tudo até chegar no await
O db.findAll() retorna uma Promise pendente
O runtime "pausa logicamente" a função getUsers, guardando seu contexto (variáveis locais, escopo, posição atual)
A função retorna imediatamente uma Promise pendente ao chamador
Enquanto isso, o Node.js continua executando outras tarefas que aparecem no Event Loop
Quando o banco responde, o callback da Promise é enfileirado na Microtask queue
O Event Loop retorna a execução da função logo após o await

Mas o que significa "pausar a função"?

Pausar não seria bloquear a CPU e nem travar a thread principal do Node.

Significa apenas que a execução daquela função em sí é suspensa de forma cooperativa até que a Promise retorne um valor para dar continuidade.

Enquanto isso:

O contexto da função fica salvo
O Event Loop continua processando outras tarefas
A thread principal nunca fica ociosa esperando algo

Explicação envolvendo duas funções

Quando eu estava realmente aprendendo o papel do async/await em funções assíncronas também ficava me perguntando: é fácil visualizar o que acontece com uma função, mas quando várias funções ao mesmo tempo trabalham dessa maneira?

Imagina que existam duas funções em execução simultaneamente:

async function A() {
  const users = await db.findAll();
  console.log('A terminou');
}

function B() {
  console.log('B executando');
}

O fluxo das duas funções seria basicamente esse:

A é chamado => executa até o await e dispara a query para o banco de dados.
A query é enviada da Call Stack para a Libuv, que cuida dessa Promise no background.
O Event Loop roda B enquanto o banco processa a consulta da função A.
Quando a Promise de A resolve, ela é re-enfileirada.
A função A retoma e finaliza com A resolvida.

Apenas a função A "pausou", o Node.js nunca parou de executar outras coisas, e esse exemplo com apenas duas funções pode se extender a milhares de funções simultâneas

Papeis dos componentes explicados

await: Suspende a execução da função até a Promise resolver
Promise: Representa o resultado futuro de uma operação assíncrona
Libuv: Executa operações de I/O fora da thread do Event Loop
Event Loop: Coordena execuções de tasks e microtasks
Microtask queue: Fila que contém Promises resolvidas aguardando execução da Call Stack
Thread principal: Executa JavaScript, nunca bloqueada por await

Conclusão para fixar

O await é, essencialmente, uma forma elegante de “esperar sem travar”. Ele permite que você escreva código assíncrono com aparência de código síncrono, pausando a execução apenas daquela função até que uma Promise seja resolvida — sem bloquear o restante da aplicação.

Na prática, isso significa mais legibilidade e menos complexidade, evitando encadeamentos confusos de .then() ao trabalhar com Promises, e passa a ter um fluxo mais linear e fácil de entender. Ao mesmo tempo, por baixo dos panos, o comportamento continua sendo assíncrono e eficiente.

Em resumo, o await não torna o código síncrono, ele só faz parecer que é, enquanto mantém a vantagem da execução assíncrona.

Promises: estados, filas, encadeamento e relação com Event Loop

Henrique Reis — Mon, 02 Feb 2026 19:55:55 +0000

Uma Promise é um objeto que representa o resultado eventual de uma operação assíncrona, como uma chamada de API, permitindo lidar com resultados e erros de forma mais organizada do que os antigos callbacks. Usando métodos como .then() para sucesso e .catch() para falhas, ele funciona como um "contrato" de que um valor estará disponível agora, daqui a pouco ou nunca.

Estados de uma Promise

Uma Promise pode estar em apenas um dos três estados abaixo:

pending - ainda está em execução
fulfilled - foi concluída com sucesso
rejected - foi concluída com erro

Esses estados são imutáveis: uma vez fulfilled ou rejected, a Promise não voltará para pending

Por que Promises existem?

Para resolver o problema do callback hell e trazer um modelo mais previsível, encadeável e configável para operações assíncronas.

Com Promises conseguimos:

Evitamos pirâmides de callback
Tratamos erros de forma unificada
Encadeamos operações de forma mais clara
Temos integrações perfeitas com async/await

Criando uma Promise:

const promise = new Promise((resolve, reject) => {
    const sucesso = true

    if (sucesso) {
        resolve("Working!")
    } else {
        reject("Something wrong!")
    }
})

A função passada para o construtor recebe dois parâmetros:

resolve(value) => finaliza com sucesso.
reject(value) => finaliza com erro (o reject não espera um erro mas é uma boa prática rejeitar com um objeto Error para facilitar o debugging, stack trace e identificar falhas -- reject(new Error('error))).

Consumindo Promises:

getUser()
    .then(user => getOrder(user.id))
    .then(orders => sendEmail(orders))
    .catch(error => console.log(error))

Cada .then() adiciona uma nova microtask no Event Loop (explicado mais afundo durante o estudo)

Outro exemplo de encadeamento:

Promise.resolve(2)
    .then(num => num * 2)
    .then(num => num + 3)
    .then(num => console.log(num)) // 7

Uso do `.finally()`

Executa sempre, independemente de sucesso ou erro

fetch("/api")
  .then(res => console.log("sucesso"))
  .catch(err => console.error("erro"))
  .finally(() => console.log("sempre executa"));

Relação das Promises com o Event Loop

Como já sabemos (se chegou até aqui e ainda não tiver noção básica de como o Event Loop funciona, recomendo fortemente que volte e entenda um pouco sobre antes de continuar), o Event Loop é o coração da execução assíncrona no JavaScript.

Ele controla a ordem em que o código é executado e coordena todas as operações assíncronas -- inclusive Promises, é essencial entender como elas interagem entre sí.

O JavaScript é single-threaded, o ambiente não

O motor JavaScript roda em uma única thread, porém o ambiente (Node.js ou navegador) possui várias APIs assíncronas (Web APIs e libuv) que operam fora dessa thread e devolvem o resultado via filas gerenciadas pelo Event Loop.

Promises utilizam a microtask queue, que tem prioridade sobre callbacks de setTimeout por exemplo, que ficam na macrotask queue

O ciclo do Event Loop segue esta ordem:

Executa todo o código síncrono
Executa todas as microtasks pendentes
Executa uma macrotask (se não tiver mais microtasks pendentes)
Repete o ciclo

Por isso que Promises são mais rápidas que timeouts:

setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('microtask'))

// microtask
// timeout

Mas quando uma Promise é resolvida, elas são tratadas como callbacks?

Conceitualmente, sim mas uma diferença fundamental

Quando uma Promise é resolvida ou rejeitada, o callback associado a ela não executa imediatamente, ele é agendado na microtask queue, como dito anteriormente.

Promise.resolve(10).then(x => console.log(x));

A execução inicial:

a chamada Promise.resolve(10) é executada na Call Stack
a Promise é criada e já nasce no estado fulfilled
a chamada .then() também é executada na Call Stack

O .then():

não executa o callback
apenas registra um Promise Reaction Record
esse reaction é armazenado internamente pelo motor JS
nada é enfileirado ainda

Quando a Promise é fulfilled ou rejected:

o motor JS percorre os Promise Reaction Records registrados
para cada reaction, cria um Promise Reaction Job
esse job contém o callback registrado no then/catch/finally
o motor JS agenda internamente esse job como uma microtask
a microtask é colocada na microtask queue

Ou seja, o que realmente acontece é que o motor JavaScript percorre a lista de Promise Reaction Records e, para cada um deles, cria um PromiseReactionJob. Esse job é então agendado na microtask queue. É dentro desse reaction job que o callback registrado no then, catch ou finally é efetivamente executado.

Modelo mental do que acontece, para ter uma visualização do fluxo:

.then()
  ↓
cria um Promise Reaction Record (armazena o callback)
  ↓
quando a Promise resolve/reject
  ↓
o motor JS cria um PromiseReactionJob para cada Promise Reaction Record registrado
  ↓
job onde o callback está registrado (then/catch/finally)
  ↓
agenda o job na Microtask Queue
  ↓
executa na Call Stack

O ponto que muda tudo

No caso das Promises, todo o fluxo acontece inteiramente dentro do motor JavaScript. Não há envolvimento de Web APIs, libuv ou eventos externos. O agendamento ocorre por meio do job scheduling interno do próprio engine.

Por isso, no funcionamento do Event Loop, os callbacks enfileirados como microtasks sempre têm prioridade sobre os enfileirados como macrotasks.

Como as Promises são resolvidas internamente pelo motor JavaScript, seus reaction jobs são agendados como microtasks e, por esse motivo, são sempre executados antes de qualquer macrotask.

Conclusão

Ao longo deste estudo, vimos que Promises vão muito além de uma simples alternativa a callbacks. Elas introduzem um modelo interno de execução assíncrona que é tratado diretamente pelo motor JavaScript, sem depender de ambiente externo.

Entender que:
.then(), .catch() e .finally() não executam callbacks imediatamente, mas registram Promise Reaction Records, que posteriormente geram PromiseReactionJobs nos quais são agendados como microtasks, é o ponto que realmente muda a forma como enxergamos o Event Loop.

Justamente esse mecanismo interno que explica por que Promises são previsíveis, se encadeiam de forma segura e sempre têm prioridade sobre macrotasks, como setTimeout, mesmo com delay zero.

Quando conseguimos entender esse fluxo, muitos "comportamentos estranhos" que nos deparamos durante o dia a dia no desenvolvendo em JavaScript ou TypeScript, deixam de ser mágicos e passam a fazer mais sentido. Promises não são mais uma caixa-preta -- elas são apenas jobs bem organizados, executados no momento certo

Se você quiser avançar ainda mais, o próximo passo natural seria entender como podemos realizar tratativas de erros, como os métodos especiais como Promise.all, Promise.allSettled e Promise.race funcionam e também como o async/await se apoia exatamente nesse mesmo mecanismo, apenas oferecendo uma sintaxe mais legível sobre as Promises que já conhecemos.

Stack memory e Heap memory

Henrique Reis — Wed, 15 Oct 2025 22:36:54 +0000

Embora esses dois tipos de memórias se refiram a formas diferentes de alocar e gerenciar dados durante a execução de um programa, entender como funcionam ajuda a prever o desempenho e possíveis comportamentos inesperados do código em desenvolvimento.

O compilador tem acesso direto à stack memory, já que ela é usada para armazenar variáveis locais e dados cujo o tamanho é conhecido em tempo de compilação (significa que o compilador sabe exatamente quantos bytes aquele dado vai ocupar antes do programa começar a rodar, ou seja, o tamanho da variável é fixa e previsível), o que garante maior eficiência.

Por outro lado, a heap memory é utilizada para armazenar dados que precisam permanecer acessíveis além do escopo atual ou cujo o tamanho só é conhecido em tempo de execução. Nela ficam os valores "reais" apontados por variáveis de referência, como objetos, arrays e estruturas dinâmicas.

Stack Memory

A stack memory é responsável por armazenar tipos por valor. Mas o que são tipos por valor?

Tipos por valor são aqueles em que a variável guarda diretamente o valor em si, e não uma referência para ele.

Exemplos comuns de tipos por valor: number, boolean, char, struct, int, float.

let a = 10;
let b = a;
b = 20;
console.log(a); // 10 => não foi afetado

Mas stack memory, também é uma estrutura de dados LIFO (Last in, First out), onde armazena dados de curta duração, como:

Chamadas de funções (frames da stack)
Variáveis primitivas (valores por valor, como mencionado anteriormente)
Referências para objetos que estão na heap

Algumas características são:

Rápida, alocação e desalocação ocorrem automaticamente, ajustando apenas o stack pointer.
Limitada, espaço pequeno (em torno de ~1MB por thread no Node.js por exemplo, podendo variar por sistema).
Limpeza automática quando uma função termina (os frames são removidos da pilha).
Armazena variáveis locais, parâmetros de função e endereços de retorno.
Quando a pilha antige seu limite, ocorre o erro conhecido como "stack overflow".

Heap Memory

Já a heap memory é responsável por armazenar tipos por referência.

Tipos por referência são aqueles em que a variável guarda o endereço (referência) do valor na memória, e não o valor em sí.

Quando uma variável é copiada, ambas passam a apontar para o mesmo dado, e alterar uma afeta a outra.

Tipos dos dados mais comuns utilizados por referência são: object, array, function(em JS), classes ou ponteiros.

let a = { x: 10 };
let b = a;
b.x = 20;
console.log(a.x); // 20 => ambos apontam para o mesmo objeto

A heap é uma região da memória usada para armazenar dados dinâmicos, cujo o tamanho ou tempo de vida não são conhecidos em tempo de compilação. Nela ficam os valores reais referenciados pelas variáveis da stack.

Algumas características:

Armazena objetos, arrays e funções.
Permite alocação dinâmica de memória.
É mais lenta que a stack, pois envolve gerenciamento de memória e ponteiros.
É gerenciada automaticamente por um Garbage Collector (em linguagens como JavaScript, Java, Go)
Os dados permanecem na memória até não serem mais referenciados.

E quando um dado deixa de ser referencido?

Um dado (objeto, array ou função) deixa de ser referenciado quando nenhuma variável ou estrutura ativa do programa aponta mais para ele na memória.

Em outras palavras: não existe mais nenhum caminho, a partir do código em execução, que leve até aquele valor na heap.

Quando isso acontece, o garbage collector entende que o valor não pode mais ser acessado e libera a memória automaticamente, um exemplo bem básico:

let user = { name: 'John'}
// A variável user referencia o objeto na heap

user = null
// Agora não existe mais nenhuma referência para o objeto { name: 'John' }

O objeto { name: 'John' } ainda existe fisicamente na heap mas como nenhuma variável aponta para ele, o garbage collector irá removê-lo em algum momento. Agora um outro exemplo interessante de perda de referência:

let obj1 = { x: 10 };
let obj2 = obj1;
obj1 = null; 
// Ainda há uma referência ativa (obj2), então o dado continua na heap

obj2 = null; 
// Agora não há mais nenhuma — o dado é elegível para coleta

Stack + Heap em conjunto (para assimilar mais rápido)

Durante a execução de um programa, a stack e a heap trabalham lado a lado par armazenar e gerenciar dados de forma eficiente.

A stack guarda as referências e valores simples (por valor), enquanto a heap armazena os valores complexos (por referência)

Quando uma variável na stack aponta para um objeto ou array, o endereço de memória desse objeto fica salvo na stack, mas o conteúdo real está na heap (como foi explicado anteriormente), exemplo:

function createUser() {
  const user = { name: "Henrique", age: 25 };
  return user;
}

const newUser = createUser();

A função createUser cria uma variável user na stack.
Essa variável guarda uma referência para um objeto armazenado na heap.
Quando a função termina, a stack é liberada, mas o objeto na heap permanece se ainda estiver sendo referenciado (newUser aponta para ele por exemplo).

Blank Space

Blank space é um espaço entre a stack memory e a heap memory, que é utilizada para expansão de uma das memórias caso haja necessidade (é interessante saber que existe caso queiram se aprofundar mais sobre o assunto).

Espero que esta explicação tenha ajudado a entender de forma prática o papel da stack e da heap, e como eles impactam a performance e o funcionamento do código. Ainda há muito a explorar sobre esse tema, como o funcionamento do Garbage Collector, otimizações de memória e outros detalhes que merecem posts e estudos dedicados da minha parte. Para quem quiser se aprofundar, certamente vale a pena.

Guards vs Interceptors no NestJS: quando usar cada um?

Henrique Reis — Fri, 18 Apr 2025 01:04:05 +0000

Recentemente tenho me aprofundado nas ferramentas que o NestJS proporciona por conta de projetos que trabalho atualmente, hoje gostaria de trazer um pouco sobre os Guards e Interceptors.

No Nest, tanto Guards quanto Interceptors são ferramentas poderosas do ciclo de vida das requisições. Mas cada um tem seu papel, e entender quando usar um ou outro pode te ajudar a escrever código mais limpo, seguro e organizado.

Guards

São classes que implementam a interface CanActivate e são responsáveis por determinar se uma rota pode ou não ser acessada. Eles são executados antes do controllers e até antes dos interceptors também.

O que é possível fazer com Guards?

Verificar se o usuário está autenticado (JWT, Keycloak, etc)
Autorização por roles (admin, user, departamentos)
Verificação de escopos de permissões
Feature toggles (acesso a funcionalidades baseado em planos de executação)

Exemplo:

@Injectable()  
export class RolesGuard implements CanActivate {
 constructor(private requiredRole: string) {} // Recebe a role necessária no construtor

 canActivate(context: ExecutionContext): boolean {
  const request = context.switchToHttp().getRequest();
  const user = request.user // Assume que o user já foi validado

  // Verifica se o usuer tem a role necessaria para processeguir
  return user?.roles?.includes(this.requiredRole)
 }
}

Aplicando o Guard no Controller

@UseGuard(RolesGuard)
@Get('protected')
public async getProtectEndpoint() {
 return 'Só é acessado se passar pelo Guard'
};

Ou Globalmente

app.useGlobalGuards(new RolesGuard());

Algumas vantagens

Rápidos e diretos, impedem que lógica do controller seja executada desnecessariamente.
Centralizam regras de acesso

Tradeoff

Não são ideias para transformar dados ou tratar respostas.
Devem retornar apenas true ou false (ou throw se for necessário lançar alguma exceção)

Interceptors

No NestJS é um decorator (@UseInterceptors()) que permite você aplicar interceptadores em controladores ou métodos de rota. Esses interceptadores é uma poderosa ferramente que permite interceptar, transformar, monitorar ou até substituir o comportamento padrão de requisições e respostas. Eles são como "middlewares inteligentes" que o NestJS proporciona.

O @UseInterceptors() permite executar lógica antes ou depois da execução de um handler (como um método de rota, por exemplo).

Como eles funcionam?
Quando aplicado a um método ou controller, o interceptor intercepta o ciclo de vida da requisição e te dá a chance de:
Modificar os dados da requisição antes de chegar no handler
Modificar ou formatar a resposta antes dela ser enviada de volta ao cliente (ou front-end)
Medir tempo de execução
Adicionar lógica comum como logging, cache, autenticação e etc.

Exemplo bem genérico:

@UseInterceptors(MyInterceptor)
@Get('data') 
public async getData() {
    return { hello: 'World' }
}

Nest exemplo, a classe MyInterceptor vai ser executada antes e/ou depois do método getData().

Um Interceptor básico

@Injectable()
export class LoggingIntercetor implement NestInterceptor {
 intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
  console.log('Antes da execução do handler')

  const now = Date.now()

  return next.handle().pipe(
   tap(() => console.log(`Depois... ${Date.now - now}ms`))
  )
 }
}

Esse Interceptor apenas loga o tempo que o método levou para responder.

Tradeoff

Podem ser complexos se usados em excesso, o aninhamento de vários interceptadores pode não ser uma boa escolha e é passível de se adotar uma outra estratégia.
Lógica errada pode afetar todos os endpoints sem perceber.

O uso de Guards ou Interceptors é situacional, não existe certo ou errado, e sim o que seu projeto e sua aplicação demanda.

Mas ultimamente estou analisando os cenários dessa forma:

Use Guards para decidir se a requisição continua.
Use Interceptors para transformar o que acontece durante ou depois da execução.

Espero que tenha ficado claro e fácil de se entender o que cada ferramenta é capaz de fazer. Usado com parcimônia pode ser um grande aliado na hora do seu desenvolvimento!

Autenticação e Autorização

Henrique Reis — Tue, 01 Apr 2025 21:58:12 +0000

Autenticação vs. Autorização

Na construção de qualquer software, os dois termos são bastante citados durante todo o processo de desenvolvimento. É com o uso destas duas técnicas que garantimos uma maior segurança aos recursos protegidos de um sistema. Sendo assim, vou explicar um pouco do que é e como funcionam cada um deles.

Autenticação

A autenticação é o processo de verificação da identidade digital de um usuário. Em termos simples, é qunado o usuário prova quem realmente é.

Um exemplo bem comum de autenticação é a combinação username e password.

Sempre que um usuário realiza login em um sistema que exige credenciais, ele está passando por um processo de autenticação. No entanto, esse não é o único método disponível para autenticr um usuário, existem outras formas que incluem:

- Validação por token
- CPF e senha
- E-mail e senha
- Certificado digital, entre outros

Cada método de autenticação tem sua aplicação específica e pode ser combinado com outras técnicas, como autenticação multifator (MFA), para reforçar a segurança.

Autorização

Por sua vez, a autorização é o processo que ocorre após ser validada a autenticação. Diz respeito aos privilégios que são concedidos a determinado usuário ao utilizar uma aplicação.

Serve para verificar se determinado usuário terá a permissão para utilizar, executar recursos ou manipular determinadas ações, que é de fundamental importância dentro de uma aplicação.

Um exemplo que posso atribuir a autorização é o uso de um ERP de uma determinada empresa, que após realizar a autenticação no sistema, o usuário do financeiro terá acesso apenas aos módulos correspondentes à realização de seu trabalho, como contas a pagar, contas a receber e etc.

- Controle de acesso:
    - Usuário: John Doe
    - Setor: Financeiro

- Ações autorizadas ao usuário do setor Financeiro:
    - Contas a pagar [X]
    - Contas a receber [X]
    - Controle de estoque
    - Cadastro de usuários
    - Vendas
    - Pedidos

Já um funcionário do setor de Recursos Humanos (RH) teria acesso a módulos específicos para suas funções, como cadastro de funcionários, histórico de salários e benefícios, e controle de exames médicos.

A autorização é um mecanismo fundamental para garantir que cada usuário tenha acesso apenas às informações e funcionalidades necessárias para sua função, evitando exposição indevida e desnecessária de dados muitas vezes sensíveis e ações não autorizadas.

Para concluir, embora estejam diretamente relacionadas, autenticação e autorização são processos distintos e complementares. A autenticação garante que o usuário é quem diz ser, enquanto a autorização define o que ele pode fazer dentro do sistema.

Compreender e implementar corretamente esses dois conceitos é essencial para fortalecer a segurança das aplicações e proteger dados críticos contra acessos não autorizados.

Padrão de teste: System Under Test (SUT)

Henrique Reis — Mon, 27 Jan 2025 19:34:10 +0000

O conceito System Under Test (SUT) refere-se ao sistema, módulo, função ou unidade de código que está sendo testado em uma bateria de testes unitários. Ele é o foco principal do teste, ou seja, é o "objeto" que você está avaliando para garantir que seu comportamento esteja de acordo com as expectativas definidas.

Características do SUT

Foco central do teste: O SUT é o componente específico que está sendo analisado para validar sua funcionalidade.
Isolamento: Em testes unitários, o SUT geralmente é isolado de dependências externas, como bancos de dados, APIs ou outros serviços, usando ferramentas como mocks, stubs ou fakes.
Entrada e saída bem definidas: Um teste unitário para um SUT verifica se a saída ou comportamento está correto dado um conjunto de entradas.
Pequena escala: O SUT deve ser pequeno e autocontido. Em vez de testar um sistema completo, o foco está em partes específicas, como funções, métodos ou classes.

Exemplo prático

Imagine que você tem uma função em um sistema de gerenciamento de clínicas chamada calculateClinicRevenue:

async function calculateClinicRevenue(appointments: Appointment[]): number {
    return appointments.reduce((total, appt) => total + appt.fee, 0)
}

Neste caso:

O SUT é a função calculateClinicRevenue
Os dados de entrada (um array de objetos Appointment) e a saida (um número representando a receita total) são os alvos do teste.

Teste unitário

describe('calculateClinicRevenue', () => {
    it('should calculate the total revenue correctly', async () => {
        const appointments = [
            { id: 1, fee: 100 },
            { id: 2, fee: 200 }
        ]

        const result = await calculateClinicRevenue(appointments)

        expect(result).toBe(300)
        expect(result).toHaveBeenCalledWith(appointments)
        expect(result).toHaveBeenCalledTimes(1)
    })

    it('should return 0 for an empty array', async () => {
        const appointments: Appointment[] = []

        const result = await calculateClinicRevenue(appointments)

        expect(result).toBe(0);
        expect(result).toHaveBeenCalledWith(appointments)
        expect(result).toHaveBeenCalledTimes(1)
    })
})

Aqui, a função calculateClinicRevenue é testada em diferentes cenários, verificando se produz a saída esperada com base nas entradas fornecidas.

Boas práticas ao testar utilizando SUT

Testar um comportamento específico por vez: Cada teste deve focar em um único aspecto do SUT para facilitar a depuração e o entendimento.
Mockar dependências externas: Se o SUT possui dependências, como chamadas a APIs ou banco de dados, use mocks ou stubs para isolar o teste (mock repositories com métodos de inserção e deleção de elementos em arrays são comumente utilizados).
Cobrir casos externos: Certifique-se de testar cenários normais, casos de erro e situações limite.
Esclarecer o escopo do SUT: Seja claro sobre o que está sendo testado e como o SUT interage com outras partes do sistema.

Lembre-se: Ajuste este modelo de teste de acordo com a sua necessidade na aplicação. Também é possível criar funções para seu SUT, como por exemplo

const makeSut = (
    users?: any
): {
    sut: CreateUser
    mockUserRepository: IUserRepository
} => {
    const mockUserRepository = new UserRepositoryInMemory(users)
    const sut = new CreateUser(mockUserRepository)

    jest.spyOn(mockUserRepository, 'findUserByCpf')
    jest.spyOn(mockUserRepository, 'findUserById')
    jest.spyOn(mockUserRepository, 'createUser')

    return { sut, mockUserRepository }
}

Desta maneira é possível utilizar execute do meu SUT diretamente no meu teste, como por exemplo:

const result = await sut.execute(mockUserPayload)

Resumo

O SUT é o componente principal testado em um cenário de teste unitário. Ele é isolado e avaliado com entradas e saídas controladas, garantindo que o comportamento seja validado sem interferências externas. Esse modelo de testes ajuda a identificar problemas em partes individuais do sistema de forma eficiente e granular.

Cache: Otimizando Desempenho e Reduzindo Custos na sua aplicação

Henrique Reis — Thu, 23 Jan 2025 00:18:38 +0000

O cache é uma técnica amplamente utilizada no desenvolvimento de software para melhorar o desempenho e a eficiência de sistemas. Ele se refere ao armazenamento temporário de dados frequentemente acessados ou computados para reduzir o tempo de acesso e o custo computacional de obter essas informações diretamente de uma fonte mais lenta (como um banco de dados, sistemas remoto ou disco rígido).

O que é Cache?
Cache é uma camada intermediária de armazenamento de dados, geralmente implementada para melhorar velocidade de leitura e escrita de informações. Ele pode ser localizado:

No cliente (por exemplo, no navegador para cache de páginas web ou assets estáticos como CSS e JavaScript).
No servidor (como sistemas de cache em memória, como Redis ou Memcached).
Entre serviços (em proxy reversso, como o Varnish, para armazenar respostas HTTP).

Tipos de Cache
Cache em Memória:

Armazena dados na memória volátil (RAM) para acesso rápido.
Exemplos: Redis, Memcached.

Cache de Disco:

Salva dados em armazenamentos secundários, como SSDs ou HDs.
Exemplo: Sistema de arquivos do SO (Linux Page Cache).

Cache de página:

Armazena páginas renderizadas (HTML) para acelerar a entrega do conteúdo.

Cache de Objetos:

Salva objetos ou trechos de dados, como resultados de consultas de banco de dados, otimizando buscas.

Cache Distribuído:

Implementado em sistemas distribuídos para compartilhar o cache entre várias instâncias.
Exemplos: Amazon ElastiCache e Google Cloud Memorystore.

Cache HTTP:

Utilizado para armazenar respostas de servidores HTTP.
Exemplos: Cabeçalhos HTTP ou Cache-Control e ETAG.

Como o Cache funciona?
O cache trabalha com um conceito bem conhecido, o chave-valor

Um valor (o dado armazenado) é acessado ou armazenado por meio de uma chave (normalmente um identificar único, como uma URL ou ID de consulta.
Quando um dado é requisitado:

O sistema verifica se ele está presente no cache (cache hit)
Caso contrário, o dado é buscado na fonte original (cache miss), processando e armazenando no cache para acessos futuros.

Importância do Cache no System Design de aplicações

Aceleração de desempenho
O cache reduz significativamente o tempo necessário para acessar dados frequentemente requisitados, já que evita operações custosas (como consultas a banco de dados ou chamadas de APIs externas)
Ideal para operações que envolvem leitura intensiva.
Redução de custos
Menor utilização de recursos computacionais (CPU, disco e de rede).
Reduz a carga no banco de dados e em outros sistemas críticos.
Escalabilidade
O cache ajuda sistemas a lidar com grande volumes de tráfegos, armazenando resultados de forma temporária para servir múltiplos usuários sem sobrecarregar o backend.
Tolerância a falhas
Em caso de falha em sistema downstream (como bancos de dados ou APIs externas), os dados armazenados no cache podem garantir a continuidade da aplicação temporariamente, disponibilizando informações armazenadas anteriormente.
Melhora na experiência do usuário (UX)
Respostas mais rápidas a consultas ou navegação aumentam a satisfação do usuário final.

Estratégias de Cache
Políticas de Expiração: Define por quanto tempo um item deve permanecer no cache. Exemplos: TTL (Time-To-Live), LRU (Least Recently Used).

Invalidações do Cache: Define como e quando os dados no cache devem ser atualizados ou removidos. Invalidação manual, baseada em eventos (por exemplo, uma atualização no banco de dados), TTL automático.

Cache Local x Global: Local: Armazena dados próximos ao consumidor (ex.: Cache no navegador), Global: Compartilhado entre vários serviços ou instâncias (ex.: Redis)

Desafios do Cache

Cache Miss: Quando um dado solicitado não está no cache, é necessário buscá-lo na fonte original, causando uma possível lentidão.
Problemas de consistência: Dados desatualizados no cache podem causar descreprâncias entre o sistema e a fonte original.
Supercarga de Memória: Armazenar dados excessivamente no cache pode esgotar a memória, especialmente um sistema de alto tráfego.
Invalidações complexas: Garantir que o cache seja atualizado de forma correta e no momento certo pode ser desafiador.
Soluções distribuídas: Em sistemas com múltiplos nós, manter a consistência e sincronização no cache é mais difícil.

Agora alguns exemplos onde o Cache é utilizado com frequência em aplicações reais:

E-commerce Armazenando produtos mais visualizados. Cache de sessões de usuários para manter carrinhos de compra.
Streaming de vídeo Utilização de CDNs (Content Delivery Network) para armazenar vídeos perto da localização do usuário.
Sistemas bancários Cache de transações ou dados no cliente para evitar consultas constantes ao banco de dados
Aplicações SaaS Cache de configurações personalizadas do cliente para evitar latências em APIs

Problemas que o Cache resolve em empresas de software
Reduzir tempo de reposta: Um banco de dados com milhões de registros

Redução de Custos de Infraestrutura: Com menos acesso ao banco de dados ou APIs de terceiros, há economia de recursos e custos.

Prevenção de Sobrecarga: Sistemas de alta demanda, como Black Friday em e-commerces, conseguem lidar com tráfego intenso usando cache para respostas rápidas ao clientes.

Melhor Escalabilidade: Permite que um sistema suporte um número maior de usuários sem a necessidade de dimensionar excessivamente a infraestrutura.

Resiliência contra Falhas: Sistemas que dependem de APIs externas podem armazenar dados no cache e operar parcialmente mesmo quando as APIs estão fora do ar.

Conclusão
O cache é essencial no system design de aplicações modernas. Ele otimiza o desempenho, melhora a experiência do usuário e reduz custos. No entanto, o uso eficaz de cache exige planejamento cuidadoso para evitar problemas de consistência e garantir que o sistema seja escalável e resiliente. Para empresas de software, o cache é uma ferramenta indispensável para resolver desafios relacionados a desempenho.