- [Jon] In a previous lecture, I introduced to you Lambda, or did a demonstration with you of Lambda, with CloudWatch logs of this example.com application. The next piece that we need to integrate in here is API Gateway. So, API Gateway is going to receive a request. This request is going to be on the slash resource, and it will be a GET request with a query string parameter of "name" being passed in. So, let's go into console, and go and take a look. In the API Gateway, I'll click the Get Started button, which will say hey, do you want to create an example API? Not really. I want to create a brand new API. I'll give it a name, called the "HelloName" API, of type endpoint Regional. I'll create that API. Now, in my resources, on the slash, I'll create a new method that will be of type GET, and I want this GET request to send the data into a Lambda function that is called the HelloName Lambda function. I am also going to make use of the Lambda Proxy Integration. The Lambda Proxy Integration automatically takes the input request, packages that into a JSON payload, and sends that into Lambda. We may have to do a few tweaks in the Lambda function to adapt for this type of payload being sent in there. But first, let me save this this setup right here. When I hit the Save button, it says Add Permission to Lambda Function. Yes. API Gateway needs to have access to call that Lambda function, but only your API Gateway needs to have access to it. So before I click the OK button, I want to go back into my Lambda console, and then show you the current permission of this Lambda function. So, I click on that view permission button right here, and then I can see under the function policy that this Lambda function's policy is empty, which means no one is allowed to invoke this Lambda function unless they have IAM permissions. Well, let me go back into the API Gateway console, and click the OK button. I'll go back again into the Lambda console, hit the Refresh button, click on that view permissions, and I can now see that API Gateway has access to call my Lambda function. My resource is right here on the right, HelloName. he SourceArn ends with qae and GET request. Let's go to be API Gateway. I can see qae and then the GET request. So, only my API Gateway that I have just created is allowed to invoke this Lambda function. That's why this ARN is very important to have inside of your function policy. So, you can always let API Gateway do that for you automatically, or you can do that manually yourself. So, the next step here is the Method Request. In the Method Request, I need to specify that there is a name parameter being inputted. So, in the URL Query String Parameters, I'm going to add a query string called "name," and I'll say this one is required. Now, I am ready to test this API Gateway. However, I don't know if you remember what I said about that Lambda proxy integration. But, because API Gateway sends its data into Lambda via automatically packaging everything up into a JSON payload, the name parameter may not be passed the same way as how I've done my test in the first place. In fact, we're going to need to go and modify our code. We should create a brand new test for this though. It needs to be sent from API Gateway. So, I'll configure a brand new test event here, and I am going to create this new test event, and use an event template of API Gateway AWS Proxy. I will need to specify a name here. HelloNameAPITest, and you can see that there's a lot more data being passed. One of the important pieces here is the queryStringParameters. The queryStringParameters is an element that API Gateway is creating for us, and this is where it will add the name queryStringParameters that gets added with the value that I want it to have. So, in our code, we cannot just say event.name anymore. I'm going to need to say, event.queryStringParameters.name, because this is where now that query string is located. So, I'll save this test, will create this test, and I'll go into my Lambda function, HelloName. Go into my Lambda function, and I'll modify it with my event.queryStringParameters.name. I'll save it, and hit the Test button. Go back to the top, and it now says "Hello jon." So, we're good. It should work with API Gateway. We've created our test. Well, the best way to know that is to go test it from the API Gateway console. Let's go there. In API Gateway, there is a Test button right here. I'll use the input my name parameter, name=jonathon. I'll click the Test button at the bottom of the page. I get the data back. Latency was 21 milliseconds, and in the response body, it says "Hello jonathan." So, API Gateway is able to invoke Lambda, and Lambda was able to get the data that the queryStringParameters name from the event payload. The last step here is to deploy this API Gateway, because I'm not going to give access to the console for my users and them coming in into here and doing this test themselves. I want them to be able to use a URL in there. So, I'll click Action > Deploy API. I need to create a new deployment stage, you've learned these with Wes in a previous lecture. So, today, I feel a little bit cowboy, so we're going to deploy right away in prod, don't do that at home though, and hit the Deploy button. I now have my invoke URL that I can copy and input my name parameter with "hopethisworks." And what I get back is "Hello hopethisworks." So, API Gateway was able to, I was able to, deploy my API Gateway in prod, and now any user who has this URL that want to pass this query string can now use my brilliant HelloName application that will now be used from the entire world. No need to scale Lambda. No need to worry about API Gateway scaling. All of that is managed for me. That's the beauty of serverless here. So in our next lecture, Rick is going to introduce you to the exercise, which will take a lot of everything that you have learned in the last few modules and integrate them, and do an exercise around Lambda.
