WEBVTT 00:00.380 --> 00:00.800 All right. 00:00.800 --> 00:08.000 So in this lecture I want to show you how we can actually connect a debugger to our running microservices 00:08.000 --> 00:16.490 in Docker so that when we send a request to our microservices, we can actually debug it and see our 00:16.490 --> 00:23.780 defined variables and our control flow as the request actually enters our Http server. 00:23.780 --> 00:29.300 This can be super useful when debugging and trying to find out what our code is actually doing. 00:29.300 --> 00:32.930 And it's going to be super easy to debug with Nestjs. 00:32.930 --> 00:40.340 So let's get started by firstly going into our package.json where we need to update our scripts. 00:40.340 --> 00:45.500 So right now you can see we actually already have a command to start in debug mode. 00:45.500 --> 00:47.270 So this is start debug. 00:47.270 --> 00:50.660 And this is just going to use the nest CLI to start the app. 00:50.660 --> 00:52.100 Still with the watch flag. 00:52.100 --> 00:55.430 So we can make changes but also with this debug flag. 00:55.430 --> 00:59.450 So the debug flag allows us to actually enter debug mode. 00:59.450 --> 01:05.240 And specify an address where we want to listen for debug requests. 01:05.240 --> 01:09.410 So in our case I want to go ahead and specify this address. 01:09.410 --> 01:12.710 So the IP is going to be 0000. 01:12.710 --> 01:17.630 So that we attach to all network interfaces running. 01:17.630 --> 01:21.170 Well in our case we know our app is running inside of a Docker container. 01:21.170 --> 01:24.920 So we want to listen on all IP addresses in that container. 01:24.920 --> 01:32.510 And we want to specifically then listen on port 9229 which is going to be the debugging port we're going 01:32.510 --> 01:33.470 to use. 01:33.620 --> 01:36.290 So now we've specified the debug command. 01:36.290 --> 01:39.290 We now need to go into our Docker compose. 01:39.290 --> 01:47.210 And now we need to actually change the command that our services are using to actually start up the 01:47.210 --> 01:47.960 application. 01:47.960 --> 01:53.810 As of right now we're simply running the start dev command, which we know just starts up the dev server. 01:53.810 --> 01:57.050 However, we want to start it up in this debug mode. 01:57.050 --> 02:02.300 So we simply are going to change start dev to start debug. 02:03.190 --> 02:06.130 And that's all we'll have to do to actually start up. 02:06.130 --> 02:14.710 Then we'll also want to add our new port of 9229, so that it's actually exposed for traffic on our 02:14.710 --> 02:21.070 Docker container and importantly, is mapped to our local machine's port of 9229. 02:21.070 --> 02:27.160 So the Docker container is going to map this port that's running in the container to our local machine, 02:27.160 --> 02:34.180 so that we can send requests to localhost 9229 and have them forwarded into the actual container, which 02:34.180 --> 02:37.510 we know is listening for requests to debug. 02:37.510 --> 02:42.760 So our final step is to actually create what's called a launch configuration. 02:42.760 --> 02:50.620 So in VS code I'm going to create a launch dot Json file by first clicking on Run and Debug. 02:50.620 --> 02:54.640 And then you can see here we have a created launch Json file. 02:54.640 --> 02:58.120 Then we'll select the suggested runtime in our case NodeJS. 02:58.120 --> 03:01.510 So it creates a default launch Json for us. 03:01.510 --> 03:07.720 So this is going to create a new VS code folder and include this launch Json inside of it. 03:08.020 --> 03:10.510 So let's go ahead and start updating this. 03:10.510 --> 03:17.470 This is essentially going to be the configuration that VS code is going to use when we enter debug mode. 03:17.470 --> 03:24.850 So we need to update this actual configuration to specify our specific application information. 03:24.850 --> 03:26.860 So we can leave the default type. 03:26.860 --> 03:33.910 Here we're going to change request to actually attach to an already running application. 03:33.910 --> 03:40.540 Then for the name I'll give it a name of debug NodeJS Docker. 03:41.380 --> 03:44.590 Then let's go ahead and get rid of these two extra properties. 03:44.590 --> 03:50.680 And next we'll add the actual address that we want to debug on. 03:50.680 --> 03:53.470 In our case we know it's just going to be localhost. 03:53.470 --> 03:56.740 And then importantly the port needs to be 9229. 03:56.740 --> 04:02.200 Since this is the port that we're actually mapping to our running container. 04:02.200 --> 04:04.870 So that's going to get forwarded into the container. 04:04.870 --> 04:08.920 We'll also include source maps to true. 04:08.920 --> 04:10.480 So we have source maps. 04:10.480 --> 04:13.840 We'll set restart to true as well. 04:13.840 --> 04:22.150 And then we need to specify the local route which is going to be quote dollar sign bracket workspace 04:22.150 --> 04:23.920 folder bracket. 04:23.920 --> 04:31.840 So this is a special variable we can use in our Launch.json to actually specify the current workspace 04:31.840 --> 04:38.260 folder for the project, which is at the default is just going to be the root of our VS code project. 04:38.320 --> 04:43.570 Now the final property we need that works with local root is the remote route. 04:43.570 --> 04:47.950 So this is the path locally on our file system where our code lives. 04:47.950 --> 04:51.760 In our case it's just at this route where the launch.json actually lives. 04:51.760 --> 04:53.740 So that's easy enough to specify. 04:53.740 --> 05:00.610 However, on the remote route, we need to map this workspace folder to where it lives on the host machine. 05:00.610 --> 05:07.810 So in our case, we know that by looking at one of our Docker files for the application we're debugging. 05:08.140 --> 05:15.100 Remember where we're actually hosting our app on the file system is in this user source app directory. 05:15.100 --> 05:18.370 So this is where the app is actually going to get placed. 05:18.370 --> 05:22.240 And that's exactly where we need to tell remote route where the app lives. 05:22.240 --> 05:30.100 So its user source app so that we can map the code on our local machine to the running container. 05:30.100 --> 05:36.670 Now before we run in debug, we of course need to make sure that our containers are up and running. 05:36.670 --> 05:40.150 So go ahead and run docker compose up to start everything up. 05:40.780 --> 05:46.750 All right, so once all of our services have started up we'll then go back to VS code and click on Run 05:46.750 --> 05:47.620 and Debug. 05:47.620 --> 05:53.740 And now you can see we actually have our debug configuration defined in this top bar. 05:53.740 --> 05:59.200 So you can add many more configurations easily by clicking add here if you want to add more for different 05:59.200 --> 06:00.250 runtimes. 06:00.720 --> 06:05.850 Let's choose the custom one we've created, and then go ahead and click on the play button. 06:05.850 --> 06:14.550 So this is going to attach our debugger to localhost 9229, which is going to be mapped to the Docker 06:14.550 --> 06:21.030 container that's actually running and can accept debug requests since we told Nestjs about it. 06:21.030 --> 06:28.200 So now if we go back to our application logs, we can actually see that our logs for our reservation 06:28.200 --> 06:30.660 service, the debugger was attached. 06:30.840 --> 06:33.990 So we actually have attached to the service correctly. 06:33.990 --> 06:41.760 Now I'm going to go back to our reservation service and let's open up the reservations controller. 06:41.760 --> 06:49.260 And I'll simply place a breakpoint by clicking on this red dot here on the create route to create a 06:49.260 --> 06:50.520 new reservation. 06:50.820 --> 06:57.090 Now in postman, I'll go ahead and send a request to our reservation service, and immediately you can 06:57.090 --> 07:03.390 see VSCode has opened back up and our code is actually stopped now on this breakpoint. 07:03.390 --> 07:07.020 So we can actually control the execution of the request. 07:07.020 --> 07:11.370 And importantly, we can actually see here this variable section. 07:11.370 --> 07:17.190 So we can see what each variable is actually defined as as it's coming into our system. 07:17.190 --> 07:24.570 So we can see our create reservation DTO with all of our DTO information on it, as well as our user 07:24.570 --> 07:28.230 for this particular request on our decoded token. 07:28.230 --> 07:29.910 So this is super helpful. 07:29.910 --> 07:37.110 We can then follow the request down into the reservation service by adding another breakpoint and then 07:37.110 --> 07:39.690 clicking on the continue button. 07:39.690 --> 07:42.960 So now you can actually see how the code is running. 07:42.960 --> 07:50.010 And I'll set one more breakpoint inside of our map here in our pipe, where we actually get the response 07:50.010 --> 07:53.430 back from the payment service. 07:53.430 --> 07:58.470 So after we send the request back, we'll see that map gets executed with the response. 07:58.470 --> 08:00.900 So I'll click on continue one more time. 08:02.830 --> 08:09.400 And now you can see we are in the map lock, with the response coming back from the payment service 08:09.400 --> 08:12.070 so we can actually see the entire payments object. 08:12.070 --> 08:16.510 We're getting back from the stripe API which is excellent. 08:16.510 --> 08:22.000 So this is super helpful when trying to debug issues with our app or in general, just try to see the 08:22.000 --> 08:26.230 state of an application for a given request at any time.