feat: implementing kafka to comunicate between services

Rodrigo001-dev · Rodrigo001-dev · commit 2049fe42a4c2 · 2022-12-18T12:05:15.000-03:00
diff --git a/README.md b/README.md
@@ -11,9 +11,10 @@ básicamente é um serviço de notificações totalmente criado com Node e o Fra
 Fala Dev!
 
 Que evento incrível 🚀🚀
+
 Mais uma vez queria agradecer a Rocketseat por sempre estar se superando e melhorando para trazer conteúdos relevantes e atualizados, e também queria agradecer o Diego pela sua metodologia incrível!!
 
-Depois das 3 aulas tivemos a live After Ignite Lab qua faz o encerramento do evento e implementa o Kafka.
+Depois das aulas tivemos a live que faz o encerramento do evento e implementa o Kafka.
 
 Mas o que é o Kafka?
 
@@ -23,11 +24,7 @@ Mas por que utilizar o Kafka?
 
 Pense na seguinte situação:
 
-Nós temos 2 microsserviços, um para receber as compras do usuário e esse serviço vai ter um banco de dados próprio que vai armazenar os dados de compra e imaginem que temos um outro microsserviço para emissão de nota fiscal eletrônica.
-
-No Frontend da aplicação, quando a pessoa vai realizar uma compra não faz sentido
-o Front ter que fazer a requisição para os dois serviços, porque principalmente a emissão da nota fiscal eletrônica não pode ser feita antes da compra ser efetuada, pois no serviço de compra: a compra vai ser processada, vai validar os dados de pagamento e depois de tudo isso vai emitir a nota fiscal eletrônica, ou seja, a nota fiscal é uma consequência da compra. A ideia que temos dentro de microsserviços é que eles se intercomunicam.
-Então quando o usuário faz a compra, depois que a compra foi processada, o serviço de compras avisa o serviço de nota fiscal que houve uma nova compra, o serviço de nota fiscal gera a nota fiscal(PDF por exemplo) e envia isso por email para o usuário.
+Nós temos 2 microsserviços, um para receber as compras do usuário e esse serviço vai ter um banco de dados próprio que vai armazenar os dados de compra e imaginem que temos um outro microsserviço para emissão de nota fiscal eletrônica. Então quando o usuário faz a compra, depois que a compra foi processada, o serviço de compras avisa o serviço de nota fiscal que houve uma nova compra, o serviço de nota fiscal gera a nota fiscal e envia isso por email para o usuário.
 
 Os serviços são totalmente independentes, ou seja, um não depende do outro para funcionar se por algum motivo o serviço de nota fiscal estiver fora do ar, o serviço de compras não vai ser afetado.
 
@@ -37,25 +34,15 @@ Mas o que aconteceria se o serviço de nota fiscal estiver fora do ar?
 
 Producers(Produtores): é todo mundo que envia eventos, ou seja, pegando o exemplo acima o producer vai ser o serviço de compras.
 
-Consumers(Consumidores): é todo mundo que recebe(consome) eventos, ou seja, pegando o exemplo acima o consumer vai ser o serviço de nota fiscal eletrônica.
+Consumers(Consumidores): é todo mundo que consome eventos, ou seja, pegando o exemplo acima o consumer vai ser o serviço de nota fiscal eletrônica.
 
 Topics: os tópicos são os tipos de mensagem que podemos transitar entre os dois lados(producers e consumers).
 
-Toda vez que o serviço de compras for enviar uma mensagem para o serviço de nota fiscal eletrônica, ele precisa dizer qual o tópico que está sendo enviado, nesse caso temos apenas um único tópico, um único evento que é o de compra, ou seja, toda vez que ouver uma compra o serviço de compras vai enviar um evento para o tópico chamado compra e o tópico no Kafka funciona como um banco de dados, cada tópico no Kafka é como se fosse uma tabela.
-
-Quando o serviço de compras chama o tópico de compra, envia um evento informando a nova compra, ele vai enviar junto todas as informações daquela compra e o kafka armazena essas informações dentro de um banco de dados próprio, onde cada tabela é como se fosse um tópico.
-
-A ideia dos consumers como o próprio nome já diz é ao invés do kafka avisar que houve uma nova compra para os consumers, como o nome deles já diz, eles são consumidores, ou seja, o caminho é inverso cada consumer busca em tempo real do kafka as novas mensagens.
+Toda vez que o serviço de compras for enviar uma mensagem para o serviço de nota fiscal eletrônica, ele precisa dizer qual o tópico que está sendo enviado, nesse caso temos apenas um único tópico, que é o de compra, ou seja, toda vez que ouver uma compra o serviço de compras vai enviar um evento para o tópico chamado compra informando a nova compra, ele vai enviar junto todas as informações daquela compra e o tópico no Kafka funciona como um banco de dados, cada tópico no Kafka é como se fosse uma tabela.
 
 Mas o que ganhamos com isso?
 
