All language subtitles for 005 Preparing Our App for Deployment_Downloadly.ir_en

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.