-: We're almost ready to deploy our application now.
But before we do that,
there is actually a couple of things
that we should take care of.
And so let's do that now.
And the first thing that I want to do
is to install a package
that's gonna compress all our responses.
So basically, whenever we send a text response to a client,
no matter if that's JSON or HTML code.
With the compression package,
that text will then be dramatically compressed.
All right, so let's install here.
Npm install, and simply, compression.
All right.
So let's include that here.
Now, so this will then expose
a very simple middle layer function
that we simply have to plug
into our middle layer stack.
So let's do that somewhere here.
Close to the end, doesn't really matter.
So app.use,
enter in there call compression.
So this here will then return a middle left function
which is then again going to compress
all the text that is sent to clients.
So it's not going to be working for images
because these are usually already compressed.
So for example, a JPEG format is already compressed.
So this is only going to be working for text.
So once our website is actually deployed,
we will then test if this compression is actually active.
Anyway, the next step before deploying our app
is to get rid of most of the console.logs
that we still have in our code.
And that's just because these logins will end up
in our hosting platform logs.
And so we don't want to pollute these logs in production.
Okay.
So let's just quickly search here for console.
And as you can see, there are a lot of them.
So this one is already commented out.
So I'm not going to work on that one.
But this one here, let's actually get rid of.
And so now, one by one,
we will take a look at all of them
and the ones that are not relevant
we will simply comment them out.
All right.
Here in the error controller we also have a ton of them
but some are actually relevant.
Now, not this one.
Let's actually get completely rid of it.
Also not this one,
but then here we have these three
that we actually created on purpose
so that they end up in our hosting platform logs.
Okay.
So remember that we set it up in a way
that when there is an error on the render website
then we'd then get a log
of the error that actually happened.
Together with this emoji here.
And so each time we see this,
we can then easily identify in our logs
that something bad happened on our side.
Okay, and so we have a couple more here.
For example, for other unknown errors where we
do not want to leak the error details to the client.
And so these ones are okay to keep them.
This one we also want to keep
in order to inform us in the logs
that the database connection was successful.
These ones here as well.
This one here is actually in the import-dev-data
so they are not important at all.
Anyway, all the logs here, let's keep them.
Then here, we have this one here,
that we only really did in order to use this middle layer.
So let's actually turn off this middle layer.
Which again we only really used
to test this post find middle layer.
Next up in the user model.
Well, this one we also do not want.
This was just once more for testing purposes.
Then we have package JSON,
so these are actually not even come to the logs.
Then we have to bundle
where we are not going to change anything.
Then we have index.js.
So that's our client side JavaScript.
So let's get rid of this console.log here.
Then we also have some more here in logout
but this one let's actually keep it.
Some more in stripe.
And we're not interested here in the session.
But this one here when there is an error
is actually okay.
And then in server.js,
we have these ones here,
which we actually, again, did on purpose.
So that they really end up showing in our log files.
And don't worry if you don't really know
what I mean with log files.
You will see once we actually put
our application onto Heroku.
So I will show you with the log files by then, all right.
Anyway, all of these console.logs here
are on purpose.
And so is this one here
about the successful database connection.
This one here as well
informing us the port where the app is running.
And this one, and this one are also important.
All right.
And so with this we took care of all the
unnecessary console.logs that we're only just
polluting our log outputs.
Okay, so let's close all of these files here.
All right.
And now, next step,
let's change URLs or API codes
in the client side, JavaScript.
So for example here in login.js,
right now we do this API codes
to this development API.
So here, we of course, have our development URL.
And so like this,
it's not going to work in production
because obviously from there,
we are not gonna be able to access any development URL.
And the same up here.
But fortunately, there is a very simple solution.
So all we need to do is to really get rid of this part.
So if we just delete it like this,
then we're gonna end up with this relative URL.
And since the API and the website
are hosted on the same server
this is gonna work perfectly fine.
So doing it like this is a bit like
specifying the path to images in the HTML.
For example, here in the overview page,
where we have these images,
we just simply say "/img"
and that will then go to the current URL
and will then add that path onto to that.
Okay.
And so the same thing is going to be happening here.
Okay.
Now again, this only works because the API and the website
are basically using the same URL.
So we're hosting them on the same place.
But if you were hosting your website
or your front end on one URL,
and then your API on another URL,
then it wouldn't work like this, okay.
But in this simple application we can just do it like this
because we have this very simple set up.
So let's delete it here in login.
In the index I believe we don't have any URLs.
Yeah that's right.
Also not in the alerts.
Not in Mapbox I believe.
Nope.
But certainly in stripe.
So to get our session.
So we can just do the exact same thing here.
And also in the updateSettings.
Okay.
Give it a save.
And all of them.
And so that one is fixed as well.
And now finally, and continuing working on
the client side JavaScript,
we need to create our final bundle.
All right.
So right now, this is our bundle JavaScript file.
But remember that this was just created
using the watch function.
So in our package.json
we have this watch.js script which will just create
a new bundle whenever we change one of the files.
But without any compression,
or without any performance optimization.
But now that we're really done with all our JavaScript
we are ready to actually build our JavaScript
into a final bundle.
And here we should replace this watch with build,
and so that will then create
our final compressed JavaScript bundle.
All right.
So let's try that out here now.
With npm run.
And once more with tab to auto complete.
So let's see if...
And it's done.
And so let's take a look at our bundle now.
And to see that now, it's really
this nicely compressed.
All right.
Now you also see that we have a ton of these new files here
and that's because you're in our file tree.
Parcel actually creates this cache folder.
But we do not want that folder in our git depository.
Right.
So let's add that here.
And so now
you see that automatically as soon as we save it,
it will then go back to
the original files that were updated.
Okay.
So once more, VS Code is really smart
about everything related to git.
All right.
Okay.
And I think that's actually it.
So our application is now prepared to really be deployed.
And so now the last step is to actually commit
all of these modified files to our repository.
So remember that the first step is to add all the files
to the staging area.
So git add, and in this case, all of the files.
All right.
And now all we need to do is git commit,
then the message, and let's say,
"Prepared app for deployment".
Great!
So you see that all our modifications are gone.
Also from here.
Which means that the current working branch,
is so called clean.
And so yeah, we're actually now ready to deploy our app
in the next video.