Now that we are all done with the main phase of authentication inside of our application I think that
we are at a pretty good spot where we should think about deploying our application off to Roku again
and deploying all this new code that we have now added to our project before we do so.
However there's one quick thing that I want to mention to you about exactly how our application is set
up.
So as a reminder inside of our config directory we've got that piece not just file and this file contains
all of the different configuration API keys you our eyes cookie keys all this stuff around our application.
So the way that we're set up right now is going to eventually maybe lead us into a little bit of trouble.
And let me tell you why.
At present we've got one set of all these keys.
I'm going to suggest that we should instead have two separate sets of keys.
So in the development development world like on your laptop on our laptops on our active development
machines we should have one set of keys for Mongo D-B for our Google API and for all the cookies that
we're handling and then we should have a completely separate and different set of keys for our production
environment which would be our Heroku deployment.
So there's two very good reasons for taking this approach of having the two separate sets of keys.
The first reason is that when we use production keys like this we can store all these keys remotely
on Heroku servers all the developer keys can still remain on our own personal laptops.
Now this is a very good approach because our developer laptops like your physical laptop right now it
is not at all outside the realm of possibility that you might at some point in time lose your laptop
or really have it stolen.
And that's what I'm really talking about.
So on your local machine right now you have a plain text file with all of these different API keys.
It is not outside the realm of possibility of someone stealing your laptop finding this file right here.
And then all of a sudden having direct access to your Mangu database the entire Google API or at least
your slice of it and be able to decrypt any keys that you or any cookies that you have issued to your
users.
Now if you have a separate set of keys for production that is only stored on Heroku then it doesn't
matter if your laptop gets stolen or someone grabs the contents of this file right here.
If someone finds your test database credentials will whatever just delete the test database and start
over again.
So again one reason that we're going to split off to having two separate sets here is that allows it
allows us to be a little bit more willy nilly or a little bit more relaxed.
I should say with our development credentials Now the other reason that we're going to split this into
two sets of keys is that allows us to have two separate Mongo databases.
And that is very important whenever we deploy our production or application to production.
We want to have a clean database existing in production that has only our users data and we always treat
that as absolute pristine data that we will never manually mess around with at any given time.
But in the development world if we have a separate database we can decide to add records and delete
records we can delete collections we can create collections we can change everything.
As much as we want without having any fear of accidentally breaking all of our users production data.
So having two sets of keys like this and two sets of resources is a great way to make sure that you
can do development on your local machine and not accidentally break some very important pieces of your
production application.
Now I do want to make sure that's really clear the vast majority of all production applications in the
world should do.
I'm going to say do or at least should take a similar approach to this.
So if you're working at a company that has you working on development with production data.
I'm sorry I've got to say that's kind of dangerous.
Just my opinion.
Maybe you've got some one off case but off the top of my head I'm going to say it's kind of dangerous.
OK.
So anyways our goal here is to separate out the two separate sets of keys and now just to kind of dive
into the details of exactly how we're going to handle this.
We're going to look at one other diagram right here.
And we looked at this diagram a little bit of go a little bit ago when we initially put together that
he's not js file and we said that we were going to do a refactor to it at some point in the future.
So here's what's going to happen inside of our key file.
We are no longer going to store all of our raw API keys.
Instead we will ask a little question are we currently running in our development environment or our
production environment.
And then depending on which one we're running we're going to return a different file.
So in one case we'll return dev.
Yes and the other case will return maybe like proj us and inside of that file we will reference a bunch
of different environment variables.
So we have to talk about exactly what these environment variables are and how we're going to set them
up on Heroku.
But that's pretty straightforward.
So right now let's take a quick break.
When we come back in the next section we'll start putting this structure here together and then one
other quick thing that I want to say just to make sure it's clear we are going to have to set up a separate
Mago database to separate Google's API count and the separate key.
So yeah sometimes it's a pain to do all this stuff.
But again there's a very good reason to go through all of it.
So let's take a break and then take care of all this stuff in the next section.