You have spent a very long time on our ticket service and we are almost done with it.
Just one last thing here.
I think maybe one more last thing after this.
We'll see.
Anyways right now in my ticket's service I got to find S.R. and then inside their index not to yes but
inside of index out to us before we start up our Express application.
You'll recall that we connect through the Nats client and we provide a hardcoded cluster I.D. right
there a hardcoded client I.D. Andi hardcoded you are L for our Net server as well.
We went through a decent amount of effort to extract some hardcoded connection variables and whatnot
into environment variables for our JWT Tiki and the Mongo your eye as well.
So I think we should do something very similar or the cluster idea client I.D. Andy you are out for
NATS.
This is just going to make sure that if we ever want to change those settings it's gonna be a lot easier
to modify an environment variable inside inside of a config file than updating our actual source code
so let's try to define a couple more environment variables inside of our ticketing deployment file.
I'm gonna find my infra directory and then inside there I'll find my ticket's deployment file.
Here it is right here.
This is where we had previously specified the Mongo you or I.
And just on Jason web token key environment variables are going to add on three more enviroment variables
right here one for our cluster i.e. one for the client I.D. and one for the URL we're gonna focus first
on the Cluster idea and the URL and we'll take care of the client I.D..
Third because that's going to be kind of a special little case so inside the deployment file I'm going
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
two.
Next up I'll put in a name of Nats luster I.D. and the value for this is ticketing.
We don't actually need quotes on that one.
All right that looks good.
Now what about the client I.D. the client I.D. is kind of a special case a client I.D. remember needs
to be unique for every client that we have connecting to nets so we can not really have a hardcoded
value right here if we expect to be running multiple copies of our tickets service.
The same is true of our deployment file as well.
We cannot put a hard coded value inside of here because if we want to run multiple copies of the ticket
service they will all try to use that same hardcoded client I.D. value what we had done previously back
on our little test project was to just randomly generate a string and throw it inside there.
That is definitely an option but I think there might be a better solution here.
Let me tell you why a random string is not the best thing for a client I.D. at some point in the future
we might want to take a look at the logs on our net server to take a look at the Nats deployment take
a look at the logs and take a look at the different clients that have connected to it over time.
When we look at all those client I.D. according to Nats it'll be really nice if we get somehow match
up the idea of each client to an actual running copy of our ticket services.
So in other words I kind of want to know or each copy of my ticket service that is connected to Nats
what each of those is doing and that's easiest to do.
If we have some meaningful value inside of here for the client I.D. as opposed to a just completely
randomly generated value so how can we get a unique value inside of here that we can use to somehow
tie back to each copy of the ticket service we are running.
Well let's go over to our terminal run all commands and I'll show you something that would be very effective
for this purpose.
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
right there with the name of this pod is unique and I would never expect to have two pods that are running
the ticket service with identical names.
And what's more if this name right here shows up as an I.D. inside of my Nats logs I can very easily
take a look at that I.D. and say oh well the client that is connecting with this I.D. must be this spot
right here.
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
I.D. how do we do that.
Well back inside of our deployment file of course inside of my ticket's deployment file inside of our
end section once again I'm gonna put in another entry here.
I'm going to provide a Nats client I.D. and then for the value right here we need to somehow tell Cuban
is that we want to take the pods like the pods name which is randomly generated and use it as the value
right here to do so rather than writing out a value we're gonna put in value from then field ref and
then build out metadata dot name now whenever we create a pod to run the ticket service Uber ladies
is going to take a look at the pods name and provide it as an environment variable inside of our container
called Nats client I.D. and so we could use that.
It is going to be randomly generated.
It will be unique but it also identifies this client inside of some Nats logs or what have you back
to the actual pod that is running our ticket service.
I think that this is is a pretty good solution.
All right.
So now that we've got all these environment variables are going to save this config file.
Well then go back over to index dot to us and we're going to make sure that we pass in those environment
variables for the Connect statement right here.
Now once again remember typescript wants us to make sure that these environment variables actually exist.
So we do have to do some additional checks very similar to these I'm going to copy the Mongo your I
won and paste it down three times
and then I'll write out inside of these three copy pasted statements a check for it and that's calling
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
going to change EMV to Nats client I.D. I'll change the air right there as well to Nats client I.D.
then I'll go manually to Nats underscore your El and then the last one was Buster I.D. though Mongo
your eye on the last right here to cluster I.D. then make sure that you still have Mongo your eye that's
client I.D. that's your l and that's cluster I.D. then we can take those different environment variables
and throw them into this connect statement I can delete the hardcoded values and replace them with process
EMV Nats cluster I.D. do some more copy pasting just to save myself some time the next one is going
to be our Nats client I.D. And then finally Nats your l like so as usual we should probably make sure
this stuff is all working so I going to say this file will then go back over to my terminal and I should
see my ticket service still successfully connecting to Nats yep looks good to me all right.
So that is pretty much it for our ticket service.
We have spent a very long time on this.
There is still one or two things we have to come back to sing and take care of.
You might recall that many videos ago we had a discussion on concurrency and tracking the version of
say like this ticket thing to make sure that we don't have concurrent updates.
So we start to come back and handle some stuff like that on our ticket model.
We also are going to eventually come back and add in some listeners to the service as well.
Once we have another service publishing events.
But right now that is pretty much it for our tickets service.
Now I know we spent a crazy amount of time on the thing many many hours but this is a pretty rock solid
service right now.
So we're going to end up using this ticket service as kind of a base.
We're going to more or less copy paste it to be totally honest with you over to our next service and
use that as a base.
Now that we understand how all this different stuff works.
Trust me the next service you put together is gonna be a lot faster.
So pause right here and I'll see ya in just a minute.