Microservice Pattern: API Gateway

Microservice architectures are here to stay and, when implementing them, we need to face some troubles we don’t suffer in monolithic systems. How to fetch and aggregate data from several services to serve a single request is one of them, and the API Gateway pattern is what we need to solve it.

First, we have an Order Microservice, where, via HTTP call, we can get information from an order:

GET http://order_service/orders/1

{
  id: 1,  
  description: "This is the order’s description",  
  customerId: 56,  
  lines: [    
    { description: "item 1", price: 3.5 },    
    { description: "item 2", price: 2 }    
  ],  
  total: 5.5
}

The Order Microservice only works with orders, not with customers; that’s why the order doesn’t know anything about the customer but their ID.

Then, we have a Customer Microservice, where we can get complete information about that customer:

GET http://customer_service/customers/56

{ 
  id: 56, 
  name: "John Doe", 
  email: "john@mail.com"
}

Now, we want to expose our services as a public API so our applications, or external ones, can consume it.

When one client requests information about an order, we want to embed customer information in the response, instead of forcing him to make another extra request. This data aggregation logic must be made in the API Gateway layer and the response would be something like this:

GET http://api/orders/1

{   
  id: 1,  
  description: "This is the order’s description",  
  customer: {    
    id: 56,    
    name: "John Doe",   
    email: "john@mail.com"  },  
  lines: [    
    { description: "item 1", price: 3.5 },   
    { description: "item 2", price: 2 }    
  ],  
  total: 5.5
}

As you see, the response contains the full data from the customer. The API consumer doesn’t know that internally two requests were needed to build the response; it’s transparent, and that’s the core idea of API Gateway.

About API Gateway:

• It acts as a router. It is the only entry point to our collection of microservices. This way, microservices are not needed to be public, anymore, but are behind an internal network and API Gateway is responsible for making requests against a service or another one (Service Discovery).
• It acts as a data aggregator: API Gateway fetches data from several services and aggregates it to return a single rich response. Depending on the API consumer, data representation may change according to the needs, and here is where Backend For Frontend (BFF) comes into play.
• It is a protocol abstraction layer: API Gateway can be exposed as a REST API or GraphQL or whatever, no matter what protocol or technology is being used internally to communicate with the microservices.
• Error management is centralized: When a service is not available, is getting too slow or something like that, API Gateway can provide data from cache, default responses or make smart decisions to avoid bottlenecks or fatal errors propagation. This keeps the circuit closed (Circuit Breaker) and makes the system more resilient and reliable.

I have built a naive implementation of an API Gateway, based on the example above, using NodeJS, Express, and RxJS. You can find it in this repo.

I hope you enjoyed the post!