WEBVTT 00:00.350 --> 00:06.680 Okay, So next up, we're going to look at using Rabbitmq as our transport mechanism to communicate 00:06.680 --> 00:08.540 between our microservices. 00:08.570 --> 00:13.730 Now, of course, right now we know that we're using the TCP transport mechanism. 00:13.940 --> 00:20.330 However, there are also some downsides to using the TCP transport opposed to an asynchronous messaging 00:20.360 --> 00:22.430 transport like Rabbitmq. 00:22.790 --> 00:30.410 Now, to actually show the disadvantage of using the TCP microservice, let's go to the payments microservice 00:30.410 --> 00:37.190 and in the payments controller, when we receive the request to create a chards, let's immediately 00:37.190 --> 00:43.610 throw a dummy error here so that we will always throw an error and never actually create the charge. 00:43.610 --> 00:48.790 And then let's go ahead and open up Postman to create a reservation to see what happens. 00:48.800 --> 00:55.730 So in Postman, I'll launch a request at the auth slash login root first with a created user to obtain 00:55.730 --> 01:03.570 a JWT and then we'll go ahead and execute an a request to create a reservation. 01:03.570 --> 01:07.240 So this is the typical payload that we would have to create a reservation. 01:07.260 --> 01:13.350 Now, of course, we're getting back a 500 internal server error because when the reservations microservice 01:13.350 --> 01:20.700 tried to reach out to the payment service, we can see that it threw an error here and the reservation 01:20.700 --> 01:22.230 service immediately failed. 01:22.230 --> 01:25.640 So this is showing the problem with the TCP microservice. 01:25.650 --> 01:32.160 There's no way to retry any sort of failed messages in our system, and our messages can't be queued 01:32.160 --> 01:33.870 up one behind one another. 01:33.870 --> 01:40.440 So if we have a massive influx of messages into our system, our system can become overloaded and we 01:40.440 --> 01:41.910 can't respond gracefully. 01:41.910 --> 01:47.880 If we need to retry a message, we immediately throw this error and then this payments request is never 01:47.880 --> 01:51.480 retried because there's nowhere to actually save that message. 01:51.480 --> 01:58.470 Now, using an asynchronous microservice like Rabbitmq, we have the idea of a queue that is introduced 01:58.470 --> 02:02.670 so a queue will hold our messages until they're ready to be processed. 02:02.670 --> 02:06.630 So if there's a large backlog of messages, we can handle them one at a time. 02:06.630 --> 02:12.060 And additionally, if we fail to process a message, we can put it back on the queue and keep trying 02:12.060 --> 02:17.670 until potentially this error is resolved and we don't actually lose that message. 02:17.670 --> 02:20.640 So that's the big difference with something like Rabbitmq. 02:20.850 --> 02:26.340 Let's go ahead and implement it now to see how we can take advantage of these asynchronous benefits. 02:26.340 --> 02:33.060 So as I've done in previous lectures, we're going to have the completed portion of this in a new branch 02:33.060 --> 02:34.230 called Rabbitmq. 02:34.500 --> 02:39.990 So if you want to see the completed code in Rabbitmq, you can just check out this branch and follow 02:39.990 --> 02:41.010 along there. 02:41.100 --> 02:46.920 I'll be working off of the main branch to start and we can integrate Rabbitmq off of the main branch. 02:46.920 --> 02:50.160 Firstly, we're going to go ahead and install some new dependencies. 02:50.160 --> 03:00.000 So let's go ahead and NPM install amp, shp lib and then amp shp connection manager. 03:02.380 --> 03:09.460 Now, since we're using Nestjs microservice library, it's going to be very easy to swap out our transport 03:09.460 --> 03:14.260 layer without having to change any of our underlying code, which is going to be great. 03:14.290 --> 03:20.560 So let's start off by going to our Docker compose where we can define a new service to actually run 03:20.560 --> 03:25.270 a rabbitmq cluster that we can connect to from our application. 03:25.270 --> 03:31.480 So let's go ahead and define a new Rabbitmq service underneath our Mongo service. 03:31.480 --> 03:38.500 And this will be the image of Rabbitmq, which is going to be the official Rabbitmq image from Docker 03:38.500 --> 03:39.070 Hub. 03:39.370 --> 03:46.840 And then for the ports, we're going to expose the default port on Rabbitmq five, six, seven two on 03:46.840 --> 03:50.070 our local host machine of 5672. 03:50.080 --> 03:55.930 So now when we start up our Docker compose, we will start up this rabbitmq image that we can connect 03:55.930 --> 03:56.440 to. 03:56.470 --> 04:00.400 Let's go ahead and get started with our auth microservice. 04:00.400 --> 04:02.840 That will change over to Rabbitmq. 04:03.110 --> 04:10.250 We'll open up the Main.ts in the auth service and we'll go ahead and change the transport out for our 04:10.310 --> 04:11.250 MQ. 04:11.270 --> 04:14.210 And now we need to specify a new set of options. 04:14.210 --> 04:21.320 So instead of a host and port, we're now going to provide an array of URLs which is going to be the 04:21.320 --> 04:23.570 different brokers that we want to connect to. 04:23.660 --> 04:31.730 In our case we only have one, so we will use the config service to get or throw, which will throw 04:31.730 --> 04:38.390 an error if this environment variable is not found and we will look for the rabbitmq Uri. 04:38.600 --> 04:40.880 So this is the connection string. 04:40.880 --> 04:46.700 And then we need to specify the actual name of the queue that we're going to be using in this service 04:46.700 --> 04:49.760 and then others will be able to produce messages too. 04:49.790 --> 04:54.950 So this queue is where the messages will go to to be consumed from in this service. 04:54.950 --> 05:00.320 And if any messages need to be retried, they will be put back on this queue. 05:00.440 --> 05:05.000 So let's go ahead and specify the name of auth to specify the auth queue. 05:05.000 --> 05:11.420 Next up, we can update our dot m file in the auth service to have this new Rabbitmq Uri. 05:11.660 --> 05:15.190 So let's go ahead and add it underneath our MongoDB Uri. 05:15.470 --> 05:26.900 We'll add the Rabbitmq Uri which will be equal to Amqp colon slash slash Rabbitmq the name of our Docker 05:26.900 --> 05:28.310 compose service. 05:28.520 --> 05:31.520 And then the port of five, 672. 05:32.620 --> 05:39.640 And that's all we have to do to switch out for Rabbitmq In our auth controller, we still use the same 05:39.640 --> 05:47.130 decorators to extract data because of this platform agnostic way that Nestjs implements its microservices. 05:47.140 --> 05:49.550 This will still work just as it did before. 05:49.570 --> 05:57.220 Next up, let's go to the notification Service where we can refactor the main.ts in the same way we 05:57.220 --> 06:05.710 can actually just copy out this options from connect microservice in auth and in the Notification service. 06:05.710 --> 06:12.370 We'll paste this in, we'll change out the name to notifications instead. 06:13.740 --> 06:19.530 Well then go ahead and update the env as well to have that rabbitmq uri. 06:19.560 --> 06:24.570 So let's go ahead and just copy it over from the dot env and auth. 06:25.620 --> 06:30.840 Next up we'll go into our payment service and do the same thing there. 06:31.260 --> 06:37.350 So we'll copy the options from connect Microservice and swap it out in the main.ts. 06:37.380 --> 06:45.630 We'll call this queue the payment queue and then in our dot env we will provide the Rabbitmq connection 06:45.630 --> 06:49.470 string, which again I'll copy over and paste it in. 06:49.530 --> 06:55.260 Now in the payment service we also have to go back into the payments module where we're registering 06:55.260 --> 06:58.890 our clients module to connect to the notification service. 06:58.920 --> 07:05.580 We have to specify that the transport layer has changed to MQ and then we need to specify the options 07:05.580 --> 07:08.970 here to connect to the notification service. 07:08.970 --> 07:12.100 So this will be the just the same as the Main.ts. 07:12.120 --> 07:20.140 So let's go ahead into our notifications Main.ts and copy these options where we get the Rabbitmq connection 07:20.140 --> 07:23.260 string and the name of the queue that we want to produce to. 07:23.290 --> 07:29.800 So in this case we know it's notifications and then we'll provide a type to our config service here 07:29.800 --> 07:32.110 to make the type happy. 07:32.260 --> 07:40.720 And now all that's left is to go to the reservation service and update our reservations module client 07:40.720 --> 07:45.220 modules where we're registering the auth service and the payments service. 07:45.490 --> 07:50.860 We're going to go ahead and change out the transport layer as we've done before and then we'll paste 07:50.860 --> 07:56.410 in our familiar options to connect to the Rabbitmq cluster and the queue name. 07:56.410 --> 08:00.430 So the queue name here will be auth and we'll provide that. 08:00.430 --> 08:05.270 This is a string and let's go ahead and do the same thing for payments. 08:05.290 --> 08:06.880 This is very easy to do. 08:06.910 --> 08:15.880 Rabbitmq Paste in our options, change this to a string and make sure our queue name is payments. 08:16.390 --> 08:24.430 Now lastly, we also have to add the Rabbitmq Uri to our EMF file in the reservation service. 08:24.430 --> 08:29.920 So let's go ahead and copy one of our existing ones and paste it in so that our reservation service 08:29.920 --> 08:32.530 can connect to the Rabbitmq cluster. 08:33.010 --> 08:38.680 So now, without having to change any of our underlying code, we already have moved all of our services 08:38.680 --> 08:40.390 over to Rabbitmq. 08:40.630 --> 08:46.180 We're producing messages to rabbitmq queues that will be consumed and we don't have to do anything else. 08:46.180 --> 08:49.420 So let's go ahead and rerun our project. 08:49.420 --> 08:57.670 So in order for our images to download the latest Rabbitmq dependencies, we can run Docker, compose 08:58.090 --> 09:04.750 up and make sure you run dash, dash, build so that your images get rebuilt with the new dependencies 09:04.750 --> 09:05.710 required. 09:06.190 --> 09:10.690 So once your images have rebuilt, you can see that our containers are starting up. 09:10.690 --> 09:17.380 And importantly, we have the rabbitmq image that has also started and is listening for TCP connections 09:17.380 --> 09:19.180 and 5672.