When an application is broken into smaller microservices, it brings in few challenges that needs to be addressed. These include abstracting producer information, handling multiple protocols, data transformation or format conversion for different consumers and so on. To handle these challenges we can use an API gateway design pattern. In this article we'll understand further about this pattern.
An API Gateway is a single point of entry for any microservice call. It can work as a proxy service to route a request to concerned microservice, abstracting the producer details. It can fan out requests to multiple services and aggregate the results to send back to consumer. It can also do protocol conversion e.g. from AMQP to HTTP and vice versa. The responsibilities like authentication/authorization can be offloaded to the API gateway.
The API gateway pattern is recommended if you want to design and build complex large microservices-based applications with multiple client applications. The pattern is similar to the facade pattern from object-oriented design, but it is part of a distributed system reverse proxy or gateway routing for using as a synchronous communication model.
The API Gateway pattern comes with several disadvantages as well:
- It increases the complexity in the system as there is an additional component to be maintained.
- As there can be network latency between the additional hop it increases the response time.
A variation of API gateway pattern is Backends for Frontends pattern. In this pattern we divide one API gateway into multiple API gateways one each for specific client type. So the API gateway explained in above diagram will become as below:
No comments:
Post a Comment