All right.
Welcome back.
So in this video we're going to address the problem that I mentioned in the last video which is that
right now we're using one database between our local cloud nine development environment and our production
environment on Heroku.
So our deployed code is using the same database that our testing ground is which is really not a great
idea.
Things work fine it's not a problem in the sense that our code is broken or that we can't get by using
this way but it's really not a good practice because we don't want to have one database where you know
if we have a big application our main database with all of our users that's deployed.
We don't want to be testing things and screwing around and adding new features accidentally deleting
entries in the database or deleting the entire database.
In our development environment.
So you want to keep those separate.
And just to demonstrate right now what we have going on.
I have remember that what we did was we updated our code rather than using the local hosts.
You can't feed 10 or whatever database you or you had there but the local version on cloud 9 we updated
it to be Mangu lab.
And this is our Mongo lab instance and it's the same one we have this running locally right now.
And on Heroku so I'll just refresh the page on both.
This is Heroku deploy as you can see we have one rodeo beach and we have rodeo beach again just to prove
that they are connected of course.
Let's add a new campground over here.
The name for this one will be Kirby cove.
I'll just use this image here which is one that I took a few nights ago totally shameless plug.
Nothing you can do about it.
So I'm going to copy that paste that here and just put blah blah blah auto complete.
Thank you.
Chrome click submit.
All right so we have this here on Heroku.
And I refresh.
I have the same Kirby code created here locally.
So it's not even about catastrophic events.
When a developer could accidentally delete the entire database.
Let's see that.
Let's say I wanted to test a feature I wanted to know is delete working on my delete route's working
.
Well if I go in here and if I deleted something which I'm not signed in but if I did delete this I'm
also deleting it from production which means that I'm deleting someone's actual data which is never
good.
So it's really a good idea to have separate databases.
So one way of fixing this problem is just to go back to cloud 9 and just on cloud nine switch.
Well we're using here so that we're now using the camp localhost version again to save restart the server
here and now on cloud 9 5 refresh.
You'll see that we're using the old version or what we were using before the local version and on Heroku
we're still using the Monga lab instance because right now they're out of sync.
We have changes that we made locally on cloud 9 that we haven't pushed to her OK.
And this is fine.
This will work it's valid but it's kind of annoying because if I do want to let's say added a new feature
I change the C S S and I want to update that on Heroku.
Well then I'm going to have to figure out what I'm going to do about our database you know.
I'm going to have to comment this out comment that or recommit on uncomment that one save and command
all of that push it to Heroku And then if I wanted to add a new feature locally again or test something
out.
I comment that and uncomment this and it's just it's really not a good solution at all.
However there is another solution or another approach that we can take.
And basically what we're going to do is write some code that says if we're in production run or set
the database you are out to this.
Otherwise set it to be this here.
Now it's not actually going to be an if statement.
And we're not technically checking if we're in production if we're in or if we're on Heroku.
It's a little bit different.
What we're going to do is make use of something called environment variables.
So we've seen them before.
This little line right here which reviews and every Express app process does envy port process that
EMV IP.
So what this means right here what this.
And I went over this briefly but I think you'll make a little more sense now that you have some more
experience under your belt.
What this refers to is the environment where this code is being run.
So process that you envied up port on cloud nine may maybe different than process that dot port on her
Roku probably is IP definitely is.
So these are ways of adding variables that are not hard coded things that change based off of the environment
they're being run in.
So we could have put something like 80 80 here.
But of course that's hardcoded.
That's not dynamic.
This allows us to have variables that respond to the environment and in node in javascript will actually
just a node.
They always start with process D-NV that's how you access them.
And then the name of the variable.
So what we're going to do here is have an environment variable that will call database Yoro and on Heroku
we're going to set database you are able to be this long thing here and then all will have to do is
basically write process
in the database you are.
And that will refer to the correct you URL for our given environment.
And then we'll do the same thing here.
We're well set on cloud nine database you Arel to be Mongar D-B colon slash us localhost she can Campfield
10.
So again the idea is that we can create an environment variable which I haven't shown you how to do
.
This is just how you access them.
But remember this is coming from outside of this application.
This is coming from the actual application or the actual environment the server that we're running the
code on.
So to demonstrate how we make this work I'm going to start by going over here closing out and I'm going
to create a new environment variable in the command line in the environment when a type export is a
new command and then I'm going to write my environment variable which usually the convention has to
do in all caps.
As you can see here IP port.
So we'll do data base.
You are all equals and we're going to start resetting it equal to what we want to run on our cloud nine
instance what we want the database you are all to be equal to.
Just like that and hit enter
to check if that were.
Going to do this right here actually right here.
Cancel that log process.
Daddy envy.
And this needs to match data base you know.
And if we see this Mongar D-B Colon's blah blah blah local host of Canvey 10 spit back out or printed
out then we know that we've successfully set up the development database you know.
So let's see what happens node.
Yes there we go see that it was printed out here.
I never said print out localhost.
You can pretend.
I said the environment variable database you are up.
So now all we need to do is say Mangeshkar connect to process NVI
database.
You IRA and then on Heroku we need to go update database you know to be this Mongo lab giant You are
all string but we only want that to happen on Heroku.
We want to leave this alone on cloud nine.
So let's just make sure it works so vocalise a restart.
Great.
Let's go to our correct version here refresh and we're still getting the local code Heroku of course
is unchanged because we haven't pushed any code to Heroku.
So now if we save this and add and commit
say update the you IRL
get push Heroku M..
If we try and run the Heroku version right now if I as soon as this finishes at least if I try and refresh
this page I'm going to have an error because Heroku are the servers that would be able to find process
study and vidette database you know because it's not set up.
So just to show you that refresh might take a bit and they should get application error and while that's
going out there we go.
Application error again if you really want to know exactly what's happening.
It's Heroku logs
and you can see here I don't know how useful the error message that we get will be honestly.
Let's see.
This might be one of those messages that doesn't tell you exactly what you had hoped but it's telling
us Mongar D-B there's an error.
Yesso doesn't it doesn't explicitly mention that this database you are is a problem because what's actually
happening is that it's trying to connect to an empty string most likely which technically isn't a problem
except for the fact that there is no database located at the you are an empty string.
So it's sort of a unexpected error message.
So I am telling you though that the problem is that we haven't set up a process to or that we haven't
set up the environment variable on Heroku.
So to do that there's a few different ways we can do it if we go to Heroku itself.
I'll probably need to log back in here I refresh the page.
Nope I didn't need to lie back in.
Here's our app.
Well if we go in and we go into settings I believe it is.
And then keep scrolling down or go to config variables.
We can add in a variable here.
So we want database you Earl to be that giant string.
I copied it and click add.
And if we go back now try refreshing the page.
It works perfectly OK.
So that's one way of doing it.
I showed you how to go on to Heroku and add in a key value pair database you Erlass and the key or the
name of the variable the environment variable and then a value.
That's one way of doing it the other way of doing it is through the command line you can run a command
.
We can do this right here.
I have the No.
J.S. support docs open on Heroku this line Heroku config colon set and then key equals value.
So I'll just copy this first bit if we want to I'm not going to actually do that.
The I'm not going to hit enter but I just want to show you it would be Heroku config Kolin set and then
database you are l equals and then we had paste that you are up.
But am I going to do that.
So another thing I haven't mentioned yet is that there's another good reason for using environment variables
which is that there are hidden there they're not exposed to whatever it is developers if you put this
code up on good hub.
We don't want to have our database you rl right here of course or if you already know no my database
you are.
But this isn't obviously a real app.
But if this was a real application even if it's an open source application or parts of my code or open
source I don't want to be exposing my data or my database you are out to everybody who looks at the
code.
So by having this line here Mongar start connect process that the NV dot database you arow that's no
longer an issue.
So that this is all that a developer would see or anyone browsing the code on get home and they would
have to set up their own database.
You are all in using environment variables.
OK.
So let's recap what we did.
We started by having the issue the problem of one database for development and production a shared database
to fix that.
We set up our database URL environment variables locally on cloud nine and on two different values for
the same variable.
And then we accessed that variable the environment variable using process that ENVI database you IRL
and we connect to that.
So we have two outcomes.
One thing that I will mention is that it is worth setting up a default value.
So let's say that I somehow screwed my app up if I restart my computer.
I don't know I reset this workspace in my environment variable is gone or I'm sending this to someone
and I want them to have I don't know a default database that they could use just to make it so that
the code doesn't completely break if I haven't explicitly set this up.
What I can do is add in a little backup so we'll make a variable and we'll just call it.
You are all equals and we're going to do process started in the database you are real or.
And then we'll put some you are out there so let's do what was are you are ELLYARD already lost it.
There you are.
So this will just be a backup.
So again what's happening here is it's not mandatory doesn't change the functionality but if for some
reason my environment variable got screwed up or it didn't exist.
Rather than breaking the code what will happen is that this you are all variable it's going to be equal
to the environment variable if it exists.
If it's an empty string though or if it doesn't exist then it's going to be equal to this which is just
our backup.
In this case on cloud nine there are the exact same thing.
It's really not mandatory again.
It's just kind of a good practice to have in case something went wrong.
But really I'm just showing it to you because it's pretty common to see this as well.
OK.
So kind of long winded or no circuitous way of approaching this but it all boils down to the fact that
we want different databases process that in vidette database you IRL is how we access environment variables
from a node app.
You want to make it clear though environment variables are not a node thing or a javascript thing.
Ruby applications rails applications Python apps they all can access environment variables and in all
they look relatively simple similar to this it just happens that in node you write process in vi in
other languages like Ruby.
You'll often see something like ENV database you know.
So it is a universal concept it's not a node specific thing and it's universal across all sorts of applications
as well.
You don't just use this for database URLs use it anytime you you want to.
It looks like a typo here.
Either way it should be localhost.
Use this any time you want to have different information between your different environments development
or production.
You also use this when you want to hide or obscure information from someone and get help for instance
.
So if you had your paypal or your Strype credit card processing API information inside of your application
because you needed it for the code.
Well if you want to share your current get how you obviously don't want to be pushing that up.
So what you can do is create an environment variable and do something like process.
Ian VI died super sensitive information and that's a way to get around that problem of wanting to share
your code make it public but also not wanting to share your super sensitive information where someone
could take your your API key and run up a bill of thousands and thousands of dollars which actually
happens some of the bigger companies are much better about policing that.
So Amazon for instance if you have your Amazon API key or your AWOS information your Amazon Web Services
web services information on get hobe they actually will know and they'll send you a message saying you
need to take this down immediately or are going to disable it.
Someone could charge thousands and thousands of dollars to this.
They could use you or basically your account to run off a huge bill that they don't have to pay.
Happens relatively often.
I've heard of some students having that problem and of mine and promise but definitely I've heard of
that before.
All right.
So process the envy is how we access environment variables.
We have two databases set up camp has now deployed two different databases.
They don't share any information which is how we want it.
Awesome