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