WEBVTT 00:00.080 --> 00:05.780 Okay, so now that we've generated the proto definitions for our services, let's go ahead and utilize 00:06.230 --> 00:08.540 Proto to generate the TypeScript code. 00:08.540 --> 00:11.930 We need to integrate it easily within our Nestjs app. 00:12.560 --> 00:21.140 So the command we'll run will be proto C dash dash plugin equal to and then we'll give it the path to 00:21.140 --> 00:21.800 our plugin. 00:21.800 --> 00:32.180 So this will be in node modules, slash bin slash proto c dash gen dash ts underscore proto. 00:32.420 --> 00:38.810 Then we'll specify where we want to generate the TypeScript code to by using the ts, underscore proto 00:38.840 --> 00:39.980 out option. 00:39.980 --> 00:43.760 And I'll just leave this equal to dot slash for the relative path. 00:44.330 --> 00:54.050 And then finally we'll use dash dash ts underscore proto underscore opt equal to nestjs equal to true, 00:54.050 --> 00:57.710 which is going to generate nestjs specific code for us. 00:57.740 --> 01:01.260 Now let's specify the path to our proto file. 01:01.500 --> 01:06.410 In this case it will be dot slash proto and then we'll start off with the auth dot Pro. 01:06.420 --> 01:14.070 Now let's go ahead and run the same command and just swap out the path for the payments proto now and 01:14.070 --> 01:18.210 finally we'll rerun it for the notifications proto. 01:18.990 --> 01:26.820 So now if we go back to our project and open up the proto folder, we can see we have three new definition. 01:27.180 --> 01:30.850 We have three new files created, one for each proto. 01:30.870 --> 01:34.650 And if we look inside, we can see all of the interfaces. 01:35.210 --> 01:40.550 And if we look inside, we can see all of this TypeScript code that has been generated for us based 01:40.550 --> 01:43.040 off of the proto file that we created. 01:43.800 --> 01:50.400 So in the arts we can see we have interfaces defined for each of the different message types that we 01:50.430 --> 01:52.380 created in our orthophoto. 01:52.500 --> 01:59.670 We also have interfaces for the client that will be calling our auth service and the controller that 01:59.670 --> 02:02.570 will actually be implementing the auth service. 02:02.580 --> 02:08.610 So this is going to make it very easy for us to write clean consistent code that is always in line with 02:08.610 --> 02:10.110 our proto definition. 02:10.350 --> 02:16.740 Now finally we have this function called auth service controller methods and this is actually a decorator 02:16.740 --> 02:23.730 that we're going to be able to apply to our auth controller and all of the necessary metadata is going 02:23.730 --> 02:30.360 to be automatically applied to our methods automatically so that when a message is sent to our service, 02:30.570 --> 02:34.980 Nestjs will automatically know which method it should be sent to. 02:34.980 --> 02:39.570 So this will all be taken care of for us under the hood thanks to Proto. 02:40.050 --> 02:44.680 So next up let's go to the libs Source comm and folder. 02:44.680 --> 02:48.820 And in here I want to create a new folder called Types. 02:48.820 --> 02:55.780 So I've created this new types folder and I want to move all of the newly generated types into this 02:55.780 --> 02:56.260 folder. 02:56.260 --> 03:00.220 So let's move each of these files into the types folder. 03:01.920 --> 03:10.350 And then we'll create an index.ts where we can export everything from each of these files so that we 03:10.350 --> 03:12.300 can use it in our application. 03:12.870 --> 03:14.730 So let's go ahead and do that. 03:22.340 --> 03:28.250 Now you'll notice the compiler is complaining because we have some duplicated exports coming from these 03:28.250 --> 03:29.120 files. 03:29.120 --> 03:34.080 And this is actually coming from this const called Protobuf package. 03:34.100 --> 03:39.020 Now, we're actually not going to be utilizing this constant in our app so we can just go ahead and 03:39.020 --> 03:40.760 delete this altogether. 03:40.940 --> 03:44.480 Let's go ahead and delete it from each definition. 03:48.160 --> 03:56.110 So now that we've done that, I'll go to the root index.ts and export everything from the types folder. 03:57.530 --> 04:03.230 Next, let's go to our DTO folder where we can open up our Create charge DTO. 04:04.090 --> 04:11.970 Now, you may have been wondering why we had to duplicate our message types in our gRPC proto definitions. 04:11.980 --> 04:20.080 For example, the create charge message has all the same properties on it besides the email as the create 04:20.080 --> 04:20.410 charge. 04:20.410 --> 04:24.580 DTO So why did we have to even duplicate this in the first place? 04:24.610 --> 04:30.340 Well, the answer is because of the class validator metadata on the DTOs. 04:30.370 --> 04:37.990 We still want our DTOs coming into our system to be validated using class validator and we can still 04:37.990 --> 04:39.610 make this happen using gRPC. 04:39.940 --> 04:43.660 However, we need DTOs with these decorators still applied. 04:44.480 --> 04:50.600 So in order to make sure that our DTOs are always matching up with the message types that are generated, 04:50.600 --> 04:57.440 which are really the source of truth for our data, we want to actually implement those interfaces. 04:57.560 --> 04:59.000 So let's go ahead and do that. 04:59.030 --> 05:07.760 We can say the create charge DTO will actually implement the create charge message from the types folder 05:09.380 --> 05:13.000 and we can go to the card DTO and do the same thing here. 05:13.010 --> 05:17.270 We're going to say that the card DTO will implement the card message. 05:17.480 --> 05:24.230 So this means that if our gRPC proto definitions ever change and we regenerate these types, we'll know 05:24.230 --> 05:29.540 right away if we have to update our DTOs as well and prevent any runtime errors. 05:30.410 --> 05:35.450 Now of course we can see it's complaining because we still are using underscores in our DTO. 05:35.600 --> 05:41.540 Let's go ahead and refactor this to use camel casing and we'll make sure that we translate this back 05:41.570 --> 05:44.130 later on in our service layer. 05:45.120 --> 05:51.330 Now in the Create Charge, DTO, we of course, we don't want to actually specify the email here in 05:51.330 --> 05:55.530 the common DTO because this is only applicable in our payments. 05:55.530 --> 05:56.970 Create charge DTO. 05:57.330 --> 06:06.360 So to specify this we can use the omit keyword that will allow us to omit any properties from a type. 06:06.540 --> 06:08.250 We just need to specify it here. 06:08.250 --> 06:14.790 So we'll say we want to implement the create charge message except for the email property and now we 06:14.790 --> 06:15.960 are type safe. 06:16.740 --> 06:25.140 So now that we've updated our DTOs, let's go to our JWT auth guard in our common source auth folder. 06:25.170 --> 06:28.290 Well, we'll refactor this to now use gRPC. 06:29.130 --> 06:37.140 So the first thing we'll do is make sure we're actually implementing on module init from Nestjs common. 06:37.920 --> 06:46.530 Then we'll make sure we'll change the injection token to be auth service name from types. 06:46.710 --> 06:55.470 And this is simply a constant that's exported from our OTS and this is going to be the injection token 06:55.470 --> 07:02.040 we'll use later on in the clients module when we set up this service in our corresponding module. 07:03.300 --> 07:07.050 So for now, let's make sure we match the injection token here. 07:07.590 --> 07:13.350 And then we'll go ahead and change the name of the variable to a client, because the type here will 07:13.350 --> 07:15.210 also change to be a client. 07:15.240 --> 07:18.610 gRPC from Nestjs Microservices. 07:18.630 --> 07:20.630 So this is a little different than before. 07:20.640 --> 07:26.190 We actually need to set the service that we want in the on module init method now. 07:26.190 --> 07:28.470 So let's implement on module init. 07:28.560 --> 07:31.760 And now in here we want to set our auth service. 07:31.770 --> 07:37.260 So let's go ahead and declare a class variable called private auth service. 07:37.350 --> 07:42.780 And this is type is going to be the auth service client that we saw earlier. 07:43.110 --> 07:49.350 So we can see that this is the auth service client from TS which is going to have access to all of the 07:49.380 --> 07:54.390 RPC methods in our auth Proto in this case the authenticate method. 07:54.780 --> 08:01.590 So now an on module init, let's go ahead and set the auth service equal to this Dot client. 08:03.070 --> 08:06.860 Dot get service and will provide the auth service. 08:06.890 --> 08:08.080 Client type. 08:09.400 --> 08:13.090 And then we provide the name of the service. 08:13.090 --> 08:18.550 So in our case, this is going to be the auth service name that we've already used. 08:19.000 --> 08:21.310 Now you might be wondering where this is coming from. 08:21.310 --> 08:29.020 Well, this name of the auth service directly corresponds with the name of the auth service that we 08:29.050 --> 08:30.430 define in our auth Proto. 08:30.670 --> 08:36.190 So the auth service name here corresponds to the service that we're asking for. 08:36.220 --> 08:39.760 And this is also the same exact name of our injection token. 08:39.760 --> 08:45.400 So now that we've correctly set our auth service, let's go ahead and refactor our call to actually 08:45.400 --> 08:46.000 use it. 08:46.960 --> 08:49.690 We're going to be calling this off service. 08:49.690 --> 08:56.530 And now we can directly call authenticate on it as if it was a local in-process method. 08:56.530 --> 09:01.020 And the fact that it's an RPC call is completely abstracted away from us. 09:01.030 --> 09:08.620 So we'll call authenticate and then we need to pass in the request message, which is going to be the 09:08.620 --> 09:11.470 same exact object we're currently sending. 09:11.470 --> 09:14.140 So let's just go ahead and remove the dot send. 09:15.360 --> 09:21.600 And we'll keep this object that we are sending, which is the authentication property which contains 09:21.600 --> 09:22.380 the JWT. 09:23.580 --> 09:29.610 Now, one final change we're going to make is that when we get the response back from the auth service, 09:30.120 --> 09:35.910 we actually want to set this equal to an object where we'll go ahead and spread all of the properties 09:35.910 --> 09:38.810 from the response, which we know is the user. 09:38.820 --> 09:46.440 However, now we want to make sure we explicitly set the underscore ID equal to response.id. 09:46.770 --> 09:50.610 So you can see here we have all of the properties coming back from the user. 09:50.610 --> 09:58.080 But remember in gRPC we can't use underscores, so we need to map the ID property from the user message 09:58.080 --> 10:02.220 to the underscore ID that the rest of our application expects. 10:02.670 --> 10:09.060 And now I'll just go up and remove all of the unused imports that we're no longer utilizing anymore.