Now that we extracted the configuration,
What we can also do still here in app.js,
is we can extract our custom middleware.
We are using a bunch of middleware
from third-party packages,
like the URL encoded body parser,
serving static files,
CSRF protection and the session.
We also got a custom middleware here.
And of course we can write that code here,
where we needed,
or we store that in a separate file
to again make this app.js file leaner.
And I'll do that,
I'll add a middlewares folder,
which again is not a reserved name,
you can use whichever name you want,
but it is a common name.
And in there I'll add my auth.js file
or auth-middleware
if you wanna be very clear about what's inside
since this is a file that shoots the (indistinct)
the authentication related middleware.
And in this case,
I only have one authentication related middleware,
but if you had authorization as well,
and you would be doing that
in a separate middleware function,
you could also have multiple middleware functions.
So here I am now going to
extract this async function from app.js,
I'm going to cut it
and add it here in auth-middleware js.
Now this was an anonymous function
and since I'm now defining it stand alone
and I wanna use it in a different place,
this can't stay an anonymous function,
it needs a name now instead
so that we can refer to it by that name
in other places of our code.
And here I'll name it, auth,
but the name is totally up to you.
And then all export it, just like this.
I'm going to export this auth function
from that auth-middleware file
so that we can use it in other files.
Because as you learned before,
if you wanna use a feature like a function
from file A in file B,
then you have to import it in file B.
You can't just use it by its name,
instead you have to import it first.
So in this case, app.js is file B
where I wanna use it,
so there I now do import my auth middleware.
You can name this constant however you want
by requiring ./middlewaresauth-middleware.
And then this authMiddleware function
is what I parse to app use.
Now, unlike csrf or urlencoded
and all these other
third-party middlewares I added,
this doesn't need to be executed.
Because these functions
which are coming from third party packages
are actually not the middlewares themselves,
instead these are in the end,
all configuration functions
which take configuration options
at least optionally,
in case of csrf I'm not parsing any,
but if we could configure this as well.
And therefore it's these configuration functions,
which are provided by the third-party packages,
and that's why I'm executing them here in app use.
Because when we execute this configuration function,
that will return us the actual middleware
and it's then the returned middleware
that is registered.
In case of authMiddleware,
I got no configuration function wrapper.
Instead there,
I directly defined the middleware function itself,
the function that takes req, res and next.
And I'm exporting this function
so therefore this should not be executed by us,
but instead by express, once we got incoming requests,
this is the middleware function already.
That's why I'm not executing
the auth-middleware function here,
but why I'm just pointing at it
because I don't wanna execute it
instead that is the middleware function
which I wanna register with express
so that express executes it in the future
once I got incoming requests.
And now if we save that,
we can also quickly test this
and try logging in here real quick.
And that still seems to work just fine.
So that authMiddleware also works
and now I extracted this as well.
And with that, we of course could do more,
but I would say this is enough right now
and that app.js file already got a bit leaner
and our code got more structured.
Because now for example,
if we wanna work on the session configuration
or on the authMiddleware,
we don't have to search for the relevant parts
here in app.js
instead we can directly go to the relevant files,
which are then way leaner
and way more structured.
That's the idea behind refactoring in the end.
Now with all of that done,
let's come back to our routes.
We already split the routes into multiple files,
but these files are still relatively large.
And if you would have a look at the different routes
that are registered there,
you would find some code duplication in there.
For example that session error management here.
And whenever you see code duplication,
that's a good indicator
that more refactoring could be done
and that you might be able to make your code slimmer
and easier to manage.
So therefore this session usage
for error management thing
is one aspect that could probably be outsourced
and we're going to do that.
But in addition to that
what we also have in those files
is a lot of logic related
to working with the database.
We're doing all the database operations in there
and even though those operations aren't too difficult,
it's still a lot of logic
that lifts in this routes folder
or in these routes files.
And as always that's not horrible,
but it is something you could consider doing differently.
And that's what I'll dive in next
before we then there after
explore more refactoring potential
that we might have in these files.