So this time around, we want to get started setting up a handler to get a payment intent and adding
the associated root to our roots file, but before we do that, there's a few things in the API go the
main entry point for our back application that we probably can get rid of.
They're just leftovers from printed copy and paste.
And you probably noticed these and get rid of them on your own.
But if not, let's do it right now.
So, for example, online 14, we don't need CSA version because we're not going to be actually sending
Web pages.
We're just sending JSON, at least for now, which means down here we don't need a template cache because
we're not going to be creating templates and that's in the type application struct.
So let's get rid of that back up in the config struct.
We don't need this API field because this is the API, so we don't need the URL to the API.
So that's gone.
And the last thing is I created this variable version online 13.
So let's actually use that.
We'll just add that to the application config right down here in the main function.
So I'll say version and version.
All right, just a bit of cleanup.
So let's now create our handlers for the API.
We'll get started on that.
We might not finish at this time around, but we'll at least get started.
So in my API folder, I'll create a new file and I'll use the same naming convention I did for Route's.
I'll call it handlers dash API Dutko and we'll give it a package declaration package making.
And the first thing I'll do is just set up a couple of types because I know that I'm going to be receiving
information in JSON format and I know I'm going to be sending data back in JSON format.
So let's create a couple of types just to make things simpler for us.
So a creative type, first of all, for what I'm going to get from the front end and I'll call that
and call it whatever I want, but I'm going to call it stripe of payload because it's information about
Stripe and it's the payload that's coming to us and it's a struct.
And what kinds of things do I know that I'm going to need?
You can always modify this later on, but I know I'm going to need to know what currency I'm using.
So currency could be a string.
And in Jason, I'll call that currency all lowercase.
And we're also going to have to have the amount which will actually receive in the form of a string
and we'll cast it to what we needed to be after the fact.
And in JSON, I'll call that not surprisingly about.
So that's what we're getting and what are we going to send back, I'll call that type Jason response
and it will be a struct.
And what are we going to have in there?
Well, we'll just put in the things that I think I might need right now.
First of all, did everything work OK to be a boolean?
And in Jason, I'll call that.
OK, that will be true if things work the way that we expected and we can send a valid response and
it will be false if it's not, which means we probably want a message, which we'll call a string,
and then Jason will call that message and there might be some content I have to send.
So I'll call that string content string.
Jason will be content.
And finally, I often need to deal with an idea of some sort, I mean, this time around, but I'm going
to put it in there, I can always delete it.
If I don't need it, that will be an integer.
And in JSON, I'll call that.
OK, so let's format this good and now let's create a stub handler.
So I'll create a function and it will have the receiver of app type pointer to applications.
So we have access to our application configuration and so forth.
And I'll call this get payment content.
And since it's a handler has to have a response writer and a request.
So W will be my response writer.
W4 Right.
HDB response writer and our request is a pointer to HDB dot request.
OK, so for the moment let's just send some manually built JSON back to the end user.
So I'll create a variable which I'll call J.
And that will be of type Jason response and we'll just populate its fields and for now we'll just say
OK is true.
And let's just convert that to Jason and send it back, so I'll use the variable out because it's what
I'm writing out and I'll check for an error, that's a sign the value of from the JSON package and I'll
use Marschall indent just to make it easier to look at.
And we're going to Marshall J and Prefix and we'll put a few spaces on the indent check for an error
if error is not equal to nil.
I'll just use my error log from the app variable after error log print on the error and we just write
it out.
So let's set the header and our response rate.
Or we call the method header and we call set and we set the content type to be applications JSON, OK,
and we write it out.
Right.
And I won't even bother checking for the error because this is all going to change when we're done.
So what are we writing?
We're getting out.
So now we have a get payment content handler.
Let's go to our API roots and set one up for that.
So we'll say Mux to get four right now and we're going to get API to be in quotes API.
I'm going to prefix all of my API routes with API, which kind of makes sense.
And we'll call this payment Desh Intent.
Now down the road.
This will probably become a post, but for now I just want to make sure it works and I'm going to call
after it, get payment.
OK, so let's try this.
Let's open our terminal and we're in the correct directory.
I am I'm writing my ghostwrite project and I'll type go run dot slash cmd API and see if it all compiles.
And it does so it's on par four thousand one, so I can go to my Web browser and I should be able to
hit the API payment Dasch intent.
So I'll go to Firefox and I'll type in HTP Colon's localhost, Kolan four thousand and one API and get
payment Dasch content and we get some JSON back.
So there it is.
Firefox gives it to me in this format, but we can look at the raw data and there it is.
So we have an OK set to true and everything else has the default values.
In other words, they're empty.
So that works really well.
Now it's going to be a pain to be stopping and starting this application, this back end application
all the time.
If I need to have things like the Stripe's Secret key, for example.
So here's where we're going to use a makefile.
And this is why we installed make way back when now I'm on a Mac.
As I record this, I'm going to stop this application.
But in the course resources for this lecture, you'll find two versions of Makefile, one for Mac and
one for Windows.
So download the Makefile and make sure it starts with a capital M and the rest of the file name is lowercase,
just like I have right here.
Makefile, put that in the root level of your application and you'll be able to do things like this.
So I'll clear the screen and I'll type make start underscore back and it will run the back.
It will build it and run it.
Now the front end I'm typically going to be using er when I work on it, when I'm working on the front
end and I'll have the back end running this way.
And it's just really easy to start at using Mac and I can actually it's running in the background so
I can return if I want to stop it.
I can say make stop underscore back and you'll see, let's open this makefile up and have a look at
it.
This is a really convenient way of doing common tasks that you have to do.
Now, this is a really simple make file.
First thing to note, at the very top, you have to have your stripe secret, your test secret and your
stripe key, your test key.
Mine are in there right now.
And as I said a while ago, before I make this course alive, I'm going to regenerate those keys so
they won't work and you can't use them.
And the version that you're downloading has nothing after the equal sign for the first two lines.
So get your test key and put it in the appropriate place and get your test secret and put it in the
appropriate place and make sure that you get the secret key next to stripe secret and secret keys.
Always start with České Underscore and your test key and put that next to stripe underscore key and
test keys or keys.
Always start with pick your publishable key.
OK, so make sure you get them in the right place.
If not, you'll just get error messages when you start working with Stripe and I often get them in the
wrong place, but try to avoid that.
The next two lines give you your ports go stripe is the front end.
I want that to listen.
I'm four thousand.
You can use whatever you wish.
And the back end.
I want to listen on port four thousand and one.
So we're looking at the Mac or Linux version of this right now.
The Windows version will look different, but it has the same basic commands.
So you can say make clean to clean all the binaries.
You can say make build front, which will compile the front end, make build back, will compile the
back end and so on and so forth.
Then you have simple ones like START, which will start both the front and the back end.
And since start calls start front, start front will actually build the front end first, then start
it and start back, will build the back end and then start it and so on and so forth.
This is really, really straightforward.
So what I'm working on the front end.
I'll usually run the front end with air and run the back end.
I'll just use make to keep it going.
And when I'm working on the back end, I'll run the back end with air and keep the front end going.
So that's entirely up to you.
Whether you use this or not, it's certainly optional.
But I find that the makefile makes your life ever so much easier.
So that's what I'm going to be using for the remainder of this course.
I'll be using this makefile a great deal.
And if you choose to do so, it I think it will make your life easier.
But again, it's optional.
So right now we have a stub handler for getting a payment intent in the back end and we have a route
to it and then we have a new makefile.
So let's move on and actually write the necessary code to make this handler functional.