API Gateway

The API Gateway service, as its name suggests, is a service geared toward creating and managing APIs' endpoints. From an architecture standpoint, the service can be seen a little bit like a load balancer such as the ALB or ELB that we saw earlier in the chapter. The ALB gives us the ability to do path-based routing and, for example, send all calls where the path starts with /api/ to the API service hosted on a specific Auto Scaling group. In the case of the API gateway service, the configuration goes one step further and, in addition to defining the path, we can also define a method (GET, POST, PUT, OPTIONS) and the integration type that can be almost anything (any AWS managed service, HTTP forwarding, or a static answer). This last specificity makes it a very compelling option when going for a serverless architecture as we can use it in conjunction with a Lambda function. By combining API Gateway and Lambda, we can replace the EC2 instance and load balancer from our stack and create complete web applications that can scale instantly to virtually any amount of traffic.

To implement this, we can use the API Gateway at the edge of your infrastructure, as shown in the following figure:

The service will accept inbound connections from browsers or mobile applications. It will then dispatch the different requests looking at the method and path to a number of Lambda functions, which in turn will execute the requests and, if needed, even interact with different data stores. This solution is particularly interesting cost-wise to use for services or applications with a small to medium amount of traffic as you get billed on a per-execution basis.

You can read more about the API Gateway service at http://amzn.to/2hRVQqW.

We are going to update our serverless Hello World application to include an HTTP endpoint. Thanks to the framework we use, adding an API Gateway endpoint is very easy. The only change necessary is in the configuration of the service. With your editor, open the serverless.yml file.

Since Lambda is a service that is event-based, we need to define an event to trigger our function. For that, we will go to Line 56 of the file where our function is defined. In order to add an API Gateway endpoint and connect it to our function, we simply need to introduce the following:

functions: 
  hello: 
    handler: handler.hello 
    events: 
      - http: GET greet 

We can now save the file and run the deploy command again:

$ serverless deploy  

After a few seconds, the CloudFormation stack will get updated and we will now see a new endpoint appearing in the Service Information output:

Service Information

service: helloworld

stage: dev

region: us-east-1

api keys:

None

endpoints:

GET - https://j93ot13ktg.execute-api.us-east-1.amazonaws.com/dev/greet

functions:

helloworld-dev-hello: arn:aws:lambda:us-east-1:511912822958:function:helloworld-dev-hello

We can now open that URL in our browser or use the curl command to validate the change:

$ curl https://j93ot13ktg.execute-api.us-east-1.amazonaws.com/dev/greet
Hello World

By combining Lambda and the API Gateway we were able to create an application that can virtually absorb any amount of traffic.

Lambda at the Edge
We talked about how distance matters and that using CloudFront could speed up your application, especially for users far away from your infrastructure. Lambda has one more feature called Lambda at the Edge (Lambda@Edge) , that lets you run your functions in the same edge location as CloudFront, allowing you to handle requests and responses that flow through your CloudFront distribution quickly.

With this new set of options in our hands, we now have a number of ways to scale out the computing of our applications. At that point, it is likely that the next issue that will need to be tackled is scaling our data layer to also handle more than what we currently have.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset