DEV Community: Bruno Mestres

GraphQL: o que é e por que ele importa nas APIs?

Bruno Mestres — Mon, 26 Oct 2026 17:33:48 +0000

Imagine uma tela que precisa exibir apenas o nome e a foto de um usuário.

Ao consultar a API, ela recebe também endereço, telefone, data de nascimento e vários outros campos que não serão utilizados.

Agora pense em outra tela que precisa dos dados desse usuário e dos títulos dos seus últimos artigos. Dependendo de como a API foi construída, isso pode exigir várias requisições.

GraphQL permite que o cliente descreva os dados de que precisa. Essa é uma das suas principais características.

O que é GraphQL?

GraphQL é uma linguagem de consulta para APIs, acompanhada de um mecanismo para executar essas consultas.

O servidor define os tipos, campos e operações disponíveis em um contrato chamado schema. Dentro desse contrato, o cliente escolhe quais campos deseja receber.

Por exemplo, uma consulta poderia ser:

query {
  usuario(id: "1") {
    nome
    foto
  }
}

E a resposta:

{
  "data": {
    "usuario": {
      "nome": "Bruno",
      "foto": "https://exemplo.com/foto.png"
    }
  }
}

A estrutura da resposta acompanha os campos solicitados. Se outra tela precisar de mais informações, poderá pedi-las, desde que estejam disponíveis no schema e seu acesso seja permitido.

Por que isso é importante?

Uma mesma API pode atender um aplicativo, um site e um painel administrativo. Cada um pode precisar de uma combinação diferente de dados.

Com GraphQL, esses clientes conseguem adaptar suas consultas às necessidades de cada tela. Também é possível consultar dados relacionados em uma única requisição, como um usuário e seus artigos. Isso pode reduzir tanto o excesso de dados na resposta quanto a quantidade de chamadas necessárias.

O ganho está na flexibilidade de consumir a API.

E os cuidados?

Essa flexibilidade também exige controle. Uma consulta pode pedir muitos dados e percorrer várias relações, gerando um custo alto para o servidor.

Por isso, uma implementação precisa cuidar de autorização, paginação e limites para as consultas. Receber apenas os campos solicitados não garante, por si só, uma execução barata no backend.

Por onde começar?

Para um primeiro contato, vale guardar esta ideia:

O servidor define o que pode ser consultado, e o cliente descreve o que precisa receber.

A partir daí, o próximo passo é entender como o schema organiza esses dados e como as funções chamadas resolvers buscam as informações para montar a resposta.

Circuit Breaker no NestJS com @nestjs/resilience

Bruno Mestres — Fri, 23 Oct 2026 13:07:43 +0000

Quando trabalhamos com APIs, é comum depender de serviços externos para executar determinadas operações.

Imagine uma aplicação de e-commerce que precisa se comunicar com uma transportadora para solicitar o envio de um pedido.

Mas o que acontece se a API da transportadora começar a apresentar falhas?

Uma alternativa para lidar com esse cenário é utilizar o Circuit Breaker, um padrão de resiliência que permite interromper temporariamente chamadas a um serviço quando ele apresenta falhas recorrentes.

No NestJS, podemos implementar esse comportamento de maneira declarativa utilizando o decorator @CircuitBreaker do módulo @nestjs/resilience.

Implementando o Circuit Breaker

Vamos considerar um endpoint responsável por solicitar o despacho de uma entrega:

@Post(':id/dispatch')
@CircuitBreaker({
  name: 'carrier',
  minimumCalls: 2,
  failureRateThreshold: 50,
  slidingWindow: { type: 'count', size: 2 },
  openDuration: '5s',
})
dispatch(@Param('id') id: string) {
  return this.shippingService.dispatch(id);
}

Nesse exemplo, aplicamos o Circuit Breaker diretamente ao método responsável por iniciar o despacho.

O decorator recebe algumas configurações que determinam quando o circuito deve ser aberto e por quanto tempo as chamadas serão interrompidas.

Vamos entender cada uma:

name: identifica o circuito como carrier.
minimumCalls: define o mínimo de chamadas necessárias para avaliar a taxa de falhas.
failureRateThreshold: estabelece a porcentagem de falhas necessária para abrir o circuito. Nesse caso, 50%.
slidingWindow: define uma janela de avaliação baseada nas últimas 2 chamadas.
openDuration: determina que o circuito permaneça aberto por 5 segundos antes de permitir uma tentativa de recuperação.

Com essa configuração, se uma das duas chamadas falhar, o circuito poderá ser aberto, pois a taxa de falhas atingiu 50%.

Enquanto estiver aberto, novas chamadas protegidas pelo circuito serão rejeitadas sem executar o método.

Após os 5 segundos, o circuito poderá entrar no estado Half-Open, permitindo verificar se o serviço voltou a funcionar normalmente.

O que ganhamos com essa abordagem?

Uma das principais vantagens é conseguir aplicar uma estratégia de resiliência sem precisar implementar manualmente toda a lógica de controle de falhas.

Também conseguimos manter o código mais organizado, separando a regra de negócio da configuração do Circuit Breaker.

Entretanto, vale lembrar que o Circuit Breaker não resolve a indisponibilidade do serviço externo. Ele apenas evita que continuemos realizando chamadas para uma dependência que apresenta problemas.

Além disso, a configuração utilizada no exemplo é bastante sensível, já que considera apenas duas chamadas. Em produção, os valores devem ser ajustados de acordo com o volume de requisições e o comportamento esperado da aplicação.

Conclusão

O @nestjs/resilience oferece uma maneira prática de adicionar mecanismos de resiliência às aplicações NestJS.

Com poucas configurações, conseguimos proteger operações que dependem de serviços externos e reduzir o impacto de falhas recorrentes.

O mais importante não é simplesmente adicionar um Circuit Breaker, mas entender quando utilizá-lo e como configurar seus limites para evitar que uma proteção acabe prejudicando a disponibilidade da própria aplicação.

Fingerprinting: o que seu navegador revela sobre você?

Bruno Mestres — Thu, 22 Oct 2026 00:24:52 +0000

Quando acessamos um site, nosso navegador pode compartilhar mais informações do que imaginamos.

Sistema operacional, resolução da tela, idioma, fuso horário e até características da renderização gráfica são alguns exemplos.

Individualmente, essas informações podem parecer pouco relevantes. Mas, quando combinadas, podem formar uma espécie de impressão digital do navegador, conhecida como Browser Fingerprinting.

Essa técnica pode ser utilizada tanto para melhorar a segurança de aplicações quanto para rastrear usuários, mesmo sem depender de cookies ou autenticação.

Mas como isso funciona na prática?

Como funciona o Browser Fingerprinting?

O Browser Fingerprinting consiste em coletar características do navegador e do ambiente em que ele está sendo executado.

Essas informações são combinadas para criar uma identificação que pode ajudar a reconhecer o mesmo ambiente em diferentes acessos.

Existem diversas técnicas para isso, mas vamos conhecer duas abordagens: a coleta de informações via JavaScript e o Canvas Fingerprinting.

1. Coletando informações com JavaScript

Uma das formas mais simples de construir um fingerprint é utilizar APIs disponibilizadas pelo próprio navegador.

Com poucas linhas de JavaScript, conseguimos coletar algumas características do ambiente:

function getDeviceInfo() {
  return {
    userAgent: navigator.userAgent,
    language: navigator.language,
    platform: navigator.platform,
    timezone: Intl.DateTimeFormat()
      .resolvedOptions().timeZone,
    screenWidth: screen.width,
    screenHeight: screen.height,
    cores: navigator.hardwareConcurrency,
  };
}

console.log(getDeviceInfo());

Nesse exemplo, estamos coletando informações como navegador, plataforma, idioma, fuso horário, resolução da tela e quantidade de processadores lógicos disponibilizada pelo navegador.

Esses dados podem ser combinados e processados por uma função de hash, como SHA-256, para gerar uma identificação.

Entretanto, o hash não garante que um dispositivo seja identificado de forma única. Dois ambientes podem apresentar características semelhantes, e mudanças nas configurações podem alterar o resultado.

Também é importante lembrar que os navegadores limitam algumas informações para proteger a privacidade dos usuários.

2. Canvas Fingerprinting

Outra técnica interessante é o Canvas Fingerprinting.

Nesse caso, utilizamos o elemento <canvas> do HTML para desenhar textos e elementos gráficos, normalmente sem exibi-los ao usuário.

O detalhe é que diferentes combinações de navegador, sistema operacional, fontes e hardware gráfico podem produzir pequenas diferenças na renderização.

Podemos observar isso com um exemplo simples:

function getCanvasFingerprint() {
  const canvas = document.createElement("canvas");
  canvas.width = 300;
  canvas.height = 100;

  const ctx = canvas.getContext("2d");

  if (!ctx) return null;

  ctx.font = "16px Arial";
  ctx.fillStyle = "#069";
  ctx.fillText("Fingerprint Test", 15, 30);

  return canvas.toDataURL();
}

console.log(getCanvasFingerprint());

O método toDataURL() retorna uma representação da imagem renderizada, que pode ser utilizada como entrada para uma função de hash.

Assim, pequenas diferenças na renderização podem resultar em hashes diferentes.

Vale destacar que o Canvas Fingerprinting também depende de JavaScript e que diferentes dispositivos podem produzir resultados idênticos.

Fingerprinting é uma ameaça à segurança?

Não necessariamente.

O fingerprinting é uma técnica, e seu impacto depende da finalidade para a qual é utilizado.

Em aplicações financeiras, por exemplo, pode ajudar a identificar tentativas suspeitas de acesso, detectar bots ou reconhecer padrões associados a fraudes.

Por outro lado, também pode ser utilizado para rastrear usuários entre sessões e sites, mesmo quando eles removem cookies ou utilizam navegação anônima.

Isso acontece porque a identificação não depende exclusivamente de informações armazenadas no navegador, mas também das características do próprio ambiente.

Por esse motivo, o fingerprinting levanta discussões importantes sobre privacidade e proteção de dados, incluindo a LGPD.

Como se proteger do Browser Fingerprinting?

Uma das formas de limitar a coleta de informações é desabilitar o JavaScript.

Como muitas técnicas de fingerprinting dependem da execução de scripts, essa medida pode impedir a coleta de diversos sinais, incluindo os utilizados no Canvas Fingerprinting.

Mas existe um trade-off.

Grande parte das aplicações modernas depende de JavaScript para funcionar corretamente. Ao desabilitá-lo, podemos perder funcionalidades, comprometer interfaces ou até impedir o funcionamento de determinados sites.

Existem alternativas menos restritivas, como:

Utilizar navegadores com proteção contra rastreamento e fingerprinting.
Manter o navegador atualizado.
Evitar extensões desnecessárias, que podem aumentar a superfície de identificação.
Revisar as configurações de privacidade do navegador.

Nenhuma dessas medidas garante anonimato completo.

Além disso, desabilitar JavaScript não impede a coleta de informações transmitidas nas requisições HTTP ou de características da conexão.

Considerações finais

O Browser Fingerprinting mostra como informações aparentemente simples podem ganhar outro significado quando combinadas.

Para desenvolvedores, pode ser uma ferramenta interessante na construção de mecanismos de segurança e prevenção de fraudes.

Para usuários, representa mais um motivo para entender quais informações são expostas durante a navegação.

E aqui temos um trade-off importante: quanto mais informações uma aplicação coleta para reconhecer um ambiente, maiores podem ser os impactos sobre a privacidade.

O desafio não é apenas identificar dispositivos, mas entender quando essa identificação é realmente necessária e quais limites devemos estabelecer.

No desenvolvimento de software, segurança e privacidade precisam caminhar juntas.

Trade-offs: por que toda decisão de arquitetura tem um preço?

Bruno Mestres — Tue, 20 Oct 2026 00:52:45 +0000

Em arquitetura de software, não existe solução perfeita. Existe solução adequada ao contexto.

Vivemos em um cenário onde novas tecnologias, ferramentas e conceitos surgem constantemente.

Hoje, podemos encontrar facilmente dez soluções diferentes para resolver um mesmo problema.

Mas ter mais opções não significa necessariamente tomar decisões melhores.

Cada abordagem oferece vantagens, mas também apresenta custos e limitações. Por isso, precisamos avaliar cuidadosamente o que realmente faz sentido para o nosso projeto.

É justamente aqui que entra um conceito fundamental na arquitetura de software: trade-off.

🤔 O que é um trade-off?

Um trade-off acontece quando precisamos abrir mão de algo para obter outro benefício.

Imagine que você está decidindo entre uma arquitetura monolítica e microsserviços.

Monolito:

✅ Menor complexidade inicial.

✅ Desenvolvimento e deploy mais simples.

⚠️ Pode dificultar a evolução independente de partes do sistema.

Microsserviços:

✅ Escalabilidade independente dos serviços.

✅ Maior autonomia entre equipes.

