API Gateway

When creating an application based on microservices, there are several issues one might come across:

• Different clients (WEB vs mobile) might require different data
•  The granularity of the data API returns might differ to what a specific client needs
• In order to get all the data, the client might need to send requests to several microservices
• Number of instances of microservices and their locations might change
• In the course of application lifetime, some microservices could be spilled or combined
• Some microservices might use special protocols that are not web-friendly

So the main problem is how the clients of a microservice application know which microservice should be targeted? The solution is the API Gateway pattern. It is a separate microservice that acts as a single entry point for all clients. It will receive a request from the client, and then according to its ruleset, forward request to appropriate microservices: Depending on the architecture, sometimes is beneficial to create several gateways for different types of clients: Pros:

• Clients don't need to know how the microservices are partitioned, nor their location
• Client simplification, since the logic of tarteting, is moved to the gateway
• Client isolation, each client has access to a subset of microservices it needs
• Universal gateway, or bespoke API for each client
• Hides the underlying communication protocols between API gateway and microservices, while providing "standard" friendly API to the public

Cons:

• Increased complexity, since it is another service that needs to be built and maintained
• Increased response time, but mostly negligible