-Se por algum motivo quando houve uma nova compra o serviço de nota fiscal estiver fora do ar, no modelo onde o kafka avisaria esse serviço ele teria um erro, quando temos o comportamento de pulling, ou seja, o consumer buscar a informação ao invés de push onde a informação é enviada para o consumer, nos ganhamos muito mais tolerância a falha, porque se o serviço de nota fiscal estiver fora do ar os outros serviços(consumers) vão conseguir tranquilamente buscar dados da compra, e quando o serviço de nota fiscal eletrônica voltar ao ar ele vai buscar todas as mensagens que ele não consumiu ainda.
-
-Mas como o serviço sabe quais as mensagens que ele não consumiu ainda?
-
-Quando criamos o consumer nos colocamos um ID, cada um dos consumers tem um ID e no Kafka fica salvo esses ID, basicamenta funcioanria assim:
-
-O ID do consumer de nota fiscal consumiu apenas até a mensagem 3, já algum outro consumer consumiu até a mensagem 5, quando o serviço de nota fiscal voltar ao ar ele vai no Kafka e o Kafka vai verificar quantas mensagens ele consumiu e se ele não consumiu alguma o Kafka vai devolver as mensagens não consumidas(nesse caso seria 2).
+Se por algum motivo quando houve uma nova compra o serviço de nota fiscal estiver fora do ar, no modelo onde o kafka avisaria esse serviço ele teria um erro, quando temos o comportamento de pulling, ou seja, o consumer buscar a informação ao invés de push onde a informação é enviada para o consumer, nos ganhamos muito mais tolerância a falha, porque se o serviço de nota fiscal estiver fora do ar os outros serviços(consumers) vão conseguir tranquilamente buscar dados da compra, e quando o serviço de nota fiscal voltar ao ar ele vai buscar todas as mensagens que ele não consumiu ainda.
 
 Existem vários outros conceitos quando falamos sobre escala com Kafka mas o core é isso.
 </LINKEDIN>
@@ -67,6 +54,7 @@ Existem vários outros conceitos quando falamos sobre escala com Kafka mas o cor
 <a href="https://docs.nestjs.com/" target="_blank"> <img src="https://img.shields.io/badge/-Nest.js-ED2945?style=flat-square&logo=Nestjs&logoColor=white" alt="Nest.js"> </a>
 <a href="https://jestjs.io/pt-BR/" target="_blank"> <img src="https://img.shields.io/badge/-Jest-FF7800?style=flat-square&logo=jest&logoColor=white" alt="Jest"> </a>
 <a href="https://kafka.apache.org/" target="_blank"> <img src="https://img.shields.io/badge/Apache%20Kafka-000?style=flat-square&logo=apachekafka&logoColor=white" alt="Kafka"> </a>
+<a href="https://upstash.com/" target="_blank"> <img src="https://img.shields.io/badge/-Upstash-00E9A3?style=flat-square&logo=upstash&logoColor=white" alt="Upstash"> </a>
 
 ## 💻 Autor
 
diff --git a/package.json b/package.json
@@ -28,6 +28,7 @@
     "@prisma/client": "^4.7.1",
     "class-transformer": "^0.5.1",
     "class-validator": "^0.14.0",
+    "kafkajs": "^2.2.3",
     "reflect-metadata": "^0.1.13",
     "rimraf": "^3.0.2",
     "rxjs": "^7.2.0"
diff --git a/prisma/dev.db b/prisma/dev.db
diff --git a/src/app.module.ts b/src/app.module.ts
@@ -1,9 +1,10 @@
 import { Module } from '@nestjs/common';
 