⚠️ Aumento da complexidade operacional.

⚠️ Maior dificuldade para lidar com comunicação e consistência de dados.

Perceba que nenhuma das abordagens é necessariamente melhor.

Tudo depende do problema que estamos tentando resolver.

🏗️ Por que isso importa para um arquiteto de software?

O papel de um arquiteto não é simplesmente escolher a tecnologia mais moderna ou o padrão mais popular.

É entender os impactos de cada decisão.

Por exemplo:

Precisamos realmente de escalabilidade independente?

Nossa equipe consegue lidar com a complexidade operacional?

Estamos priorizando performance, disponibilidade ou simplicidade?

O custo de manutenção dessa solução compensa seus benefícios?

Essas perguntas ajudam a evitar decisões baseadas apenas em tendências.

⚖️ Arquitetura é sobre escolhas

Um sistema altamente distribuído pode oferecer maior flexibilidade, mas também exigir mais infraestrutura, monitoramento e conhecimento técnico.

Por outro lado, uma arquitetura mais simples pode atender perfeitamente às necessidades do negócio.

E está tudo bem.

Complexidade não é sinônimo de qualidade arquitetural.

💡 Conclusão

Entender trade-offs é uma das habilidades mais importantes para quem trabalha com arquitetura de software.

Porque uma boa decisão arquitetural não é aquela que oferece mais benefícios isoladamente.

É aquela em que os benefícios justificam os custos e as limitações dentro do contexto do projeto.

No fim, arquitetura de software não é sobre encontrar a solução perfeita.

É sobre tomar decisões conscientes e saber explicar por que elas fazem sentido.

Content Security Policy (CSP) no NestJS: protegendo sua aplicação com Helmet

Bruno Mestres — Fri, 16 Oct 2026 17:36:06 +0000

Quando falamos sobre segurança em APIs, normalmente pensamos em autenticação, autorização e validação de dados.

Mas existe outra camada de proteção que muitas vezes passa despercebida: os headers de segurança HTTP.

Um deles é o Content Security Policy (CSP).

Neste tutorial, vamos entender o que é CSP e como configurá-lo em uma aplicação NestJS utilizando o Helmet.

O que é CSP?

O Content Security Policy é um mecanismo de segurança que permite definir quais recursos o navegador está autorizado a carregar e executar.

Por exemplo, podemos restringir:

Scripts JavaScript.
Arquivos CSS.
Imagens.
Recursos de domínios externos.

Isso ajuda a reduzir os riscos de ataques como Cross-Site Scripting (XSS), limitando a execução de conteúdos não autorizados.

Vale destacar que o CSP é uma camada adicional de proteção, não um substituto para validação de entradas e tratamento seguro de dados.

1. Instalando o Helmet

O NestJS permite utilizar o Helmet como middleware para configurar diversos headers de segurança.

Primeiro, instale a dependência:

npm install helmet

Depois, importe o Helmet no arquivo main.ts:

import helmet from 'helmet';

2. Configurando o CSP

Vamos adicionar a configuração ao bootstrap da aplicação.

import { NestFactory } from '@nestjs/core';
import helmet from 'helmet';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  app.use(
    helmet({
      contentSecurityPolicy: {
        directives: {
          defaultSrc: ["'self'"],
          scriptSrc: ["'self'"],
          styleSrc: ["'self'", "'unsafe-inline'"],
          imgSrc: ["'self'", 'data:', 'https:'],
        },
      },
      crossOriginEmbedderPolicy: false,
      hsts: {
        maxAge: 31536000,
        includeSubDomains: true,
        preload: true,
      },
    }),
  );

  await app.listen(3000);
}

bootstrap();

Com isso, o Helmet passa a enviar headers de segurança nas respostas HTTP da aplicação.

Importante: o CSP é aplicado pelo navegador aos documentos que ele carrega. Em uma API que retorna apenas JSON, seu efeito direto costuma ser limitado.

Ele se torna especialmente relevante quando o NestJS também entrega páginas HTML, documentação Swagger ou outros recursos consumidos pelo navegador.

3. Entendendo as diretivas

Vamos analisar as configurações que utilizamos.

`defaultSrc: ["'self'"]`

Define a política padrão para recursos que não possuem uma diretiva específica.

O valor 'self' permite carregar recursos da mesma origem da página.

`scriptSrc: ["'self'"]`

Restringe o carregamento de scripts à própria origem.

