In the last section we spoke about the need for two separate sets of resources inside of our application.
One set for development and once one set for production this is going to allow us to completely segregate
the two sets of resources so we can just absolutely tear apart our development stuff as often as we
want but not affect any of our production data.
So let's get to it in this section.
We're going to create a new Mongo database.
We're going to create a new Google API account and then we will set them both up inside of our project.
We've gone through both these steps previously.
So this time around we will speed through both the database creation and the API sign up to get started.
I'm going to flip over to my open in lab instance.
So if you have closed down your browser tab that contains your lab database.
Make sure you open it back up navigate to in lab dot com and we want to get back to our overall dashboard.
So click on the big link up here and you should see a list of all the different deployments.
Now on this list you should see e-mail the dash death.
So make sure you see that.
So we're going to create a completely separate database to house all of our production data so find
the create new button here on the right hand side.
We've gone through these steps before.
So let's do it very quickly.
I will select a sandbox.
I will hit continue.
I will select the closer region to me which is US east in my case.
We will continue.
And then I will give it a database name of email the dash Prod. which is short for production.
So we will continue Samit order and that's pretty much it.
Now the database will be created.
Now I remember just creating the database is not enough.
We also have to create a service account that can access that database so that our copy of mongoose
can essentially log in and make changes to the database.
So I find e-mail dash prod on this list right here.
Here is the connection you URL that we'll be using just a little bit.
So we'll leave that right there for now before we make use of it.
I will click on the user's tab.
We will add a new database user and then enter our database credentials.
Now to be 100 percent clear since this is a production version of our database it kind of goes without
saying that I would not want to use the same database credentials that are used on the development version.
That would definitely be bad practice.
So this would be a great case in which you might want to generate a very secure password or a very secure
user name.
In my case I'm just going to use an arbitrarily different user name.
I'm looking to use a simple password because this is a sample application that we're building here.
You know it's an application of course so it's not the worst thing in the world if someone can guess
this and hack your see me write the username so how can secure it can it be right.
Anyway as a database user name I'll say Stephen prod and I'll give it a password of password
and then I will create that account OK.
So that's pretty much it.
We now have our database user account created.
I still see the connection you are right here.
Now we're not going to copy this thing just yet.
I'm going to leave this tab open because we'll come back in a minute.
We start to organize all of our different assets since going to leave this up for right now and we'll
come back shortly.
So now that we have the database put together.
The second thing that we need to create is our production version of the Google API.
So this is going to be a separate set of API credentials that's going to house all of our actual production
users.
So remember how we do that previously in a new tab I will navigate to console dot developers dot Google
dot com.
Now once we end up here our e-mail dash dev project should be visible by default.
So here is email dush death.
So we're going to have to create a completely separate separate project to completely isolate these
things.
These two separate projects.
Now before we do that just one quick thing I want to mention when we create this separate project on
the Google API console you'll notice that I'm still logged in as the same user like myself and even
when we created the separate lab account I am still logged in as the same user.
And so you might if you really think through this it's entirely conceivable that someone could instead
of stealing our you know actual log in password or our connection here for the actual database.
It's entirely conceivable that someone could instead steal my lab credentials and then get access to
both databases and the same thing with the Google API.
Someone could steal these credentials as well right and sign in as me.
So of course that's always a possibility.
If you really wanted to help things securely it's not outside the realm of reasonability to say that
maybe you make a separate lab account with the extremely secure username password that you have never
used on any other service before.
Obviously you can really go overkill with this stuff.
But for us doing an happiness course we got to kind of draw the line somewhere.
OK.
So back over at the developer Council we will generate a brand new separate project so up with a dropdown
I will click this I will find the plus button on the top right to create a new project.
Now we get prompted for a project name to enter email the dash prod and then we will click Create.
Now very important.
Remember when you create a new project on the Google Dashboard it is not instantly created.
We have to wait for the actual creation process to finish.
And so here is a little notification waiting for things to complete and you will notice that I just
recorded this video 7 minutes ago and forgot to wait.
So I started making changes to email dush dev which is why I am very recording the video without that
mistake.
So don't do what I do right.
Anyways it looks like the project has now been created created so I will go back up to my project selector
and make sure that I change over to email the dash product right here.
K we are now inside of Emily dash Prod..
We have to do two separate things here.
We have to enable the API and then we have to generate a set of API credentials.
So a click Enable API.
We will search for the Google Plus API which is very poorly labeled for giving us access to the API.
So a click that on the screen will click and unable to give us access to accessing user credentials
with auth 2.0.
We will let that do its thing and then after that we will make sure that we generate our credentials.
So on the left tab credentials create credentials we want to make an oath client ID before we can do
that.
We have to configure the consent screen.
I know this entire set up is just madness.
So for your production application it definitely makes a lot more sense to spend a little bit of time
on the consent screen right here.
Like you know a completely reasonable to use a home page you Arel put an actual logo and all this other
stuff as well.
So if you really want to go all out with the production version of your app absolutely feel free to
pause the video here and maybe you put on some you or L or product logo you know whatever you want to
do.
And of course you can always come back later and change the settings as well.
And obviously for a real production application we would want to make sure that this is all set up very
nicely.
Okay.
So right now we really just need our product name.
I'm going to use e-mail.
This is shown to users.
So we're not going to say email Prod. you know that doesn't make sense to our users.
This is solely something to tell our users who are the who they are granting access to then down the
bottom.
What clicks save.
And then we can select our type of application.
So we'll say it's a web app we can leave the name the same.
Now something that's a little bit more challenging this time around is going to be our authorized origin
and our authorized redirect you or I and here's why.
Remember that authorized user redirect you are right there that redirects you or I is specifying what
the valid address is or what the valid you are Elazar that we can redirect the user back to after they
have gone through our auth process.
Now in the past when we previously set up these credentials we used localhost 5000 because that's where
we are running our local server.
However this time around we are generating a production set of credentials.
So when a user goes through the flow corresponding to this account right here they're going to be tied
to our Heroku application or the Heroku you are out.
So it will no longer be a redirect back to localhost 5000.
It's going to be a redirect back to our running Heroku instance.
Now the reason that this is kind of a problem right here is that you and I have completely different
Heroku addresses.
You have one that was automatically generated when you first deployed your app to Hoku.
And I have a completely different one.
So I think at this point.
Let's take a quick pause in the next section.
We're going to come right back to this.
So don't go anywhere.
We're going to come right back to this.
We will figure out what are correct.
Redirect your ideas and then make sure that we add it right in here.
So catch you in just a second.