1 00:00:01,020 --> 00:00:04,870 You have spent a very long time on our ticket service and we are almost done with it. 2 00:00:04,890 --> 00:00:06,900 Just one last thing here. 3 00:00:06,960 --> 00:00:08,970 I think maybe one more last thing after this. 4 00:00:08,970 --> 00:00:09,580 We'll see. 5 00:00:09,750 --> 00:00:16,020 Anyways right now in my ticket's service I got to find S.R. and then inside their index not to yes but 6 00:00:16,050 --> 00:00:19,530 inside of index out to us before we start up our Express application. 7 00:00:19,530 --> 00:00:25,470 You'll recall that we connect through the Nats client and we provide a hardcoded cluster I.D. right 8 00:00:25,470 --> 00:00:31,110 there a hardcoded client I.D. Andi hardcoded you are L for our Net server as well. 9 00:00:31,230 --> 00:00:35,910 We went through a decent amount of effort to extract some hardcoded connection variables and whatnot 10 00:00:35,910 --> 00:00:40,890 into environment variables for our JWT Tiki and the Mongo your eye as well. 11 00:00:40,890 --> 00:00:46,110 So I think we should do something very similar or the cluster idea client I.D. Andy you are out for 12 00:00:46,110 --> 00:00:46,870 NATS. 13 00:00:47,070 --> 00:00:50,550 This is just going to make sure that if we ever want to change those settings it's gonna be a lot easier 14 00:00:50,550 --> 00:00:55,380 to modify an environment variable inside inside of a config file than updating our actual source code 15 00:00:56,480 --> 00:01:03,040 so let's try to define a couple more environment variables inside of our ticketing deployment file. 16 00:01:03,050 --> 00:01:08,360 I'm gonna find my infra directory and then inside there I'll find my ticket's deployment file. 17 00:01:08,360 --> 00:01:09,500 Here it is right here. 18 00:01:10,930 --> 00:01:13,960 This is where we had previously specified the Mongo you or I. 19 00:01:13,960 --> 00:01:18,730 And just on Jason web token key environment variables are going to add on three more enviroment variables 20 00:01:18,730 --> 00:01:26,050 right here one for our cluster i.e. one for the client I.D. and one for the URL we're gonna focus first 21 00:01:26,050 --> 00:01:28,780 on the Cluster idea and the URL and we'll take care of the client I.D.. 22 00:01:28,810 --> 00:01:33,950 Third because that's going to be kind of a special little case so inside the deployment file I'm going 23 00:01:33,950 --> 00:01:45,330 to add in a name of Nats you are L and a value of H TTP O and slash slash that's SRB ports or two to 24 00:01:45,330 --> 00:01:46,950 two. 25 00:01:46,960 --> 00:01:56,880 Next up I'll put in a name of Nats luster I.D. and the value for this is ticketing. 26 00:01:56,940 --> 00:01:58,650 We don't actually need quotes on that one. 27 00:02:00,650 --> 00:02:02,060 All right that looks good. 28 00:02:02,120 --> 00:02:07,430 Now what about the client I.D. the client I.D. is kind of a special case a client I.D. remember needs 29 00:02:07,430 --> 00:02:12,750 to be unique for every client that we have connecting to nets so we can not really have a hardcoded 30 00:02:12,860 --> 00:02:17,970 value right here if we expect to be running multiple copies of our tickets service. 31 00:02:18,260 --> 00:02:20,840 The same is true of our deployment file as well. 32 00:02:20,840 --> 00:02:25,190 We cannot put a hard coded value inside of here because if we want to run multiple copies of the ticket 33 00:02:25,190 --> 00:02:31,100 service they will all try to use that same hardcoded client I.D. value what we had done previously back 34 00:02:31,100 --> 00:02:35,730 on our little test project was to just randomly generate a string and throw it inside there. 35 00:02:35,780 --> 00:02:39,680 That is definitely an option but I think there might be a better solution here. 36 00:02:39,740 --> 00:02:45,250 Let me tell you why a random string is not the best thing for a client I.D. at some point in the future 37 00:02:45,460 --> 00:02:50,710 we might want to take a look at the logs on our net server to take a look at the Nats deployment take 38 00:02:50,710 --> 00:02:55,300 a look at the logs and take a look at the different clients that have connected to it over time. 39 00:02:55,300 --> 00:03:01,330 When we look at all those client I.D. according to Nats it'll be really nice if we get somehow match 40 00:03:01,330 --> 00:03:06,490 up the idea of each client to an actual running copy of our ticket services. 41 00:03:06,520 --> 00:03:11,410 So in other words I kind of want to know or each copy of my ticket service that is connected to Nats 42 00:03:11,680 --> 00:03:15,100 what each of those is doing and that's easiest to do. 43 00:03:15,100 --> 00:03:19,840 If we have some meaningful value inside of here for the client I.D. as opposed to a just completely 44 00:03:19,900 --> 00:03:25,590 randomly generated value so how can we get a unique value inside of here that we can use to somehow 45 00:03:25,590 --> 00:03:28,960 tie back to each copy of the ticket service we are running. 46 00:03:29,040 --> 00:03:33,750 Well let's go over to our terminal run all commands and I'll show you something that would be very effective 47 00:03:33,750 --> 00:03:35,350 for this purpose. 48 00:03:35,390 --> 00:03:41,160 So at my terminal I can do a QCT I'll get pods and I'll see that I've got my running tickets service 49 00:03:41,220 --> 00:03:47,190 right there with the name of this pod is unique and I would never expect to have two pods that are running 50 00:03:47,190 --> 00:03:50,220 the ticket service with identical names. 51 00:03:50,220 --> 00:03:56,460 And what's more if this name right here shows up as an I.D. inside of my Nats logs I can very easily 52 00:03:56,460 --> 00:04:02,050 take a look at that I.D. and say oh well the client that is connecting with this I.D. must be this spot 53 00:04:02,070 --> 00:04:03,230 right here. 54 00:04:03,260 --> 00:04:09,600 So I think it'd be really nice if we could figure out some way to use the name of a pod as our client 55 00:04:09,630 --> 00:04:11,950 I.D. how do we do that. 56 00:04:12,000 --> 00:04:17,610 Well back inside of our deployment file of course inside of my ticket's deployment file inside of our 57 00:04:17,840 --> 00:04:21,430 end section once again I'm gonna put in another entry here. 58 00:04:21,660 --> 00:04:29,550 I'm going to provide a Nats client I.D. and then for the value right here we need to somehow tell Cuban 59 00:04:29,650 --> 00:04:37,470 is that we want to take the pods like the pods name which is randomly generated and use it as the value 60 00:04:37,470 --> 00:04:47,110 right here to do so rather than writing out a value we're gonna put in value from then field ref and 61 00:04:47,110 --> 00:04:56,730 then build out metadata dot name now whenever we create a pod to run the ticket service Uber ladies 62 00:04:56,740 --> 00:05:01,890 is going to take a look at the pods name and provide it as an environment variable inside of our container 63 00:05:01,900 --> 00:05:04,800 called Nats client I.D. and so we could use that. 64 00:05:04,810 --> 00:05:06,430 It is going to be randomly generated. 65 00:05:06,430 --> 00:05:12,310 It will be unique but it also identifies this client inside of some Nats logs or what have you back 66 00:05:12,310 --> 00:05:15,650 to the actual pod that is running our ticket service. 67 00:05:15,720 --> 00:05:17,480 I think that this is is a pretty good solution. 68 00:05:18,550 --> 00:05:18,810 All right. 69 00:05:18,820 --> 00:05:22,480 So now that we've got all these environment variables are going to save this config file. 70 00:05:22,510 --> 00:05:26,980 Well then go back over to index dot to us and we're going to make sure that we pass in those environment 71 00:05:26,980 --> 00:05:30,650 variables for the Connect statement right here. 72 00:05:30,660 --> 00:05:35,040 Now once again remember typescript wants us to make sure that these environment variables actually exist. 73 00:05:35,040 --> 00:05:41,050 So we do have to do some additional checks very similar to these I'm going to copy the Mongo your I 74 00:05:41,050 --> 00:05:42,920 won and paste it down three times 75 00:05:45,730 --> 00:05:50,020 and then I'll write out inside of these three copy pasted statements a check for it and that's calling 76 00:05:50,030 --> 00:05:57,030 I.D. Natsu rail and that's cluster I.D. So for the first one here's the first copy of Mongo your I'm 77 00:05:57,050 --> 00:06:02,950 going to change EMV to Nats client I.D. I'll change the air right there as well to Nats client I.D. 78 00:06:03,940 --> 00:06:14,550 then I'll go manually to Nats underscore your El and then the last one was Buster I.D. though Mongo 79 00:06:14,550 --> 00:06:19,650 your eye on the last right here to cluster I.D. then make sure that you still have Mongo your eye that's 80 00:06:19,650 --> 00:06:24,910 client I.D. that's your l and that's cluster I.D. then we can take those different environment variables 81 00:06:24,940 --> 00:06:31,600 and throw them into this connect statement I can delete the hardcoded values and replace them with process 82 00:06:31,720 --> 00:06:40,370 EMV Nats cluster I.D. do some more copy pasting just to save myself some time the next one is going 83 00:06:40,370 --> 00:06:50,520 to be our Nats client I.D. And then finally Nats your l like so as usual we should probably make sure 84 00:06:50,520 --> 00:06:56,310 this stuff is all working so I going to say this file will then go back over to my terminal and I should 85 00:06:56,310 --> 00:07:03,250 see my ticket service still successfully connecting to Nats yep looks good to me all right. 86 00:07:03,250 --> 00:07:06,220 So that is pretty much it for our ticket service. 87 00:07:06,220 --> 00:07:08,480 We have spent a very long time on this. 88 00:07:08,620 --> 00:07:11,790 There is still one or two things we have to come back to sing and take care of. 89 00:07:11,800 --> 00:07:17,020 You might recall that many videos ago we had a discussion on concurrency and tracking the version of 90 00:07:17,020 --> 00:07:20,710 say like this ticket thing to make sure that we don't have concurrent updates. 91 00:07:20,710 --> 00:07:24,170 So we start to come back and handle some stuff like that on our ticket model. 92 00:07:24,190 --> 00:07:28,150 We also are going to eventually come back and add in some listeners to the service as well. 93 00:07:28,150 --> 00:07:30,390 Once we have another service publishing events. 94 00:07:30,580 --> 00:07:34,250 But right now that is pretty much it for our tickets service. 95 00:07:34,390 --> 00:07:40,210 Now I know we spent a crazy amount of time on the thing many many hours but this is a pretty rock solid 96 00:07:40,210 --> 00:07:41,300 service right now. 97 00:07:41,530 --> 00:07:45,030 So we're going to end up using this ticket service as kind of a base. 98 00:07:45,040 --> 00:07:49,990 We're going to more or less copy paste it to be totally honest with you over to our next service and 99 00:07:49,990 --> 00:07:51,030 use that as a base. 100 00:07:51,060 --> 00:07:53,390 Now that we understand how all this different stuff works. 101 00:07:53,440 --> 00:07:57,040 Trust me the next service you put together is gonna be a lot faster. 102 00:07:57,040 --> 00:07:59,430 So pause right here and I'll see ya in just a minute.