Now that your API is sending back authentication tokens When users sign up or log in it's time to start
talking about how those tokens are gonna be used to actually authenticate other requests.
Now remember every single request to the API is going to require authentication with the exception of
sign up and log in for everything else the client is going to need to provide that authentication token
and the server is going to validate it before performing whatever operation they're trying to do.
Now we're going to knock this feature out in this video and in the next one and where I'd like to start
is talking about Express middleware which is going to be at the core of allowing us to get all of this
done to get started.
Let's head over to visual studio code and explore how express Middleware is going to fit into our application
architecture.
Now for this video we'll be spending all of our time in index dot J.
S and over here I'm going to start by pasting in a set of JavaScript comments which are going to serve
as a little diagram illustrating what Express middleware will allow us to do.
So without middleware which is our current setup we have the following situation A new request comes
into the server and the first thing that runs is our root handler.
This is the only thing we've set up to execute.
So the new request comes in Express maps to the correct route and that function gets executed.
This is exactly what we've seen for the dozen or so requests we've created and run so far.
Now with middleware we can customize the behavior of the server to fit our needs.
So in this case we have something similar but slightly different.
There's a step added in the middle so we still have a new request coming into the express server but
then we do something now.
This something is nothing more than a function that runs and we can set up this function to do whatever
we'd like.
Maybe we want to log out some statistics about their request so we can keep track of it in our server
logs or maybe we want to check if there is a valid authentication token.
Now once the middleware runs we can continue to choose to run the regular route handler so the given
operation is completed successfully.
Now in here we have a ton of control over what we do.
We could allow the route handler to run.
We could prevent it from running if the user isn't authenticated as an example.
So express middleware gives us a lot of fine grained control over how we can customize our app.
Now when we set up our middleware functions we don't have to do it for every single route in the Express
application.
We can target individual ones which is what we'll be doing with authentication.
Because remember sign up and log in.
Aren't you going to require authentication to work.
Now let's actually write some code to register a middleware function of our own.
We're going to add this code right up here as one of the first things we do in the file make sure that
what you're adding is above our other app dot use calls and I'll talk more about why that needs to be
in a little bit.
And right here what are we going to do.
Well to register a new middleware function to run we use app dot use a method we've actually called
before.
Now every time in the past when we've called app use we always provide something that was created by
express.
We've never explicitly provided a function that we've defined but that's exactly what we're going to
do right here.
So let's go ahead and pass.
To use a single argument a function.
Now this function is the function that's going to run between the request coming to the server and the
root handler actually running.
And it has access to the same information as the root handler.
Right here I get access to the request and the response along with one additional argument called next.
Now request and response both of those contain the same information that we would have for our root
handler.
It is only next.
That's specific to registering middleware to get started.
Let's go ahead and just use console dialog and to print something into the terminal.
What I'm going to do is print out the request method and the path.
So was it I get a post a delete and what was the path.
Was it forward slash users or forward slash posts.
So right here we have access to all of that information on the request object.
We have a request dot method where we can get the H TTP method used and we have request dot path where
we can get that path.
Now for the moment we're not going to add anything else into the function we're just going to set it
up with this one line and we're going to test it out by running a request from man.
Let's go ahead and run a request like the read use request right here.
I'm gonna go ahead and fire that off and down below.
What do we see.
I see.
Loading printing.
And it's never gonna go away.
It's going to run until eventually post man just gives up.
Now we can always cancel that in order to stop their request.
But the question is why is it always loading why doesn't ever it get the response that it's expecting.
Which would be the users array.
The reasoning has to do with the function that we've created.
Your middleware function can do as much or as little as it needs to.
It could be something as simple as logging out a message or something as complex as validating a token
and making sure that user exists in the database.
But it's your job to call next.
If the next thing in the chain should run so down below we have the new request and we have do something.
If do something.
Our middleware function never calls next.
The root handler is never going to run.
If we do want the root handler to run all we do is we call next right here.
We don't have to provide any arguments to it.
We just call it letting express know that we're done with this middleware function.
So right here we can add the call to next and test things out.
We're not going to change anything else.
All we've done is we've added that in over inside of postmen.
What I'm gonna do is fire that off one more time and right here we are indeed getting the same old response
we were getting before we ever had that middleware function set up.
Now inside of visual studio code you'll notice that down in the terminal we have a get forward slash
users showing up.
So now we have the best of both worlds.
We're able to log out what we wanted to log out but in the end of the day our request is still able
to run providing the user with the information that they've requested.
Now it's possible that you don't always want to call next and there's valid reasons to do that.
Sometimes your middleware should stop the root handler from running like it's going to do when we eventually
set up authentication.
For the moment though let's go ahead and work through a simpler example.
We're going to say that if someone tries to use the get h TTP method we go ahead and send back a message
saying that they can't.
But if they tried to use post patch or delete will allow it to work.
So let's go ahead and see how we could set something like that up right here.
We're going to wipe out our middleware function and we'll start with a little conditional logic F right
here.
We're going to run this code if it is indeed a get request.
So for us that would be looking at request dotted method and checking if it is equal to the string capital
get if it is.
This code is going to run if it's not.
We could set up an else block that will run instead.
Now if it is valid if it's not get we can go ahead and call next.
That ensures that those root handlers will run if it is get currently.
It would just never respond and we would see that loading screen forever.
And that's not what we want either.
If we're not going to call next from our middleware it's a good idea to send back a response saying
why saying why things aren't working as expected.
Right here we can use response dot send which we've used plenty of times before to say something like
get requests are disabled.
Now let's go ahead and save the program and test things out.
If it's a get request I would expect us to see this message.
If it's anything else I would expect it to work right here.
I have read users.
I'm gonna go ahead and fire that off one more time.
And what do I get.
I get my get request message showing up.
Now let's try a non get request like create user which uses post I'll fire that off and it does indeed
work.
Now the user wasn't created because that e-mails already taken.
But it did indeed at least run the root handler.
So using just a little variation in our middleware we can limit what a user has access to.
And this is the exact same technique we'll use to enable authentication.
Now we'll get to that in the next video but before we do a quick challenge for you to setup some middleware
on your own up above I'm going to go ahead and comment out of the middleware function.
We've already created and it's going to be your job to create a middleware function for when your site
is in maintenance mode.
Right here it's going to be your challenge to create middleware for a maintenance mode.
So right here what you're going to do is register a new middleware function and you could do that right
here below our previous one.
And the job of this one is to disable every single request that matter what someone makes a request
to you're going to send back a response with a maintenance message and a 5 0 3 status code which means
that the service is temporarily unavailable.
Now for the actual message you could say something like the site is under maintenance please try back
soon.
This would be really useful if you were doing something like upgrading your database and you needed
the service to shut down temporarily though you would bring it back online shortly.
So in this case we don't want any of our request handler functions to ever run.
We want to send back that message for every single incoming request.
Now once you're done with that go ahead and test things out make a couple of requests over and post
man and make sure you see the correct message and status code showing up.
Take some time to knock that out test your work and when you're done go ahead and click play
how'd that go.
Let's go ahead and get started by calling app dot you.
So right here we are going to register a brand new middleware function to run.
And we know we get access to those three arguments.
We have a request and a response.
And next.
Now I already know that I'm not going to use next or response.
We don't have to name those but it's common practice to always list out all three.
Just so you have them available.
And do you remember what you have access to down below in the function itself.
We want to send back our maintenance message with a 5 0 3 status code.
So right here let's go ahead and do just that for that I'll be using response dot status to set these
status code to a 5 0 3.
Then I'll go ahead and use send to send back the message site is currently down.
Check back soon or any other message would get the job done.
So we have the middleware intercepting their requests we're sending back our maintenance response and
we're not calling next.
Which means that none of those root handlers will ever execute the last step is to test things out.
I'm going to try.
The requests from the server using postman and I'll make sure I get the correct response back.
Right here.
What I'm going to do is remove the challenge comments.
I'll also remove the little diagram we had down below.
I'll save the file then I'll test things from postman over here.
I have create user I'll fire that off and we get our maintenance message and the status code which is
great and expected and over here for another request like read users I should see the same thing.
And I am so using middleware we can customize our server to fit our needs.
Now currently we're setting up middleware that runs for every single root handler in the next video
as we actually set up the authentication middleware.
We'll learn how we can set it up for specific requests.
I'm excited to get to that.
So let's jump right into the next one.