Desacoplar Efeitos do Código Principal com Eventos no NestJS

[@ozielsenior5310]

Que aula massa... Estou 1% melhor todo dia Hehehe Parabéns e continua com o ótimo trabalho

[@PhillCode]

Fala Oziel, que comentário top! Que bom que o conteúdo está ajudando. Bora continuar evoluindo! 🚀🚀🚀

[@gabrielcardosogirarde7515]

Que vídeo incrível! Estava lendo a documentação do NestJS e descobri que esse pacote cqrs vem com uma classe AggregateRoot que já encapsula a lógica de envio de eventos internamente pelos nossos agregados.

[@PhillCode]

Fala aí, Gabriel, tudo certo? Pois é, vivendo e aprendendo. Confesso que ainda não tinha usado essa classe AggregateRoot, mas vou dar uma conferida. Valeu pela dica!

[@PabloSilva-np3rj]

como eu nunca tinha visto esse canal antes. merece muito mais relevância!

[@PhillCode]

Opaaa, valeu demais, Pablo! O canal é novo, e faço os vídeos no meu tempo livre, que não é muito, rs... mas fico feliz demais de saber que está sendo relevante pro pessoal. Agradeço demais se puder dar uma força divulgando.

[@erisvaldo777]

VC DEVERIA TER MILHOES DE SEGUIDORES!!!! SIMPLES, DIRETO AO PONTO!

[@PhillCode]

Opaaa, fala aí Erisvaldo! Pô, obrigado, meu caro! Com 1 like e 1 comentário por vez a gente chega lá, hehe, obrigado pela força!

[@cleyton1986]

Muuuuito bom... Parabéns, ficou muito boa a aula.

[@djaircostatech]

Parabens pelo conteudo top demais....tbm estou no aguardo do curso NestJS

[@PhillCode]

Opaa, bom demais! A galera está agitando pra ter um curso. Olha que hora ou outra vou fazer mesmo. Obrigado pelo apoio.

[@djaircostatech]

@@PhillCode Demorou mestre...estou no aguardo

[@EduardoSales369]

Parabéns pelo conteúdo, muito bom! A fim de simplificar a questão dos eventos, gostaria de deixar uma sugestão. Aplicar o conceito de Observable, trabalhando com os Entity Listeners and Subscribers do TypeORM. O que acha?

[@PhillCode]

Fala Eduardo, obrigado :) se entendi corretamente, você está propondo usar tipo @AfterInsert, @AfterUpdate ou o que for mais apropriado pra lançar automaticamente os eventos, certo? Faz sentido sim, é um caminho interessante, pensando em criar uma classe base Entity e disparar os eventos a partir de lá. Me confirma aí pf, mas legal, anotado!

[@josephklimber195]

Cara, faz um curso de NestJs e coloca no Udemy, vo ser o primeiro a comprar, sua didatica é muito boa.

[@PhillCode]

"Mas a vida é uma caixinha de surpresas" 😅 "Joseph Klimber" é um nome bom hein! Haha, gostei da referência. Então Joseph, em breve penso mesmo em fazer uns cursos. Ainda não tenho experiência com isso, então vou fazer mais alguns vídeos pra melhorar o meu processo; depois vou fazer algum curso pequeno e simples pra começar, e daí a coisa vai crescendo né... mas obrigado pelo incentivo!

[@viniciusrocha5762]

Boa tarde Phill, cara, conteúdo sensacional. Mas fiquei na dúvida, entendi o conceito de disparar os eventos e etc. Mas na prática qual seria a mudança disso em comparação de só fazer uma função que manda o email depois que a outra função é concluída?

[@PhillCode]

Fala Vinicius, tudo bem? Ótima pergunta, vamos lá. Quando você chama diretamente uma função de envio de e-mail dentro da conclusão de compra, essas duas operações ficam fortemente acopladas. Qualquer mudança na lógica do envio de e-mail pode afetar diretamente a lógica de compra. Na minha experiência, vi vários códigos quebrarem por causa de funções chamadas uma dentro da outra. 1) Desacoplamento. Com eventos, a lógica de compra é desacoplada da lógica de envio de e-mail. A parte de compras dispara um evento de "compra concluída" e não se preocupa com o que acontece depois. Outros componentes, como o serviço de e-mail, podem se inscrever para esse evento e executar suas tarefas quando ele ocorrer. 2) Extensibilidade. Novos handlers podem ser adicionados para o evento "compra concluída" sem você ter que pôr a mão no código original de conclusão de compra. Isso facilita a escalabilidade do sistema. Segue o princípio Open Closed, que é fechado para modificação e aberto para extensão. 3) Rastreabilidade. Fica bem fácil você saber quais são os eventos relevantes para o seu negócio e quais são as ações "penduradas" em cada um desses eventos. Tipo, "o que acontece quando o cara fecha a compra?", respondendo rapidamente "manda email, tenta o pagamento, notifica o vendedor para embalar os produtos, adiciona pontos de fidelidade para o comprador", tudo isso como handlers distintos. 4) Escalabilidade com processamento em segundo plano. Nesse vídeo eu dei a base para o próximo vídeo, que foi sobre filas e processamento em segundo plano. Isso é top, porque aí você desvincula completamente a ação secundária (envio de email) do código principal. No caso do Bull, quando uma tarefa é enfileirada, ela é armazenada no Redis até que um worker esteja disponível pra dar conta dela. Os workers são processos NodeJS separados que se conectam ao Redis e ficam "ouvindo" por novas tarefas na fila. Quando uma tarefa é encontrada, o worker processa. E qual a relevância disso? Se o envio de email falha, ele não impacta o processo principal (de compra), pode ser retentado várias vezes... é uma maravilha. Espero ter respondido, mas qq dúvida manda ae.

[@viniciusrocha5762]

@@PhillCode Bom dia Phill, beleza? Cara, show de explicação. Agora sim entendi os benefícios disso, valeu pela atenção em explicar em detalhes como isso funciona. Obrigado!

[@KuroManX]

Eu poderia fazer com interceptors também?

[@PhillCode]

Opa, tudo bem? Ótima pergunta. É possível fazer usando interceptors sim, mas eu não recomendo, pelas seguintes questões: 1) Responsabilidade. A principal finalidade é modificar ou monitorar chamadas e retornos de funções, e não pra lidar com lógica de negócios ou efeitos colaterais complexos e coisas que poderiam/deveriam ser executadas em em segundo plano, como o envio de e-mails após uma compra. 2) Escalabilidade. O uso de interceptors pra esse fim não é escalável. Se o envio de e-mails falhar, a lógica de reenvio e gerenciamento de falhas fica complicada. Se você leva isso pra uma fila, você ganha retentativas e outras mecânicas de graça, sem ter que escrever código adicional. O uso ideal dos interceptors é para coisas como: * Logging: Você captura os detalhes da requisição e da resposta, registra tempo de execução, parâmetros de entrada e saída, status, etc. * Padronização de respostas: Você pode interceptar os retornos pra garantir que todos sigam um mesmo padrão/formato. * Tratamento de erros: Aqui você pode padronizar o formato de retorno especificamente pra erros, além de poder incluir lógica de retry automático. Espero ter conseguido clarear a questão, mas qq dúvida manda ae!

[@KuroManX]

@@PhillCode sensacional, entendi sim

[@dodijacobs]

Phill, pra ficar ainda mais "transparente", ao invés de publicar os eventos no CommandHandler, nao seria possível ter um afterSave no EntityBase que publicaria os eventos automaticamente?

[@dodijacobs]

Não tinha olhado o video até o fim, pode desconsiderar o comentário