Serverless development allows the developer to focus more on the application code and logic and not worry about the infrastructure details.
Scaling which is handled by AWS also becomes simpler as the developer only has to invoke the APIs in response to events. There are no more idle servers sitting and waiting for the events to trigger as AWS manages the availability of servers as and when required.
The key benefits of serverless development is –
- No infrastructure management
- No idle servers
- High availability
- Flexible scaling.
There are a number of managed services provided by AWS that act as the building blocks for your application. Some of them are AWS Lambda that provide you with compute services, S3 for storage services, Amazon Aurora for the relations database needs or Dynamo DB for NoSQL databases.
All the interaction with these managed services provided by AWS involve invoking an API and getting the response back which mainly consist of the business logic you need got your application.
The service which we are going to discuss further is API Gateway which is designed to help you develop and operate the APIs.
API Gateway
API Gateway is one of the managed services provided by AWS to create, publish, monitor and secure REST and WebSocket APIs. The REST APIs created using API Gateway are HTTP-based and stick to the REST protocol which allows for stateless client-server communication.
You can implement the standard HTTP methods like GET, PUT, POST, DELETE, and PATCH.
You can simply access the API Gateway from the AWS Management Console and if you are using one of the available programming languages in AWS SDKs, then SDK could be used to access the API Gateway. It can also be accessed using the AWS Command Line Interface as well.
How API Gateway works
In the above diagram, on the left we have all users, web and mobile applications, IoT devices and all the private applications that are on VPC or on-premises. All these connect to the API Gateway using the HTTP-based request.
API Gateway receives the request and determine what to do with that request. API Gateway adds a CloudWatch monitoring where you can easily monitor the API calls. It also determines if the response from the application is cached in the memory (API Gateway Cache).
API Gateway then invoke a number of backend managed services like AWS Lambda, EC2 endpoints, etc.
Choosing the right API endpoint (Host name of the API)
The selection of the right API endpoint depends on where the majority of your application traffic originates. There are basically 3 types of API endpoints –
- Edge optimized – It is helpful to reduce client latency as the API requests are routed to the nearest CloudFront Point of Presence (POP).
- Regional – It is helpful to reduce latency when the calls are triggered from the same region as the API
- Private – It is helpful when you want to only expose the APIs inside your VPC.
Edge Optimized
API Gateway deploy a CloudFront distribution which is managed by API Gateway. The nearest CloudFront receives the request from the customer and route it to API Gateway endpoint in the AWS region. This is how the customer latency is reduced.
Regional
This is completely different than Edge Optimized end point that we just discussed above. In this there is no CloudFront distribution deployed by AWS. The customer request directly goes to the API Gateway that are in a specific AWS region. This endpoint provides lot of flexibility as you can customize different scenarios like load balancers, etc.
You can decide how the request from the customer is routed towards the endpoint. You can also add firewalls, caching and SSL certificates as well with this style.
Private
This endpoint is only exposed from within the VPC. It means that all the API requests originates from within your own VPC and they are not exposed publicly.
This type of API endpoint is used for secure work environments like financial institutions, etc.
It is very important to select the right API endpoint from the above 3 types. You can easily choose the type of endpoint you want to use from the dropdown while creating the API. If your requirements change later on, you can simply come back and change the API and you are not locked down to only one type of endpoint.
TechieSpice 