In the last section we spoke about the code that we added to instruct express how to handle incoming
HTP requests.
Now that we've got the absolute basics of an express server put together and we kind of understand more
or less what's going on here.
We're going to move on to the next feature inside of our application.
And so this next feature is something I'm really excited about because it's something that I think you're
going to be excited about.
So for the next year we're going to do.
We're going to figure out how to deploy our application.
Yes that's right square one even with this very basic code right here we're going to figure out how
to handle deployment.
And then as we go through the remainder of this course we're going to consistently make sure that we
update our deployment so that our friends and family can test out our application and give us a little
bit of feedback and tell us how it's going.
So let's get to it.
We're going to figure out how to deploy this application and we're going to figure out how we deploy
it again in the future much more easily now to handle deployments throughout this entire course.
We're going to be using a third party service called Heroku.
So in a new browser tab I'm going to navigate to Heroku dot com.
Now I know that you might have your own pre or your own personal preference for a service provider you
might prefer to use AWOS or digital lotion or any other of a number of different providers.
But for our purposes Heroku really is a very happy medium because we can get started for free and deploy
our app without having to associate any credit cards or anything like that.
So I know that maybe you want to see some stuff around AWOS but we're going to start with Heroku and
figure out how we get this process going really well.
So let's get to it.
There's going to be a couple steps so we have to go through to get our application Heroku ready or ready
to be actually deployed.
So let's take a look at a quick diagram.
It's going to walk through us through all these steps.
So this is our deployment checklist right here.
These are some steps that we have to do exactly one time to get our server code ready to actually be
deployed after we go through these steps right here.
We will then go through a separate checklist that's going to guide us through deploying our application
for the very first time and how we deploy our app on future deployments like after we've made some number
of subsequent changes.
So we'll start with this checklist and then we'll go over the other checklist on how we actually do
the deployment.
So every single one of these items right here are all about getting our application ready to be executed
or hosted by Heroku.
So these are steps to make sure that our app is essentially Heroku compliant.
Now a lot of these steps are going to go through are actually used by many different providers.
And so this is one of those things where you kind of want to go through this checklist no matter what.
So let's briefly talk about each item and then actually implement it inside of our codebase.
Each of these items on here I think that you're going to have a pretty good sense of what's going on
even though we've only written the bare minimum amount of code and only explained a very small amount
of surface area of note and express.
So anyways let's get to it.
OK.
So the first thing is dynamic port binding.
So in a nutshell when we deploy our application Trochu Heroku is going to expect us to listen for incoming
HTP traffic on a very particular port.
Remember we had previously looked at this diagram right here and we had said that express would tell
node to listen to incoming HTP traffic on the specific port and we even coded it in port 5000 inside
of our codebase.
Remember with this line right here of Atlas and 5 0 0 0 0.
But whenever we deploy our application to Heroku Heroku will tell us which port we need to listen to.
So in other words Heroku is going to expose a very specific port to us and it's going to tell us hey
you have to listen to incoming traffic on this particular port.
This is done because Roku will host many different applications on a single server or a single machine
and it wants the ability to just dynamically tell us where traffic is going to be coming from now setting
up this dynamic port pin binding in practice is really straightforward.
So let's do it right now.
I'm going to flip back over to my code editor and download our apt.
Listen line right here.
We're going to add one additional line right above it.
That's going to dynamically figure out what port we should be listening to.
So I'm going to say right above it Konst port.
I'm going to spell port with all capital letters to make sure that it's really clear to any other engineer
who's looking at this in the future that this is some type of constant that should not be changed slightly.
We're then going to say that port is going to get its value from process.
Even the dot port.
OK.
So a little bit about this statement right here.
Whenever Heroku runs or application it has the ability to inject what are called environment variables
environment variables are variables that are set in the underlying runtime that node is running on top
of.
And it's essentially no Croker's opportunity to Passos runtime configuration or some configuration that
Heroku only wants to tell us after we have actually deployed our application so we can't look up on
Heroku what our port is going to be ahead of time.
We have to wait until essentially the very last second when our app is starting to be executed by Heroku
to figure out what the port is.
And that is what this statement right here does.
It says look at the underlying environment and see if they have declared a port for us to use.
Now the trick here is that if we are running in production.
So if Heroku is running our app then we can freely use this process.
NV port variable.
However if we are running our code inside of a development environment like on our machines like as
we are right now then this variable might not actually be defined.
So to handle the case in which we are running in a development environment we're going to add on a simple
boolean statement we're going to say 4 5 0 0 0 0 and like so.
So what this says is if there is an environment variable that has been already defined by Heroku go
ahead and sign that variable to port otherwise by default just use the value of 5000.
And so in our development environment we'll use 5000.
And production will use whatever port Heroku is attempting to provide to us.
So then on the next line when we decide what port to listen to rather than always listening to 5000
will listen to the port that we just calculated on line it will say port like so.
OK.
So that's one step done just a couple more to go the remainder on here are much more easy and a little
bit more straightforward than the one we just did.
So we really put the hardest one first.
The second step we have to go through is tell him Heroku exactly what version of node we want it to
use.
So remember the first video inside this course we had said that we are going to use a very specific
or at least a very up to date version of node because we are going to rely upon some very advanced features
or very new features of node by default Heroku attempts to use a little bit of an older version which
would definitely without a doubt crash if we attempted to run the completed version of our app on it.
So we're going to tell her Oku to use a very specific version of Node.
Again this is a pretty straightforward process.
I'm going to change back over to my code editor.
I'm going to open up my package.
It's on file and inside of this Jason object I'm going to add a new configuration block.
So right underneath main and right above scripts is a good place for this inside of double quotes and
do make sure.
Please please please make sure you are using double quotes here not single quotes.
We're going to say engines and then this is going to be another object we'll say node we want version
eight point eight point one or put a comma.
And I will say NPM.
And we want version 5.0 point 3 and then do make sure that you get a comma after the closing brace here
as well.
OK.
So please do triple check that you've got all your comments in here.
Very easy to miss one of them and do make sure that every single statement that you just put in here
every little line has a double quote around its single quotes will not work.
It has to be double.
OK so that's pretty much it.
Whenever Heroku boots up our application it will read in our package.
Some file and see if we have declared any versions for it to use.
And if we have Heroku is going to use that version whenever deploys our application.
OK let's move on to Step 3.
Specify a start script.
So when we deploy our application Heroku we have to tell Heroku what command it should run to start
up our server.
You can kind of imagine that between 20 different servers or 20 different applications there might be
20 different ways of starting them up and running them in production.
And so what we're going to do right here is tell Heroku exactly how it should startup our server to
do so.
We'll flip back over to our code editor still inside the package not just on file.
I'm going to find the section labeled as scripts.
I'm going to delete the existing test script inside of here and I will replace it with double quotes
start and then node index j us like so.
So this one probably won't be that big a surprise.
Remember we just started up our server like two sections ago by running the command node index.
Yes that attempts to call or run the index file using the no G-S runtime whenever Heroku attempts to
deploy or to run our application it will automatically attempt to run the start script right here.
And so we are essentially saying hey Heroku we understand that you're going to run a script called start
whenever you do execute this command right here and that's pretty much it.
I'll get down to the very last step here.
And then we can take a break and start the deployment.
So the last step is to create a dot get ignore file.
The purpose of this file is to make sure that we do not accidentally commit any of the dependencies
that we have created or installed.
Excuse me if we change back over to our code editor.
Remember that when we installed express dependency inside of our project it automatically created this
node modules directory where we got all these automatically install dependencies.
Traditionally we do not commit these dependencies or we do not transmit them over to get me to Heroku
when we attempt to deploy our application.
Rather we let Heroku install all of our dependencies itself.
So the purpose of a dot get ignore file is to make sure that we don't accidentally commit all of these
dependencies to source or to version control when we deploy our application.
So let's get to it.
This is give me another easy step inside of our project directory.
I'll make a new file called Daut get ignored.
Do make sure you get the dot on the very front there and then inside of this file We're going to add
the text node underscore modules and save it.
This essentially tells get which we will use in just a second to commit our project to and use as version
control to not attempt to commit the entire folder of node modules.
Don't touch it don't worry about saving it to get.
Just ignore it entirely.
OK.
So that's pretty much it for our pre-deployment checklist.
We've gone through all four steps.
So let's now take a break.
When we come back we'll run through our first time deployment checklist and then we will figure out
how we handle subsequent deployments.
So I'll see you in just a second.