Isso ajuda a impedir a execução de scripts externos não autorizados.

`styleSrc: ["'self'", "'unsafe-inline'"]`

Permite carregar estilos da própria origem e utilizar estilos inline.

O unsafe-inline facilita a compatibilidade com aplicações que dependem desse comportamento, mas reduz a proteção oferecida pelo CSP.

Sempre que possível, prefira estilos externos ou mecanismos como nonces e hashes.

`imgSrc: ["'self'", "data:", "https:"]`

Permite carregar imagens de três tipos de origem:

'self': mesma origem da aplicação.
data:: imagens incorporadas utilizando Data URLs.
https:: imagens provenientes de qualquer origem HTTPS.

Essa configuração oferece flexibilidade, mas pode ser restringida a domínios específicos quando necessário.

4. E as outras configurações do Helmet?

Além do CSP, adicionamos duas configurações importantes.

`crossOriginEmbedderPolicy: false`

Desativa o envio do header Cross-Origin-Embedder-Policy pelo Helmet.

Isso pode evitar problemas de compatibilidade com recursos externos que não estão preparados para as exigências dessa política.

Por outro lado, desativá-lo significa abrir mão dessa camada de isolamento.

`hsts`

hsts: {
  maxAge: 31536000,
  includeSubDomains: true,
  preload: true,
}

O HTTP Strict Transport Security (HSTS) instrui navegadores a utilizar HTTPS para futuras conexões com o domínio.

Nessa configuração:

maxAge: mantém a política por aproximadamente um ano.
includeSubDomains: estende a política aos subdomínios.
preload: declara a intenção de utilizar a lista de pré-carregamento HSTS dos navegadores.

Atenção: configurar preload: true não adiciona automaticamente seu domínio à lista de preload.

Antes de utilizar essa opção em produção, é importante garantir que todos os subdomínios envolvidos suportem HTTPS corretamente.

5. Como verificar se está funcionando?

Inicie a aplicação:

npm run start:dev

Depois, faça uma requisição para um endpoint existente:

curl -i http://localhost:3000

Você deverá encontrar um header semelhante a este:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:

O Helmet também pode adicionar outras diretivas padrão à política, mesmo que não estejam explicitamente declaradas no código.

Outra opção é abrir o DevTools do navegador, acessar a aba Network e inspecionar os Response Headers.

Para verificar se uma política realmente bloqueia recursos, é necessário testá-la em uma página HTML que tente carregá-los.

6. Quais são os trade-offs?

Apesar dos benefícios, configurar CSP exige alguns cuidados.

Benefícios

Redução da superfície de ataque: ajuda a mitigar determinadas formas de XSS.
Controle de recursos: permite definir quais origens são autorizadas.
Segurança adicional: adiciona uma camada de proteção no navegador.
Centralização: facilita a configuração de headers de segurança.

Trade-offs

Compatibilidade: políticas restritivas podem bloquear recursos legítimos.
Estilos e scripts inline: algumas bibliotecas podem exigir ajustes.
Integrações externas: domínios utilizados pela aplicação precisam ser considerados.
Manutenção: novas dependências podem exigir alterações na política.

Uma boa estratégia é começar utilizando Content-Security-Policy-Report-Only para identificar possíveis violações antes de aplicar bloqueios em produção.

Conclusão

Implementar CSP com Helmet no NestJS é relativamente simples.

O maior desafio não está em adicionar o middleware, mas em definir uma política que equilibre segurança e compatibilidade.

Também é importante lembrar que o Helmet oferece outras proteções além do CSP, e que headers de segurança não substituem boas práticas de desenvolvimento.

Segurança não depende de uma única configuração. Ela é construída em camadas.

CQRS: vale a pena separar leitura e escrita?

Bruno Mestres — Thu, 15 Oct 2026 00:05:38 +0000

Uma das abordagens que mais gosto quando estou estruturando um projeto é o CQRS (Command Query Responsibility Segregation).

Já utilizei esse padrão em alguns projetos e gosto bastante da organização que ele proporciona.

Mas será que vale a pena usar em qualquer aplicação?

O que é CQRS?

A ideia é simples: separar as operações de leitura das operações de escrita.

Em uma aplicação tradicional, um mesmo serviço pode ser responsável por criar, atualizar, excluir e consultar dados.

Com CQRS, dividimos essas responsabilidades em dois grupos:

Commands: operações que modificam o estado da aplicação, como criar ou atualizar um usuário.
Queries: operações que apenas consultam informações, como buscar ou listar usuários.

E um detalhe importante: não precisamos de microsserviços ou bancos de dados separados para utilizar CQRS.

Essa separação pode acontecer dentro de um monólito.

O que ganhamos? ✅

Organização: responsabilidades mais claras.
Manutenção: facilita encontrar e modificar operações específicas.
Flexibilidade: permite utilizar modelos diferentes para leitura e escrita.
Escalabilidade: abre possibilidades para otimizar os dois fluxos independentemente.

E o que perdemos? ❌

Mais complexidade: uma operação simples pode exigir mais componentes e arquivos.
Mais abstrações: aumenta a curva de aprendizado.
Mais manutenção: exige consistência na organização do projeto.
Sincronização: caso os dados sejam armazenados separadamente, podemos precisar lidar com consistência eventual.

Afinal, vale a pena?

Particularmente, gosto bastante de CQRS pela organização que proporciona.

Mas, para um CRUD simples, talvez essa separação seja mais trabalho do que benefício.

Já em aplicações com regras de negócio mais complexas, pode fazer bastante sentido.

No fim, não existe padrão arquitetural gratuito. Toda escolha traz benefícios e custos.

Coesão e Acoplamento: dois conceitos fundamentais da arquitetura de software

Bruno Mestres — Sun, 11 Oct 2026 17:39:14 +0000

Coesão e Acoplamento: dois conceitos fundamentais da arquitetura de software

Ao desenvolver uma aplicação, é comum focarmos em funcionalidades, regras de negócio e requisitos. Mas existe outra preocupação importante: como organizamos o código e como as partes do sistema se relacionam?

É nesse ponto que dois conceitos ganham importância: coesão e acoplamento.

Embora sejam conceitos simples, eles influenciam diretamente a manutenibilidade, a testabilidade e a capacidade de evolução de uma aplicação.

O que é coesão?

Coesão representa o quanto as responsabilidades de um módulo estão relacionadas entre si.

Um módulo com alta coesão possui um propósito bem definido. Suas funcionalidades trabalham em conjunto para cumprir uma responsabilidade específica.

Imagine um serviço responsável pelo gerenciamento de usuários. Ele pode conter operações como:

Cadastrar um usuário.
Atualizar seus dados.
Consultar suas informações.
Desativar uma conta.

Essas operações estão relacionadas ao mesmo domínio, o que contribui para uma boa coesão.

Agora imagine que esse mesmo serviço também seja responsável por processar pagamentos e gerar relatórios financeiros.

As responsabilidades começam a se distanciar, tornando o componente mais difícil de compreender e modificar.

A ideia é manter juntas as funcionalidades que pertencem ao mesmo propósito.

O que é acoplamento?

Acoplamento representa o grau de dependência entre diferentes módulos ou componentes.

Quando um componente depende diretamente dos detalhes internos de outro, mudanças na implementação podem gerar impactos em diferentes partes do sistema.

Considere o seguinte exemplo em TypeScript:

class MySQLDatabase {
  save(data: string): void {
    console.log("Salvando no MySQL:", data);
  }
}

class UserService {
  private database = new MySQLDatabase();

  createUser(name: string): void {
    this.database.save(name);
  }
}

Nesse exemplo, UserService cria diretamente uma instância de MySQLDatabase.

Isso significa que o serviço está acoplado a uma implementação específica. Se precisarmos trocar o banco de dados ou utilizar uma implementação em memória nos testes, será necessário modificar a estrutura ou criar mecanismos adicionais para acomodar essa mudança.

Uma alternativa é depender de uma abstração:

interface Database {
  save(data: string): void;
}

class MySQLDatabase implements Database {
  save(data: string): void {
    console.log("Salvando no MySQL:", data);
  }
}

class UserService {
  constructor(private database: Database) {}

  createUser(name: string): void {
    this.database.save(name);
  }
}

Agora, UserService não precisa conhecer a implementação concreta do banco de dados.

Podemos fornecer diferentes implementações que respeitem o contrato definido pela interface.

Isso reduz o acoplamento com uma implementação específica e facilita a substituição de dependências.

Vale destacar que a interface, sozinha, não elimina o acoplamento. O serviço ainda depende do contrato Database, mas não precisa depender de uma implementação concreta.

Como esses conceitos se complementam?

