We're gonna start working on our different root handlers inside this video.
The first right handler.
We're gonna work on is the create order route and make sure that a user can make a poster crust to create
an order whenever a user makes a supposed request they're going to include a ticket I.D. inside the
body the request.
And that's gonna be the ticket that the user is trying to purchase.
Now we definitely are going to want to make sure that only users who are authenticated are able to access
this root handler.
So if you are not authenticated if you're not signed in you do not get to create an order.
So with all that minds let's go back over to our new handler file.
We could start to put together some implementation for this rabbit handler inside my order service.
I'll find the roots directory and new dot.
Yes inside there then at the very top I'm going to import a couple of things that we are probably going
to need inside of here so I'm going to get the require auth middleware and the validate request middleware
from our custom module.
So for me that is SGI ticket slash common.
Remember you have a different organization named right there.
I'm also going to get the body function from Express validator.
So right now words can make sure that a user is authenticated and we're going to make sure that they
are passing in some ticket I.D. in the body the request the right after our route name right there.
I'm going to put in require us to make sure that a user is authenticated and then right after that I'm
going to put in an array and list out my different validators inside of here.
The only thing we really need to truly validate is that ticket items property so we might write in something
like body.
Take a look at the ticket items property and let's just make sure that that thing is defined.
So we might say not is empty and then we can put a custom error message on there of with message and
say ticket I.D. must be provided
now this right here definitely works and it definitely is a good validation step but there's potentially
a one other step of validation we could potentially do inside of here.
When a user passes in a ticket idea property that is a reference to another ticket or some ticket inside
of our system.
And you and I know because the ticket ideas are stored these tickets are stored inside a mongo DV that
this ticket idea property right here should have the structure of an Mongo I.D..
So in other words it should be a string of characters.
That's what is it like twenty four characters twelve or 24 I forget off the top of my head.
Essentially it should look like a mongo DV I.D..
So an idea of something like one two three.
Well that would pass this validation step but that is not a valid I.D..
So we might want to add in a little Czech right here and make sure that whatever the user provided has
the structure of a real Mongo I.D. Now that would definitely be a valuable check here.
But it's also just a little bit dangerous.
And the reason for that is that we would now have one service our order service that is making assumption
or an assumption about the database that is used by the tickets service over here.
So there is a little bit of coupling that we're doing between these two services.
If we start to say oh yeah you must be providing me specifically a mongo DV I.D. at some point in the
future we might decide to change out the database used by the ticket service to some other kind of database.
And when we do that well we might not be using Mongo DB anymore we might have a totally different structure
of I.D..
This is a very small thing.
It's just something I want to throw out there that by just assuming that this ticket idea is going to
have a particular structure.
We are kind of coupling our application in a very subtle way with the ticket service.
You might say Steven What does that matter.
We're already using information from the ticket service you're telling us that we're going to replicate
tickets directly from the ticket service.
Well yes we are replicating data over from that service but well what would happen if we just deleted
the service entirely but still issued these events right here.
So maybe there are some other service not called ticket service our order service doesn't really care
about who even these events it just cares that someone emits these events.
So the ticket service really truly can just totally disappear.
It can change structure it can do something dramatically different.
And as long as these events are still being emitted we are happy campers but that is not quite true.
If we start to directly make assumptions about what the service looks like and that's what we are doing
if we add in a check to make sure that the incoming I.D. is actually a mongo I.D..
So I just want throw it out there.
Once again just something to be aware of.
Just something to think about.
So we are going to add in the check to make sure that this does look like a real Mongo I.D. just so
you know how this would be done and if you don't like this idea of making assumptions about how that
service is put together you can always remove it.
So here's how we would do that check at the very top.
We will import Mongoose from Mongoose then right after making sure that the ticket I.D. property is
not empty.
We'll put on a custom validation step.
We're going to say that we're going to expect to get some input to this little custom validation function
that is going to be a string and inside of here we're going to return a boolean to decide whether or
not whatever string the user just provided is actually a valid Mongo I.D. we will write out instead
of your Mongoose types with a capital T object I.D. with a lowercase d on their is valid and then we'll
pass in that input.
So this is just gonna make sure that the user is providing a valid Mongo I.D..
And again if you want to do that just delete it.
No problem whatsoever.
That looks good.
Now after doing the validation step right there we do need to make sure that if anything went wrong
with the validation step we reject the request right away and send back an error message.
And that was the purpose of that validate request middleware.
They'll put in validate requests right there.
Looks good.
Let's say that at present we do not have any way of testing this code unless we pull out postmen and
starts making requests directly.
So we are going to write tests around these root handlers very similar to how we did back on our test
our ticketing service.
We're going to write out all the tests after we create each individual right handler.
So if you don't like the entire testing process if you just don't care about tests no problem.
I'll give you the completed test code and you can always copy paste it over if you want to be able to
run the tests yourself.
Let's keep working on this in the next video.
Then once we are done with this right handler we'll start to write out a couple of different tests around
it.
We'll see you in just a minute.
Let's finish this thing up.