+import { MessagingModule } from '@infra/messaging/messaging.module';
 import { DatabaseModule } from './infra/database/database.module';
 import { HttpModule } from './infra/http/http.module';
 
 @Module({
-  imports: [HttpModule, DatabaseModule],
+  imports: [HttpModule, DatabaseModule, MessagingModule],
 })
 export class AppModule {}
diff --git a/src/infra/messaging/kafka/controllers/notifications.controller.ts b/src/infra/messaging/kafka/controllers/notifications.controller.ts
@@ -0,0 +1,22 @@
+import { Controller } from '@nestjs/common';
+import { EventPattern, Payload } from '@nestjs/microservices';
+
+import { SendNotification } from '@application/use-cases/send-notification';
+
+interface SendNotificationPayload {
+  content: string;
+  category: string;
+  recipientId: string;
+}
+
+@Controller()
+export class NotificationsController {
+  constructor(private sendNotification: SendNotification) {}
+
+  @EventPattern('notifications.send-notification')
+  async handleSendNotification(
+    @Payload() { content, category, recipientId }: SendNotificationPayload,
+  ) {
+    await this.sendNotification.execute({ content, category, recipientId });
+  }
+}
diff --git a/src/infra/messaging/kafka/kafka-consumer.service.ts b/src/infra/messaging/kafka/kafka-consumer.service.ts
@@ -0,0 +1,27 @@
+import { Injectable, OnModuleDestroy } from '@nestjs/common';
+import { ServerKafka } from '@nestjs/microservices';
+
+@Injectable()
+export class KafkaConsumerService
+  extends ServerKafka
+  implements OnModuleDestroy
+{
+  constructor() {
+    super({
+      client: {
+        clientId: 'notifications',
+        brokers: ['your_broker'],
+        sasl: {
+          mechanism: 'scram-sha-256',
+          username: 'your_username',
+          password: 'your_password',
+        },
+        ssl: true,
+      },
+    });
+  }
+
+  async onModuleDestroy() {
+    await this.close();
+  }
+}
diff --git a/src/infra/messaging/messaging.module.ts b/src/infra/messaging/messaging.module.ts
@@ -0,0 +1,13 @@
+import { Module } from '@nestjs/common';
+
+import { KafkaConsumerService } from './kafka/kafka-consumer.service';
+import { NotificationsController } from './kafka/controllers/notifications.controller';
+import { SendNotification } from '@application/use-cases/send-notification';
+import { DatabaseModule } from '@infra/database/database.module';
+
+@Module({
+  imports: [DatabaseModule],
+  providers: [KafkaConsumerService, SendNotification],
+  controllers: [NotificationsController],
+})
+export class MessagingModule {}
diff --git a/src/main.ts b/src/main.ts
@@ -1,13 +1,22 @@
 import { ValidationPipe } from '@nestjs/common';
 import { NestFactory } from '@nestjs/core';
+import { MicroserviceOptions } from '@nestjs/microservices';
 
+import { KafkaConsumerService } from '@infra/messaging/kafka/kafka-consumer.service';
 import { AppModule } from './app.module';
 
 async function bootstrap() {
   const app = await NestFactory.create(AppModule);
 
   app.useGlobalPipes(new ValidationPipe());
 
+  const kafkaConsumerService = app.get(KafkaConsumerService);
+
+  app.connectMicroservice<MicroserviceOptions>({
+    strategy: kafkaConsumerService,
+  });
+
+  await app.startAllMicroservices();
   await app.listen(3000);
 }
 
diff --git a/yarn.lock b/yarn.lock
@@ -3289,6 +3289,11 @@ jsonfile@^6.0.1:
   optionalDependencies:
     graceful-fs "^4.1.6"
 
+kafkajs@^2.2.3:
+  version "2.2.3"
+  resolved "https://registry.yarnpkg.com/kafkajs/-/kafkajs-2.2.3.tgz#a1ab1b7c4a27699871a89b3978b5cfe5b05c6f3e"
+  integrity sha512-JmzIiLHE/TdQ7b4I2B/DNMtfhTh66fmEaEg7gGkyQXBC6f1A7I2jSjeUsVIJfC8d9YcEIURyBjtOEKBO5OHVhg==
+
 kleur@^3.0.3:
   version "3.0.3"
   resolved "https://registry.yarnpkg.com/kleur/-/kleur-3.0.3.tgz#a79c9ecc86ee1ce3fa6206d1216c501f147fc07e"
