All right.
And up next, let's install two more packages Morgan and dot env.
Now Morgan is an awesome package that provides logs about our requests, which is super, super, super
useful while we're developing especially a full stack project because once in a while you get the situation
where you're sending the request from the front end and everything seems to be correct.
But of course stuff is not working.
And then you go to the server and you're like, Oh, the URL is wrong, or the method and all that.
Now of course you can still have the same error even with Thunder Client, but again, especially with
the front end, it's very, very useful.
And the second one is going to be dot env, which loads up the environment variables.
Now what are environment variables?
Well there are going to be some values that we don't want to share with the rest of the world when we
push our project to a GitHub for example, our database connection string.
So that's something we want to keep secret.
And in order to do that we'll create a file.
But in order to access that dot env file in our project, we need to use this package.
And then of course we'll set up those values locally.
And then once we push this up to production, we'll go to our platform in our case render and then we'll
add them one more time.
And if some of this sounds iffy, trust me, once we start working with these packages, you'll see
exactly what I'm talking about.
Now, if you want to check out their docs, of course you have the links over here in order to install
them.
This is the command you need to run, of course, without the versions and all that.
And then.
In order to get started with Morgan, it's a middleware.
So effectively, we want to import from Morgan and since it's a middleware, we just go with app.use.
We invoke Morgan and in here we pass in a string.
So in my case, I'm going to go with dev option.
But if you want to check out more options, then of course navigate to their docs.
And the only difference is the amount of info you're going to get.
So again, I'm going to go with the dev one, so let's try it out.
I'm going to go to a server.
And right after the Express, I guess we're going to go with import then Morgan from Morgan and I'm
going to do it above the Json.
I'm just going to go with App.use.
Like I said, invoke Morgan and then I'm going to go with Dev option.
Let's save it.
We need to make a request.
Now of course you can also go to a browser and all that, but in my case I'm just going to go with the
one over here.
Let's send it.
So I'll see my response.
But that's not what I'm actually looking for.
Notice in the console I'll have this get then forward slash again, that just means homepage and that
the request was successful.
And again, it's super, super, super useful once we connect our back end to the front end.
All right.
So that's the first package.
Up next, let's talk about the dot envy.
Like I said, this is a file that we create in a route, and this is where we essentially set up the
variables we don't want to share.
Now, there's also some things you can add here that maybe are not that sensitive, but still it's useful
to add them there.
And the first thing I suggest doing the moment you create a dot env is actually add this dot envy to
gitignore because otherwise it's going to get pushed up to a GitHub and that's definitely the last thing
you want.
So make sure you find the git ignore and make sure you add here dot env.
So we don't want to share this, we don't want to add this to our source control, so let's save it
over here and effectively.
We want to grab the envy and we also want to set up the values.
The first value I'm actually going to set up is the node environment.
You see, when we push this up to production, this node environment is a special value that automatically
gets injected and the value will be production.
However, while we're in development, we'll actually add our own value in the dot env.
Why?
Well, because there's certain things that I don't want to run in production.
And again, if you're looking at it and you're a little bit confused, yes, this value will be provided
by our platform and as a result we'll only use this package in development and we won't get those logs
in production.
So let's try it out.
I'm going to navigate first to dot env and let's create both of those variables.
So the second one is going to be for the port and again we'll discuss it once we start using it, but
we might as well set it up.
So dot env we'll set it as key value pair and we'll set it equal to development.
And again.
Yes, in production.
The platform is going to inject that value and that value will be equal to production.
And then the second one is the port.
So we can definitely hard code in a server.
But again, once we push this up to production, a platform is going to also inject that value.
So here's what we're going to do.
We'll make one in dot env and then we'll check whether the port value exists.
If it exists, we'll use that one.
If not, we'll again use some kind of hard coded value.
Just keep in mind, yes, that's the case in production.
This value will be again injected.
I know it might seem a little bit abracadabra since we cannot clearly see the production one, but yes,
those things are happening in production.
So now let's navigate here and essentially we want to access those values, Correct.
Now, what was the syntax?
First, we need to grab the star, basically everything.
And we want to name it as dot env.
So import and let's go as dot env.
So we are just coming up with a value package we're looking for is dot env and we need to invoke it.
So essentially we go with dot env and then config.
Now here and there this package and there's another one might give you some problems if you don't place
it on the top.
Again.
If it works then of course you don't need to do anything.
But if you experience any issues with accessing those values then try moving this all the way to the
top.
So this is exactly what I'm going to do.
Basically, I'm going to place it before the Express.
Let's save it again.
We have the middleware for our Morgan and we just want to wrap it in the condition, I'm going to say
if and in order to access right now those env values we need to go to process dot env and yes, this
is special syntax and then we're looking for the actual variable.
So the first one is node env and we'll set it equal to development.
So if that's the case then I want to run it.
If not, if this is going to be equal to production and of course we're not going to show those logs.
So first of all, let's try it out.
Also something to keep in mind whenever you start messing with Envs, you might need to stop and start
the server.
I know that Node is technically doing that for us, but again, if you experience some glitches, just
try stopping the server the good old manual way here with control C and then again run npm run and dev
and now let's try it out.
I'm going to navigate again back to my thunder client.
Let's send it notice while we're in development, of course we're getting the logs, but.
If we mimic the production environment.
We can go over here with production.
If everything is correct, we shouldn't see that log.
So the value is not equal to development.
And of course, in that case, we're not logging.
Again, notice I still get the log because I do need to stop the server.
That's one of those things when you change the dot env values.
So let's go here with NPM run dev.
And now if everything is correct, check it out.
I make a request but I don't see anything in the console.
Why?
Well, because the node environment is not equal to development.
I know that this is probably somewhat redundant, but I just keep repeating that.
But I think it's very, very important to establish this right out of the gate.
So let's go back to development.
Let's right away.
Stop.
And start the server.
So NPM run dev and let's also set up that port value.
So I'm going to navigate back to my server.
Let's keep on moving and right after the post request, essentially I want to create a variable, so
I'm going to go here with port and that one is equal to again process dot env and then the port.
If it exists, we'll use this one.
If not, we're going to use or operator and we're going to go with 5100.
I know this might seem a little bit redundant since the same value we already have in Dot env, but
yes, basically this is the logic.
Now of course you can go with 4000 for example, but again I'll keep both of them as 51.
So of course, during development, this is the value I'll use for my port value.
And then in production, this one will be injected by our platform.
So let's try it out over here.
We're going to go with port variable instead of hard coding.
And then let's just write some additional stuff over here.
I'm going to say server running on port and let's just access it as well.
And you know, I probably need to change it.
From quotation marks to a template string.
Yep, that's the one.
And if everything is correct, we should see the server running on port 5102.
Super, super useful packages.
One to log.
The info about our requests.
And second one to access dot E and V variables in our application.