In the last video we install the re-act stripe.
Check out library to the client side of our project.
We're now going to change back into the server side and start the project back up with NPM run dev like
so.
OK.
So let's think about how to tackle all this stuff.
We first have to take care of some configuration on the front end.
After we set up all this reac stripe check out Stuy stuff on the front end.
We'll then move to taking care of everything on the back end as well.
Now to make use of the re-act stripe check out library we first have to make sure that the available
API keys specifically the publishable key is available to the reac stripe check out library.
So this key right here is a requirement of check out yes we have to have it available on the front end
of our application.
The back end similarly wants the publishable key and the secret key in this video.
I think that we should just go through the entire process of putting all these different keys into the
right places so that we don't have to come back later and access these keys again at some point in the
future.
So in this video we're going to make sure these keys get put onto our server side configuration and
our client side is going to take care of all of it right now.
We'll start off first with the server side stuff because we are familiar with how keys are handled on
the server side.
If you recall we have our config folder inside of there is the dev J.S. file and the Prod. J.S. file.
So both of these the dev side has all the Rockies intend for use the development environment and the
Prod. side pulls keys from our Heroku environment variables.
So let's do the setup.
Let's just get this done with because it's basically going to be a lot of copy paste.
So I'm going to flip back over to my stripe dashboard.
Here's my publishable key.
I'm going to copy the key.
I'm going to change back over to my dev dot J.S. file first.
It's going to take care of dev genius first.
Now going to make sure that I add a comma at the end of the cookie key line because we're going to add
a new property inside of here.
So the first one that we're going to take care of is going to be Strype publishable key and we'll paste
the publishable key.
So you should see right there.
Short for publishable we'll make sure that we get a comma at the end and then we will also pull in the
secret key.
So here's my secret key I'll copy it change back over to Deb.
Yes and we'll do Strype secret key and then paste that one.
OK.
Before we change away from this file I have to ask you very carefully please make sure every line has
a comma where appropriate.
Please make sure you spelt the word publishable correctly.
If you make any mistakes at this point we're not going to be making use of these keys anytime soon.
OK we're going to take care of the client side stuff first and then come to the server side stuff.
So if you make any typos here or anything like that it's going to be really hard to debug because we
won't start to see any error messages around it until we later on.
So please triple check your spelling here.
OK so there's the dev JSA File.
We're all done with this one so I'm going to close this file out and we're going to take care of the
project file.
So remember all the keys inside of here are for use in production and they are all sourced from our
Heroku config.
Heroku environment variables.
However we do have to still set up the relationship.
So after cookee key put a comma down we'll say Strype public or something.
Streite publish of all key is process done.
Ian V Strype publishable key.
Well make sure we get the comma Strype secret key is processed.
Even the dot stripe secret key like so OK.
Again I got to ask you please triple check your spelling of publishable here so you should see a publishable
one and publishable too.
Right here make sure you they are spelled correctly because this is going to be really hard to debug
at some point in the future.
OK so now the last thing we do on the server side is make sure that the Heroku development works and
the Hiroko environment has these different environment keys set up correctly.
So we're going to open up our Heroku dashboard so we'll make a new tab I'll navigate to Heroku dot com
and I'm going to find the dashboard for my current project that's running our e-mail application so
mine is called agile by you.
If you recall yours is likely called something else so you'll want to pull your application up and then
remember how we add on environment variables.
We're going to follow the Settings tab right here.
We will find reveal config variables and then we will add them onto this list.
OK so we're going to first flip back over to the product G-S file and we're going to copy the property
names here to just really ensure that we don't actually accidentally make any typos.
So I will select Strype publishable key I'll copy it I'll add it as a new key.
I'll then go back to my striped dashboard.
I will grab the public key right here or copy it and paste the value.
So you should now see publishable key.
Lining up with P.K. right here.
You should see it.
OK.
So we'll add that and it will do the same process for the secret key as well.
So here's Strype secret key.
Copy that.
I'll paste it.
Now we're going to go back over to the striped dashboard grabbed the secret key right here and paste
it as a value.
OK.
So one more time.
P.K. appear OK down here.
S.K. being short for secret key.
And then the last step.
Don't forget this one.
Very important.
Make sure you click at.
OK.
So that looks good.
We've now got our Strype environment variables set up correctly on the back end of both our development
environment and our Heroku instance.
So not going to close the Heroku dashboard and now we can start to think about how we're going to handle
all this environment variable stuff on the front end.
So again I want to remind you that this config folder right here and all the configuration side of it
is strictly for the back end of our application.
We are not going to use this config folder for anything on the front it nothing on the front end.
And the reason for that is that yes we have these development and production keys are these separate
files right here.
But inside of the re-act world it is the front end of our application.
Any file that gets required into our reaction a project like any file it gets required in is going to
have its contents publicly visible to the outside world.
So in other words if we somehow required in this dev dot file to our client side application all the
keys inside of here would be accessible to the outside world.
Because this entire file would be pulled into the client side project when we required it.
So again we make sure that the config for our server side is distinctly different and distinctly separate
from the config for our not server side the the front end that's when it's called.
OK.
So it then mind we are not going use the same directory we're not going to use the same set up here.
And believe it or not there's actually one other big issue here.
You might be thinking OK Stephen whatever who cares let's make a config folder in the client directory
and make the stuff happen.
Well there's one other big issue.
So let me tell you about what the other big issue is.
If we open up our config key is not Geass file.
You'll recall how we settle this stuff up.
We said if we're in production required this file and export it.
If we are in not production essentially require this file and export it.
So you might be thinking.
All right that's fine.
We'll make the separate config folder will do the same set up on the front end as well.
Well here is the problem with that approach.
On the front end of our application and it is going to seem really esoteric or kind of strange by the
way but it's really fine on the front end of our application.
If you recall we are making use of yes 20:15 modules.
So like let's open up the SIRC folder.
Find the index dot jazz file.
Check it out.
Yes 2015 modules use 20:15 modules are characterized by import statements like this and export default
statements as well like this one right here.
So the front end of our application is making use of yes 20:15 modules the back end as we've said previously
is making use of common G-S modules which are characterized by require statements or their require function
like this right here.
Now here's why I bring this up.
Here's what the problem is with common.
Yes modules like this right here.
We can have some amount of logic executed before we decide what file to require in how ever when we
make use of.
Yes 20:15 modules.
You are not allowed to execute any type of logic whatsoever.
Before listing and import statements.
So in other words on the client side of our project because we are using as 20:15 modules we can't put
in a check like this to say hey if we are in production bring in this file but if we are not in production
bring in this other one we cannot have that layer of logic inside of the client side of our application.
So obviously that's not the best thing in the world and it's going to just slightly kind of complicate
our lives a little bit.
Fortunately the Create react up project that we are making use of.
Remember we used create re-act up to generate our client side project has a good solution for.
AP he's just like what we need.
So let's take a quick break.
When we come back we're going to look at some of the Create react out documentation and we'll talk about
exactly how create re-act out is going to help us in defining some secret API keys and all this kind
of good stuff.
So let's get to it in the next section.
I'll see you in just a minute.