All right my friends we now have put together our survey schema.
It is linked up to our recipient schema.
Before we move on.
There's one quick thing I want to mention to you.
Remember that we hooked up the survey model inside of our index G-S file.
So here's the required statement for it right here.
Now I had previously said that we need to make sure that we always import our models somewhere into
our project structure.
So you can see right here.
Here's the user and here's the survey we do not have to do something similar for the recipient sub document
model right here because we are already requiring that into the survey get G-S file.
So here's the required statement for recipient right here.
So just a quick reminder we don't have to take care of it in this case.
OK.
So now that our survey model is all set up we're now going to move on over to a new routes file that
we are going to create whose sole purpose will be to implement these different routes that we need to
hook up all the different survey logic inside of our application.
So we're going to make a survey route's file.
We will then define the post request handler to API slash service.
So let's get to it.
Back in my code editor I mean to start off by closing all the different files I have open right now
just to clean things up and then going to find my route's directory.
And inside of there I'll make a new file called survey wraps.
J.S..
Now we've spoken about the structure of these routes files several times.
Now remember we define an arrow function we immediately export it and then we wire that up to our express
an object inside of the top level index not G-S file.
So at the top of the survey route's will say module that exports is the app and then whatever associated
routes we want to attach to it.
Now all immediately save this file I'll flip back over to the index file.
We're going to scroll down to where we hooked up all the other routes.
Right around here.
And we'll set up this new route handler.
So we'll say require dot slash routes survey routes and then pass in the app.
So we've spoken several times now about the kind of syntax we have going on here.
Remember we are requiring in the out of the route function.
There we go.
And then we immediately call that route function with the app object.
And that's pretty much all of the set up we have to do for creating a new route file.
So now inside if we get to create the new route handler itself.
Remember this time around we're taking a post request to slash API slash surveys will say app dot post.
So if any post request comes in to API slash surveys then run this arrow function right here.
Now before we even start worrying about creating a survey in here even remotely before we even dive
into that aspect.
There's two very important things that we want to kind of vet about the user before we start to create
an actual survey.
The first thing we want to do is we want to make sure that the user is logged in.
So without a doubt we want to make sure that if you are attempting to create a survey you've got to
be logged in.
There's no two ways about it.
Secondly if you are logged in we also want to check to make sure that you have enough credits on hand
to actually send out a survey.
So remember that's how all the billing inside of our application works when you create a survey.
It takes one credit to send out that mass bold e-mail to all these different users.
So we want to make sure that a user is logged in and that they have enough credits.
Let's first do the check to make sure that a user is logged in and authenticated and then we'll figure
out exactly how to do the credit stuff after that.
So recall a couple of videos ago we put together this middle weares directory and inside there we created
a file called require loggin and the sole purpose of this function right here was to assert and make
sure that a user was logged in before we allow some particular route handler to actually be executed.
So we can very easily reuse this code with this new API slash surveys throughout.
Handler will first require in that middleware is require up one directory middleware as require log
in and then we can wire up this middleware to the second argument of apt post right here.
And remember when I say second argument it doesn't necessary.
I don't really mean to indicate that it has to be some very particular argument in here.
Remember that we can pass an arbitrary number of functions to this request handler right here and they
will all be executed in line.
So if we have other function functions in here as well that's totally fine.
They will just all be executed until it eventually gets to a function that somehow takes the response
object and sends a response back to the user.
OK.
Lesing I want to remind you about is the required log in function itself.
We are not calling it.
So we are not out the set of parentheses on there because we don't yet have the request or a response
object in hand.
We are simply telling our express app object.
Hey if someone makes a request to this route right here.
Here is a reference to a function that you should run to make sure that the user is actually logged
in.
OK so that's making sure the user is authenticated.
Now step number two is to make sure that a user actually has enough credits to send out a survey so
the check to make sure that the user has enough credits is going to be pretty straightforward.
Like if we go and look at their required log in statement right here remember that our user model which
sits on user has a credits property.
And really we just want to make sure that the user has at least one credit if we are going to let them
create a new survey.
So I'm kind of thinking that we could almost reuse the same type of middleware right here.
And rather than just saying hey make sure that a user exists we could say hey make sure that the user
has enough credits and then if they don't we'll kick them out early.
Otherwise we can allow requests to run through.
So this is going to be another location where we can easily encapsulate all this logic to make sure
that the user has enough credits inside of a middleware.
Now one thing I want to remind you about before we actually create that middleware is that one of the
ideas behind middleware are that it's a little reusable function that we can reuse with many different
route handlers inside of our application.
Now at this point we only have exactly one route and for our application in general.
We're only going to have one route that really deducts or checks to make sure that a user has enough
credits and that is the creation of a new survey right here.
However I can very easily imagine expanding our application in the future to adding more features that
require some amount of billing.
So I do feel pretty secure in saying yes this really should be a middleware because we might have many
different locations inside of our up inside the future where we want to make sure that the user has
some minimum number of credits.
So with that in mind let's take a break.
We come back we're going to create a new middleware to just validate and make sure that the current
user has enough credits to actually send out a survey.
So quick break and I'll see you in the next video.