In this video, Jeff Winesett demonstrates how to deploy the Amazon Gateway for external use and testing. Once deployed, CORS settings are added to allow a single page web app to connect with Amazon gateway API.
- [Instructor] OK, the last thing I want to show is actually testing the API externally. If you recall we tested our lambda function directly against the DynamoDB table, then we tested the API internally, and now I wanna test it externally. And the first thing I need to do to do that is I have to deploy the API to make it externally accessible. So, I'll go to the API Gateway, I'll chose the demo microservice API, and to deploy I go up here to actions and I choose deploy API.
I give it a deployment stage, let me call this stage test, and just a test environment. And deployment description, this deployment is version 1.0 initial deployment. D-e-p-l-o-y, alright and deploy. Now my test stage is deployed.
I've got any of these options available to me, that's what the DynamoDB CRUD function provides. And, I've got this invoke URL that's available to me right here. So, this is gonna be important for me to test out the API. I wanna be testing out POST, so in order to post information externally to the API, which will then invoke the lambda function, which will then save to a DynamoDB table that we created. So, let me grab this, copy that.
And in order to use curl, I need to toggle over to the command line, and actually I've already included in the exercise file the little snippet of curl that you'll need. All you'll need to replace is the actual gateway API that we just cut and pasted there. So let me do that. It's basically gonna be doing a curl command with the right information that it needs to do a post with the data formatted as needed. And you can see I've got the table name and thing ID and curltest, so I'll copy that, move back over to the command line, and I'll be using, like I said, curl, and this should be adding in the thing ID curltest into our things table.
So, let me hit enter. OK, again we got back this blank jSON notation indicating success, as I've done in the other cases, let me verify that curltest was actually added to DynamoDB, so I'd do that by toggling back to services back to DynamoDB, go into the table that I created, things, items, and sure enough curltest. So, the external testing of the API has been successful.
The final thing that I wanted to do was get this little application working, as I mentioned before. And the only thing that we have to do there is, we need to make a couple changes in the source code files, really just one change, to where the form is posting to, which is exactly our new gateway API URL. So if I go ahead and, just to remind you where to get that again, go to services, gateway, go into the gateway, go into stages this time, I'm looking at the test stage, and I wanna be doing a post.
So once again I'll make sure that I have this correct URL. I'll copy that. Now I can go over to the exercise files and in our serverless frontend app files, I've got a bundle.js and an index.html. So all I need to do is, I'll use whatever the default is here, I need to go into this code, and I just need to change the form action where the form is posting to, and I need to make sure that it's posting to the URL that I sent, and once I've got that, I need to save, so that's over in S3, that's where we're hosting our application.
I'll go into the bucket that's hosting it right there. We see we've just got the index.html, I need to actually upload the two files now, bundle.js and index.html, I'll choose those, I'll click next, I'll make sure that they can be read by everyone. Click next, everything else is just fine and upload. OK, and with these two files now in place our application has basically been updated with the information that it needs to make requests to the API.
The cross origin research sharing or CORES mechanism gives web servers cross domain access controls, which enables security cross domain transfers. So, I actually have to set things up to allow this to happen. So let me show how to go about doing that. What we need to do is we need to toggle back to the API, Gateway API, choose the API that we have in place, and then when I choose the options down here under the methods, I can actually start to enable CORES right here in the actions drop down.
So, this would be the normal way that you would go about enabling CORES for any of your normal get, put, post methods on the API. Now there's a little bit of a wrinkle with this particular situation, because we used a blueprint that set up a lambda function that really just has any method, any of the methods come in, we're passing in the method actually in our jSON payload, and it's parsing that and dealing with the method that way, so that's why it's got this, any method can come in to this API.
Now according to Amazon's documentation, if you try to enable the enable CORES via this method on the any method, it won't work. It explicitly says, when applying the CORES enable CORES to the any method in a proxy integration, any applicable CORES headers will not be set, instead I have to rely on the integration backend to return the applicable CORES headers. So, I have to actually go back into my lambda function and I need to add in the right kind of header information to get this to work.
Real quick, go into lambda, go into my specific function and now I can see in the Chrome browser my scroll bars are working. I'm sure they will get this fixed, even by the time you're watching this video. So, it may be a non-issue by then. Let me move on. So, in this case, I need to find the place in the code where it's setting applicable headers. That's right here, so all I need to do is add another one. I need to add the access control allow origin, and I want to allow from any where.
OK, with this change in place and it saved, I can open up a new tab and test out our app again. Just as a reminder, I'll go grab that URL again, I don't have it memorized. I go in here, properties, go into the static website hosting. There it is, so let me pop that in, alright. What I'm seeing is, is that I'm seeing this form display, first of all it's gitting back, so it's using the Git, it's hitting the API with the Git command, the Git htp method, and it's getting back all of the data that's in our DynamoDB table, which is exactly what we've already added.
We added car, curltest, apitest and lambdatest. Let me add one more test, websitetest. Let me add this thing. Well it's showing me that it's there, it did a Git, let's make sure. We go back over here to services, DynamoDB, and tables, things, items, websitetest. Great, so we've actually shown the end to end working of something from the browser into the gateway API, which is invoking a lambda function.
Which is saving data to a DynamoDB table, and actually getting that data back, as we saw in this listing here. So, that concludes this serverless microservices architecture application, similar to what we did before when we did it all manually, then we did it through Elastic Beanstalk, and now we went serverless. Mission accomplished.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures