Build a serverless API with Amazon Lambda and API Gateway | by André Ribeiro | Towards Data Science

IntroductionCreate a spelling and grammar corrector using GingerItDeploy the Python service to LambdaAssociate an API Gateway with LambdaSecure and throttle the API with API keysConclusionReferences
Introduction
Create a spelling and grammar corrector using GingerIt
Deploy the Python service to Lambda
Associate an API Gateway with Lambda
Secure and throttle the API with API keys
Conclusion
References
In my previous article “Build a serverless website using Amazon S3 and Route 53”1 I demonstrated how to build a serverless website comprised of static (client-side) content. This approach allows to easily scale a website from 10’s to 1000’s while keeping costs low.
To extend serverless to dynamic (server-side) content, Amazon Web Services (AWS) offers further services such as AWS Lambda. Together with API Gateway, one can create RESTful APIs that enable real-time two-way communication applications.
In this post, we’ll cover how to create and deploy a spelling and grammar correction app using AWS Lambda, and respond to standard HTTP requests through API Gateway.
GingerIt2 is an AI-powered open-sourced Python package developed to help correct spelling and grammatical mistakes in your text, based on the context of the complete sentence.
To use it, let’s start by creating a virtual environment and install GingerIt in it.
To test it, in the terminal run the following snippet.
This will display the original text, followed by the corrected text by GingerIt.
 Original text: 'This is a corrects snetence'Corrected text: 'This is a correct sentence'
“AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers (...). Lambda automatically and precisely allocates compute execution power and runs your code based on the incoming request or event (...). You can write Lambda functions in your favorite language (Node.js, Python, Go, Java, and more) and use both serverless and container tools, such as AWS SAM or Docker CLI.”3
The above statements from Amazon summarise the purpose of Lambda: Providing a simple service to react to requests using custom code, in any major language, and without managing runtimes. To further facilitate development and deployment of your APIs, Lambda also supports Docker.
To deploy the GingerIt spelling and grammar correction service we will make use of Lambda’s Docker support. To do that, we first need to package the Python service in a Docker container.
Let’s start by creating our lambda handler which will be called every time the Lambda function is executed. This handler will receive a json with the text we want to correct, process it with GingerIt and return the corrected text. Save the below snippet as app.py.
Now we just have to wrap the app.py file in a Dockerfile as below. Note that you should use a suported image from AWS. This will ensure that all the required packages needed to execute Lambda are set up properly.
To test the lambda function start by building and running the docker container.
Then run the following snippet in the terminal or notebook.
If all steps were sucessfull you should be greeted with the following output.
{‘body’: ‘{“corrected_text”: “This is the correct sentence”}’, ‘headers’: {‘Content-Type’: ‘application/json’}, ‘isBase64Encoded’: False, ‘statusCode’: 200}
At this point we know that our local Lambda is working correctly. The next step is to run it remotely (serverless). To do this, we need to:
Push the docker image to the Amazon Elastic Container Registry (ECR)Create a new Lambda function and associate it with the ECR imageSet the IAM access permissions for the Lambda function
Push the docker image to the Amazon Elastic Container Registry (ECR)
Create a new Lambda function and associate it with the ECR image
Set the IAM access permissions for the Lambda function
Thankfully, this whole process (and the additional steps introduced later) can be simplified by using the serverless framework. To install it, simply follow the official serverless website4.
After installing serverless create a new file called serverless.yml and add the following content to it.
This file defines the key parameters in Lambda.
service: Name of the service we are creating. This name will be user across all required resources.provider:  name: Name of cloud provider to use (AWS)  stage: Stage to use (dev, prod)  region: Region to where to deploy the lambda function  runtime: Runtime that will be used to run the docker container. the python version should match the docker one.  ecr:    imager:      gingerit: Target name for the docker image        path: Defines where the docker file isfunctions:   gingerit: Defines the parameters for the lambda function named ‘gingerit’    timeout:If request takes longer than the defined value, return time out    memory_size: Total docker RAM in Megabytes    image:      name: Name of the docker image to use. Must match provider.ecr.image
To deploy our service we can now just simply call serverless deploy in the terminal. The following output should appear (it may take a couple of minutes to deploy the image to ECR and the Lambda function).
Serverless: Stack update finished...Service Informationservice: language-correctorstage: devregion: eu-west-1stack: language-corrector-devresources: 6api keys:  Noneendpoints:  Nonefunctions:  gingerit: language-corrector-dev-gingerit
This output indicates the full name of our lambda function (language-corrector-dev-gingerit) and a few more variables we defined. To test the function run the following snippet in the terminal or a notebook cell.
The following output should be visible:
{'body': '{"corrected_text": "This is the correct sentence"}', 'headers': {'Content-Type': 'application/json'}, 'isBase64Encoded': False, 'statusCode': 200}
Hurray! You just created a spelling and grammar correction tool and deployed it serverless.
“API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, CORS support, authorization and access control, throttling, monitoring, and API version management. (...) API Gateway supports containerized and serverless workloads, as well as web applications.”5
In summary, API Gateway serves as the middle man between our client’s browser and our Lambda function, accepting and processing the HTTP request and response. Additionally, it can be used to set limits on the allowed number of calls per second, or monthly cap for a given function or api key.
To use it, we simply add an events object to our function in serverless. Our new serverless would look like this:
The events object defines the required fields to set the API Gateway.
http: Defines the event as an HTTP method  path: Endpoint path name  method: HTTP method used to access this endpoint  cors: If true allows Cross-Origin Resource Sharing  async: Endpoint can be accessed async  private: Endpoint requires an API key to be accessed
If we now rerun serverless deploy a new field (endpoints) appears. This field indicates the address to our API Gateway, which we require to call our Lambda function through HTTP Requests.
endpoints:  POST - https://olx5ac31og.execute-api.eu-west-1.amazonaws.com/dev/language_corrector
This indicates the API Gateway address we need to call our Lambda function through standard HTTP Requests. To test the new endpoint run the below snippet.
If the API Gateway was sucessfully implemented the corrected text should appear:
{'corrected_text': 'This is the correct sentence'}
Up to now we have a working API deployed in Lambda that can accept requests through standard HTTP methods.
This function, however, can be accessed by anyone that knows the URL, and does not have a limit on the number of requests per second. This is dangerous as it could quickly increase your monthly costs if too many requests are made to it.
To mitigate this we can set API keys in API Gateway. To use it, we simply add an apiGateway object to our provider in serverless and set the private flag in our events object to true. Our new serverless would look like this:
The apiGateway object defines the usage plan for our API. In this example we set two API keys. A free API key with several restrictions, and a paid one which would allow more requests per second and a higher cap.
apiGateway:    apiKeys:      - free: name of the usage plan          - name of the api key    usagePlan:      - free:          quota:            limit: Maximum number of requests in a time period            offset: The day that a time period starts            period: The time period in which the limit applies          throttle:            burstLimit: Rate limit over a short amount of time            rateLimit: API request steady-state rate limit
If we now rerun serverless deploy a new field (api keys) appears. This field indicates the name and value of our new API keys.
api keys:  medium-language-corrector-free: FREE_KEY  medium-language-corrector-paid: PAID_KEY
To test the new endpoint run the below snippet.
If the API Gateway was sucessfully implemented the corrected text should appear:
{'corrected_text': 'This is the correct sentence'}
For the full scripts go to my GitHub page by following this link:
github.com
Using serverless computing allows you to scale your application without managing a web server, and at the same time keeping the costs low.
While for static content, the simplest and most affordable option is the Amazon Simple Storage Service (S3), this approach does not allow us to use dynamic server-side code.
To extend serverless to more complex applications, in this tutorial we explored how to use Amazon Lambda and API Gateway to deploy a serverless spelling and grammar correction tool.
This simple example should give you all the necessary tools to build more complex applications such as a serverless chatbot or an image processing service.
Join my mailing list to get new content as soon as I publish it!
If you enjoy reading stories like these and want to support me as a writer, consider signing up to become a Medium member. It’s $5 a month, giving you unlimited access to Python, Machine Learning and Data science articles. If you sign up using my link, I’ll earn a small commission with no extra cost to you.
andrefsr.medium.com
[1] A. Ribeiro. “Build a serverless website using Amazon S3 and Route 53”https://towardsdatascience.com/build-a-serverless-website-using-amazon-s3-and-route-53-c741fae6ef8d
[2] T. Kleinschmidt. “Welcome to Gingerit’s documentation!” (2015)https://gingerit.readthedocs.io/en/latest/
[3] Amazon Team. “AWS Lambda”https://aws.amazon.com/lambda/
[4] Serverless Team. “Serverless Framework — Documentation”https://www.serverless.com/framework/docs/getting-started
[5] Amazon Team. “Amazon API Gateway”https://aws.amazon.com/api-gateway/