Microservice Pattern : API Gateway

When we talk about the system design or see those big Mircoservice Architecture diagram, there is a component with name api-gateway which always comes into the picture. In this blog we will see what exactly is the API gateway and why do we need it, when and where to use it.

Before reading this post or learning about the api-gateway, i would suggest you to learn about proxy and reverse-proxy first or go through my other blog in which i have shared the information about the same.

Ok, now lets start with the definition of api-gateway

"API gateway is a tool that sits between the client and the collection of backened services. An API gateway acts as a reverse proxy to accept all api calls, aggregate the various services required to fulfill them, and return the appropriate result."

Let's understand the problem we would face if we don't use the API gateway. Let's take a scenario of an basic ecommerce website which has microservice architecture as below:

1. Customer Service : handles the new customer addition, updation, deletion etc.
2. Product Service: gives all the information about the products.
3. Inventory Service: takes care of all the quantity or availability of products.
4. Order Service : handles payment and place the order.

As we have microservice architecture having more than one service for front-end to interact with, it would lead to below problems :

1. Front-end itself has to play the role of API-Composer, it fetches the result from different services and combine the result.
2. Front end will have to call all the each service separately, which mean there will be 4 network calls, which could cause performance issue to the application.
3. We would have to implement authorization/authentication mechanism for all the service separately for each individual call from front end to backend.
4. We are not able to implement common caching mechanism.
5. All the service will have to follow communication protocol like REST/HTTP as client is directly communicating to services.
6. From Security point of view, will have to implement HTTPS with all the service.

Now let's see how an api-gateway can overcome all the above problems for us and what other benefits it provides and come out as an essential component in microservices architecture.

The main responsibility of api-gateway is to route the request to the required service, perform protocol transformation and combined the results from different services into one.

Apart from the main functionality api-gateway provides a lot of another benefits as well :

1. Caching : Response from the services can be cached in api-gateway to prevent network call.
2. Authorization/Authentication : Instead of verifying the identity of the client and authentication at each service, it can be implemented in api-gateway.
3. Less Network calls : As we can see now the client will have to make one only network call to api-gateway and further call to services will be executed by the api-gateway only which are in same network, hence it will enhance the performance a lot.
4. Different protocol: Now the backend service can be implemented in different protocol like REST/HTTP and gRPC and not just client friendly protocol as HTTP and WebSocket.
5. Rate Limiting : Limiting how many requests per second from either a specific client and/or from all clients.
6. Metrics collection: Collect metrics on API usage for billing analytics purposes.
7. Request logging: Log requests to different services which can help later on in debugging.
8. Easy to add another service : Now we can easily add another service in the backend without client being aware of that.

Drawback of using API-Gateway :

1. In the microservice architecture, it becomes the one highly available component which needs to be developed, deployed and managed carefully.
2. Add more complexity to the application architecture.

This blog was first posted on my blog as https://ishantgaurav131.wordpress.com/. If you find this blog relevant, you can visit my blog for more such content.

This is all from this Post. Thanks for reading, and let me know your thoughts in the comments!

Comments

[★]

I dont agree on "Nr. 3 Less Network calls" .
I don't see an api-gateway as equal as a "backend-for-frontend". I would route each request to the designated service behind the gateway. The reason is that I would not implement the complexity of the aggregation logic for all my microservice calls inside the gateway.

[pranabenator]

What he says it's that if the workflow is held by the client, it has to make multiple network calls. However, if it is held by a server component, the client needs to ask what it wants and nothing else (one network call).

[alecomputacao]

Hi
I think that api composition pattern can be used at this case.
Thanks

[Jagar]

Wouldn't it be more like a monolith architecture this way? Also it could lead to more delay in the requests and more costs.

[Allan Camilo]

Interesting