Coesão e acoplamento analisam aspectos diferentes da organização do software.

Alta coesão: as responsabilidades de um módulo fazem sentido juntas.
Baixo acoplamento: os módulos possuem dependências controladas e não precisam conhecer detalhes desnecessários uns dos outros.

O objetivo não é eliminar todas as dependências. Sistemas precisam de colaboração entre componentes para funcionar.

O importante é organizar essa colaboração de maneira que uma mudança não provoque uma sequência desnecessária de alterações em toda a aplicação.

Isso significa que precisamos criar mais abstrações?

Não necessariamente.

Adicionar interfaces, classes e camadas sem uma necessidade concreta pode aumentar a complexidade em vez de reduzi-la.

Uma aplicação pequena pode funcionar muito bem com uma estrutura simples. Conforme surgem novas responsabilidades e necessidades de evolução, determinadas abstrações podem começar a fazer sentido.

A arquitetura deve resolver problemas reais, não criar estruturas apenas para seguir um padrão.

Conclusão

Coesão e acoplamento são fundamentos importantes para construir sistemas que possam evoluir de forma sustentável.

Ao organizar um módulo, pergunte se suas responsabilidades realmente pertencem juntas.

Ao criar uma dependência, avalie se o componente precisa conhecer uma implementação específica ou se pode trabalhar com um contrato mais estável.

Essas decisões parecem pequenas, mas podem fazer uma diferença significativa conforme a aplicação cresce.

Uma boa arquitetura não é aquela que elimina a complexidade, mas aquela que evita espalhá-la desnecessariamente pelo sistema.

[Boost]

Bruno Mestres — Thu, 27 Feb 2025 02:53:18 +0000

🚀 Como Rodar uma API Node.js + PostgreSQL com Docker

Bruno Mestres ・ Feb 26

#docker #node #postgres

🚀 Como Rodar uma API Node.js + PostgreSQL com Docker

Bruno Mestres — Wed, 26 Feb 2025 20:53:18 +0000

Hoje, vou compartilhar um exemplo prático e direto para quem quer aprender Docker: subir uma API Node.js conectada ao PostgreSQL sem precisar instalar o banco localmente.

Se você já perdeu tempo configurando dependências no seu ambiente ou precisa garantir que tudo funcione igual em qualquer máquina, Docker é a solução!

📌 Estruturando o Projeto
Criamos dois containers:
🔹 App Node.js para servir uma API
🔹 Banco PostgreSQL para armazenar os dados

📦 meu-projeto-docker ┣ 📂 src ┃ ┣ 📜 main.ts ┣ 📜 Dockerfile ┣ 📜 docker-compose.yml ┣ 📜 package.json
1️⃣ Criando a API Node.js
Dentro do projeto, inicialize o package.json:

npm init -y

Instale as dependências:

npm install express pg

Agora, crie src/main.ts:

import express from "express";
import pg from 'pg'
const { Pool } = pg
const app = express();

const pool = new Pool({
  user: "postgres",
  host: "db",
  database: "meubanco",
  password: "postgres",
  port: 5432,
});

app.get("/", async (req, res) => {
  const response = await pool.query("SELECT NOW()");

  res.send(`Banco conectado! Hora atual: ${response.rows[0].now}`);
});



app.listen(3000, () => console.log("API running on port 3000"));

2️⃣ Criando o Dockerfile

Esse arquivo define a imagem da nossa API:

Dockerfile

FROM node:23
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "src/main.ts"]

3️⃣ Configurando o Docker Compose

Aqui criamos os serviços da API e do PostgreSQL.

docker-compose.yml

version: "3.8"

services:
  db:
    image: postgres:15
    restart: always
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: meubanco
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

  app:
    build: .
    restart: always
    depends_on:
      - db
    ports:
      - "3000:3000"
    volumes:
      - .:/app

volumes:
  pgdata:

4️⃣ Rodando o Projeto 🚀

Agora é só rodar:

docker compose up -d

E acessar a API em:
http://localhost:3000

Enfim, com Docker, garantimos que nosso ambiente seja consistente, evitando aqueles famosos "na minha máquina funciona".

Esse foi só o começo! Podemos evoluir esse setup com migrations, CI/CD e Kubernetes. Se quiser mais conteúdos como esse, comenta aí! 👇🔥

Construindo uma API segura e eficiente com @fastify/jwt e @fastify/mongodb

