Problem Statement

A microservice based application can have multiple services, each performing a unique individual task. A client to the application may require combinations of data obtained from each of those microservices. Microservices usually provide fine-grained APIs, which means that the client would need to interact with every individual microservice of interest.

Different consumers of the application would require different combinations and formats of the responses. The microservices themselves might support different protocols, making communication more complex. Also, the latency requirements of the consumers themselves would affect their experience with the application.

In a practical scenario, the service partitioning could change over time, and it is in the interest of usability that such changes are masked from the consumer.

Thus, it becomes necessary to provide a single point of access to the application for any microservice API call. This provides the background for the API Gateway Pattern.

The API Gateway Pattern

The API Gateway is usually an entry-point to the system. It may store partial responses from microservices, as it waits for responses from other services. It solves the following issues:

  • Accessing data from microservices over different protocols
  •  Security and Access Complexities
  • Data format management
  • Solve latency problems with caching.
  • Digital identity mapping

This pattern works as a proxy that forwards requests to relevant services. It can play a vital role in assisting Authentication and Authorization.

Authentication and Authorization

Authentication and authorization are important aspects that need to be factored into a system.

Authorization (Auth_Z) is comprised of a combination of a digital identity and one or more authenticators.

Authentication (Auth_C) determines what that digital identity can do.

Privileges are the result of completing Auth_Z and the application of Auth_C.

The API Gateway can perform both but it rarely does so in an enterprise setting. Auth_Z is a call to an external identity provider which may also do Auth_C. We normally see Auth_Z external to the gateway and Auth_C as part of the gateway in an on-premises setting, whereas in cloud environments we see the API Gateway relying on an external service for both Auth_Z and Auth_C.

Advantages of the API Gateway Pattern

  • Single Point of entry, acting as a proxy, abstracting the producer details.
  • Can request data from multiple microservices, aggregate the data and deliver the results to the consumer.
  • Can do protocol conversions (like MQTT to HTTP)
  • Can expose client-specific API.

Disadvantages of the API Gateway Pattern

  • API Gateways represent a consolidation pattern that adds abstraction to a design. This could be desired but in some cases it should be avoided.
  • API Gateways represent a single point of if resilience is not considered in planning.
  • API Gateways can create throughput issues if not resource appropriately.

Contextual Example

Examples of situations where this may be required can be found in [2].

Online Code Examples

[Example 1] https://github.com/microservices-patterns/ftgo-application

References

[1] DZone on the API Gateway Pattern: https://dzone.com/articles/design-patterns-for-microservices

[2] API Gateway Pattern: https://microservices.io/patterns/apigateway.html

[3] API Gateway vs. Aggregator: https://stackoverflow.com/questions/68044745/api-gateway-pattern-vs-aggregator-pattern-in-the-context-of-microservices

[4] DZone on the API Gateway: https://dzone.com/articles/microservice-pattern-api-gateway

[5] DZone: https://dzone.com/articles/microservices-integration-aggregators