Nota para desenvolvedores: Se você prefere ir direto ao código, o repositório completo com a implementação desta arquitetura está disponível aqui: github.com/carol8fml/nexus-notification-hub. 🤟🏾
Olá, pessoal!
Um tempo atrás, na empresa onde eu trabalho, recebi do gestor de engenharia a tarefa de fazer uma análise de serviços externos para envio transacional de e-mail. Na época, usávamos o SendGrid em quatro aplicações web e precisávamos expandir para o aplicativo principal da empresa.
A previsão era escalar para cerca de 250.000 envios por mês. Precisávamos comparar preços e funcionalidades de outras plataformas para validar se a troca fazia sentido.
Durante a análise, avaliei mais de 10 serviços similares. Encontrei opções mais baratas e com mais funcionalidades, mas o custo real eu só descobri no final: seria a mão de obra dos desenvolvedores.
Para trocar o serviço nas quatro aplicações que já tinham integrado o SendGrid, o custo seria altíssimo. O motivo? A lógica estava totalmente acoplada aos repositórios, tanto nos que utilizavam programação funcional quanto naqueles que já eram considerados ‘quase arquitetura limpa’.
Estipulei junto com o time que essa troca levaria meses para se encaixar nas Sprints. Teríamos que tirar desenvolvedores das features principais apenas para essa refatoração.
No final, o resultado foi continuar com o SendGrid, mesmo não sendo a melhor opção financeira na hora. A empresa ficou refém daquele serviço por uma limitação técnica.
Foi dessa experiência que nasceu a ideia do Nexus Notification Hub.
Durante meus estudos para aprofundar conhecimentos em Arquitetura de Software, decidi que não queria apenas ler sobre padrões; eu queria aplicar a teoria para resolver problemas reais que enfrentei na carreira. E o objetivo dessa POC foi validar uma arquitetura que impedisse esse acoplamento, utilizando uma stack robusta (NestJS, Nx) aliada a padrões de projeto clássicos, especificamente o Adapter Pattern.
Se tivéssemos essa arquitetura desenhada na época, o cenário seria outro:
- Eu criaria um arquivo novo (o Adapter).
- Mudaria uma linha de configuração.
- Pronto.
A seguir, detalho como implementei essa arquitetura na prática, criando uma solução onde trocar de SendGrid para AWS (ou qualquer outro provedor) leva minutos, e não meses.
A Arquitetura: Adapter Pattern na Prática
A solução se baseia em dois padrões clássicos trabalhando em conjunto: o Adapter Pattern e o Factory Pattern. A ideia é simples: criar uma camada de abstração que isola completamente a lógica de negócio das implementações específicas de cada serviço de e-mail.
1. O Contrato: A Interface NotificationProvider
Tudo começa com uma interface que define o contrato mínimo que qualquer provedor de notificação precisa seguir:
export interface NotificationProvider {
send(to: string, content: string): Promise<void>;
}
Essa interface é o coração da arquitetura. Ela estabelece que, independente de estarmos usando SendGrid, AWS SES, Mailtrap ou qualquer outro serviço, todos precisam implementar o método send com essa assinatura exata.
Na prática: O resto do código (Controller, Factory, Use Cases) nunca precisa saber qual serviço está sendo usado. Eles trabalham apenas com esse "contrato".
2. A Implementação: MailtrapProvider como Adapter
Cada serviço de e-mail tem sua própria forma de trabalhar (API REST, SDK proprietário, SMTP). O Adapter Pattern resolve isso criando uma "tradução" entre a interface comum e a implementação específica.
Veja como ficou o adapter do Mailtrap:
@Injectable()
export class MailtrapProvider implements NotificationProvider {
private transporter: nodemailer.Transporter;
constructor(private configService: ConfigService) {
this.transporter = nodemailer.createTransport({
host: this.configService.get<string>('MAILTRAP_HOST'),
port: this.configService.get<number>('MAILTRAP_PORT'),
auth: {
user: this.configService.get<string>('MAILTRAP_USER'),
pass: this.configService.get<string>('MAILTRAP_PASS'),
},
});
}
async send(to: string, content: string): Promise<void> {
// A "tradução" acontece aqui
await this.transporter.sendMail({
from: '[email protected]',
to,
subject: 'Notification from Nexus',
text: content,
html: `<p>${content}</p>`,
});
}
}
Aqui está a mágica: toda a complexidade do nodemailer e a configuração do Mailtrap ficam encapsuladas. Se amanhã eu quiser trocar para SendGrid, crio um SendGridProvider que implementa a mesma interface, mas internamente faz chamadas HTTP. O resto do sistema nem percebe a diferença.
3. O Factory: Centralizando a Decisão
O Factory Pattern entra para centralizar a lógica de "qual provedor usar", evitando if/else espalhados pelo código:
@Injectable()
export class NotificationFactory {
constructor(private mailtrapProvider: MailtrapProvider) {}
getProvider(type: 'email'): NotificationProvider {
switch (type) {
case 'email':
return this.mailtrapProvider;
default:
throw new Error(`Unsupported notification type: ${type}`);
}
}
}
O Factory recebe os providers via Injeção de Dependência do NestJS. Para adicionar um novo provider, basta:
- Criar a classe do Adapter.
- Injetar no Factory.
- Adicionar um
caseno switch.
4. O Controller: Trabalhando com Abstrações
No Controller, vemos o poder do desacoplamento. Ele não sabe nada sobre Mailtrap ou SendGrid:
@Controller('api/notifications')
export class NotificationsController {
constructor(private notificationFactory: NotificationFactory) {}
@Post()
async sendNotification(@Body() dto: SendNotificationDto) {
// O Controller pede um provedor genérico
const provider = this.notificationFactory.getProvider(dto.type);
// E executa a ação sem saber quem está enviando
await provider.send(dto.destination, dto.content);
return {
success: true,
message: `Notification sent via ${dto.type}`,
};
}
}
Nota arquitetural: Neste exemplo didático, o cliente define o tipo de notificação via DTO. Em um cenário de produção real, essa decisão poderia ser tomada automaticamente pelo backend (usando regras de failover ou custo), mantendo o cliente agnóstico quanto ao provedor.
5. A Cola: Injeção de Dependência (NestJS)
O NestJS gerencia o ciclo de vida e a injeção dessas classes através do Módulo:
@Module({
controllers: [NotificationsController],
providers: [NotificationFactory, MailtrapProvider],
})
export class NotificationsModule {}
Vendo na Prática
Abaixo, uma rápida demonstração do fluxo completo: a aplicação frontend (React) enviando uma requisição para o backend (NestJS), que utiliza o Adapter do Mailtrap para realizar o envio.
Escalabilidade na Prática
Para provar a eficiência, vamos supor que precisamos adicionar o SendGrid agora. Quantos arquivos eu preciso tocar?
Criar o Adapter (sendgrid.provider.ts): ImplementaNotificationProvider.
Atualizar o Factory: Adiciona o novo provider no construtor e no switch.
Atualizar o Módulo: AdicionaSendGridProviderna lista de providers.
Resultado: O Controller permanece intocado. A lógica de negócio permanece intocada. Os testes existentes continuam passando.
Bônus: DTOs Compartilhados (Nx Monorepo)
Lembra do contrato que falei no início? Como estamos usando Nx, levei esse conceito também para a comunicação entre Frontend e Backend.
Criei uma biblioteca compartilhada para os DTOs. Isso garante que o Frontend (React) e o Backend (NestJS) falem exatamente a mesma língua.
// libs/shared-dtos/src/lib/dtos/send-notification.dto.ts
export class SendNotificationDto {
@IsEnum(['email'])
@IsNotEmpty()
type!: 'email';
@IsString()
@IsNotEmpty()
destination!: string;
// ... outros campos
}
Se eu altero o contrato aqui, o build do Frontend e do Backend falha na hora, garantindo consistência total e evitando aqueles bugs silenciosos de integração.
Conclusão: A Liberdade da Abstração
O Nexus Notification Hub é a resposta técnica para o impasse de negócios que vivi anos atrás. Aquele problema de "meses de refatoração", que travou a decisão da empresa, se transformou em uma tarefa de, no máximo, algumas horas.
A grande lição aqui não é apenas sobre usar NestJS ou decorar o Adapter Pattern. É sobre estratégia: preparar o terreno para um futuro onde tudo pode mudar e a escalabilidade é inegociável.
Naquela época, ficamos reféns do SendGrid não porque ele era insubstituível, mas porque nosso código dizia que ele era. Com essa nova arquitetura baseada em abstrações, o poder de decisão volta para as mãos dos times de engenharia e produto.
Se hoje chegasse aquele mesmo épico de aumentar o volume para 250.000 envios trocando de fornecedor, a resposta não seria mais "não dá, é muito caro refatorar". A resposta seria: "Claro, me dê uma tarde para implementar o novo Adapter".
Entendo hoje que essa é a diferença entre apenas escrever código e entregar uma solução escalável.
Código Fonte
O projeto completo, incluindo a configuração do Monorepo Nx, o frontend em React e todos os testes, está disponível no GitHub. Fique à vontade para clonar, testar e usar como base para seus projetos.