Bruno Mestres — Mon, 13 Jan 2025 22:14:10 +0000

Ultimamente tenho utilizado bastante o Fastify em meus projetos pessoais, recentemente descobri diversas funcionalidades através de plugins oficiais.

Eles são leves, eficientes e, o melhor de tudo, encaixam perfeitamente no ecossistema do Fastify.

Então resolvi criar um projeto prático com autenticação e persistência, utilizando o JWT e o MongoDB.

Plugins usados no projeto:

⚒️ O @fastify/jwt é um plugin oficial que simplifica a autenticação com JSON Web Tokens. Com ele, dá pra:

Gerar tokens JWT de forma rápida.
Verificar tokens automaticamente nas rotas protegidas.

⚒️ @fastify/mongodb: Plugin oficial do Fastify para integração com o banco de dados MongoDB.

Ele se encarrega de gerenciar a conexão com o MongoDB de forma eficiente, sem que eu precise ficar configurando drivers manualmente.

Os plugins seguem uma interface padrão. Basta registrá-los com fastify.register(), definir algumas configurações e pronto.

Depois disso posso, acessar o banco diretamente com fastify.mongo e o módulo do jwt com o fastify.jwt.

Também criei um decorator para anexar apenas as rotas que seriam protegidas, onde ele verificará o token passado no cabeçalho.

import Fastify from "fastify";
import mongodb from "@fastify/mongodb";
import jwt from "@fastify/jwt";
import { config } from "./constants.ts";
import * as bcrypt from "bcrypt";

const fastify = Fastify();

type RequestUser = {
  username: string;
  email: string;
  password: string;
};

fastify.register(mongodb, {
  forceClose: true,
  url: config.MONGO_URL,
});

fastify.register(jwt, {
  secret: "supersecret",
});

fastify.post("/signup", async (req, reply) => {
  const salt = 10;
  const { email, password, username } = req.body as RequestUser;

  const data = {
    username,
    email,
    password: await bcrypt.hash(password, salt),
  };

  const user = await fastify.mongo.client.db("plugins").collection("users").insertOne(data);

  reply.send({ user })
});

fastify.decorate("auth", async (request, reply) => {
  try {
    await request.jwtVerify();
  } catch (err) {
    reply.send(err);
  }
});

fastify.post("/signin", (req, reply) => {
  // some code
  const body = req.body;
  const token = fastify.jwt.sign({ body });
  console.log(token);
  reply.send({ token });
});

fastify.get("/", { onRequest: [fastify.auth] }, async (req, reply) => {
  const users = fastify.mongo?.client.db("plugins").collection("users").find();

  const data: any = [];

  for await (const doc of users) {
    data.push(doc);
  }
  return data;
});

fastify.listen({ port: 3333 }, (err) => {
  if (err) process.exit(1);

  console.log("Running server");
});

Design Pattern - Strategy

Bruno Mestres — Mon, 18 Mar 2024 13:52:30 +0000

Ultimamente tenho estudado bastante padrões de projetos, então resolvi escrever um pouco sobre alguns, e decidi começar pelo Strategy.

O Strategy é um padrão de projeto da categoria comportamental, que permite que você crie uma hierarquia de algoritmos, separando os objetos intercambiáveis em classes separadas.
Esse padrão é muito útil quando temos um código carregado de condições, ele permite que nosso código se adapte a diversas situações que venha acontecer posteriormente.

Digamos que tenham algumas regras de negocio para dar desconto em um Ecommerce, e ela varia dependendo de diversos fatores, como quantidade de produtos no carrinho, ou um determinado valor a ser batido, promoções e etc. Nesse caso a classe que representa o carrinho de compra teria que verificar cada uma dessas variantes com diversos IFS e aplicar o valor correto, e a medida que mais opções de desconto fosse adicionado na regra de negocio, teríamos que mexer na classe do carrinho, tornando o código cada vez mais difícil de se manter e aumentando a chance de criar bugs em códigos que já estavam funcionando.

O Strategy sugere que nesse caso, pegue a classe que tem diversos IFS e separe os códigos em outras classes separadas, chamadas de estratégias.

Na estrutura desse Padrão temos:
O contexto e a classe que contem o algoritmo com a lógica comum, ela vem carregada de condições.
A interface da Strategy, que define a função que as estratégias deverão executar.
E as estratégias que são os algoritmos específicos para cada situação que o código cliente chamar.