API gateway and Its Invokation with Lamda
An API gateway is an API managementtool that sits between a client and a collection of backend services.
An API gateway acts as a reverse proxy to accept all application programming interfaces (API) calls, aggregate the various services required to fulfil them, and return the appropriate result.
An API is a URL that you can perform
DELETE requests on to control another service. If you make one yourself, then you can build these APIs to do whatever you want behind the scenes. Common uses are providing database control, performing actions on third-party APIs (API-caption), or controlling another service.
Additionally, modern cloud development, including the serverless model, depends on APIs for provisioning infrastructure. You can deploy serverless functions and manage them using an API gateway.
Consider a case study of a complex page( let’s say product page) of an e-commerce application. If we look at the below page of Amazon product listing, we can see a lot of information needed to be rendered by this specific page.
For illustration purposes, let’s list all the microservices that we might need to render the above page.
Consider Search Product, Inventory, Shipping, Rating and Reviews, Recommendation Engine, Merchants, and Finance and Insurance are the different seven(7) microservices being used for rendering the above page.
P.S: Above seven(7) microservices are just an assumption to explain the API gateway concept. In reality Amazon could have a different number of microservices.
Since these microservices have been deployed separately on a different server if a client wants to access these services, at least seven(7) calls must be requested for a single page.
But is it really a good approach?
I don’t think it’s a recommended approach because we have to make seven different calls, which would definitely impact performance, resource consumption, load time, etc. The client is also tightly coupled with all the services and suppose if we have to separate the Reviews and Rating microservices in two different services, we have to update the client code. The client has to make one call to get reviews, and one call to get ratings, which is really not the best way to deal with it.
So, what’s the recommended approach?
It is an API gateway
In this approach, we have a layer between the client and microservices called an API gateway. It is a front-facing service for all the microservices. Now any client who wants to access the microservices, the client must call the API gateway. Now API gateway, in turn, makes a call to all the microservices and gets whatever response we might need. This process is called API composition.
In a nutshell, An API gateway sits in between the client and microservices and it acts as a gateway for all the microservices.
By switching on to API Gateways, these microservices can be accessed using private IP addresses only. This results in a more secure way of the transaction of data. Additionally, the usage of API Gateway also protects the data from malicious and DDoS attacks.
To ensure security, a TLS certificate is necessary, API Gateway handles all of them by keeping all our APIs behind a single static IP or domain and helping protect them with keys, tokens, and IP filtering.
It is important to ensure authentication and authorization of the user who logs into applications. The API Gateway makes it easier by being a single-entry point and satisfies all the requirements easily. Thus, it allows only authorized users to log in, and authenticated users to make changes, so fault tolerance is gained.
Creating the Lambdas
We can respond to these API requests using Lambdas, which is great as they only run when we need them to. They are also easy to create, so that’s what we’ll do now.
Connecting the Lambdas to API Gateway
Back in API Gateway, we can add our new Lambdas to the methods we created earlier. We need to make sure that “Use Lambda Proxy integration” is selected and that we are pointing at the correct Lambda. Clicking “Save” will ask you for permissions to access this Lambda, to which we can give the “OK”.
Do this for the GET methods on both resources and we can start to test. Selecting the methods should now show a method execution diagram. This sounds complicated but the only bit we need is the “TEST” section.
Clicking “TEST” will open a new section where we can try out the API. There are lots of things you can set here, but the only one we care about is the Path genre. We need to set this to the genre we’re requesting. Entering “western” as the genre and hitting the “Test” button gets a response like this: