Skip to content

The API Gateway Pattern

Pattern: API Gateway

Context

Let’s imagine you are building an online store that uses the Microservices pattern and that you are implementing the product details page. You need to develop multiple versions of the product details user interface:

  • HTML5/JavaScript-based UI for desktop and mobile browsers – HTML is generated by a server-side web application
  • Native Android and iPhone clients – these clients interact with the server via REST APIs

In addition, the online store must expose product details via a REST API for use by 3rd party applications.

A product details UI can display a lot of information about a product. For example, the Amazon.com details page for POJOs in Action displays:

  • Basic information about the book such as title, author, price, etc.
  • Your purchase history for the book
  • Availability
  • Buying options
  • Other items that are frequently bought with this book
  • Other items bought by customers who bought this book
  • Customer reviews
  • Sellers ranking

Since the online store uses the Microservices pattern the product details data is spread over multiple services. For example,

  • Product Info Service – basic information about the product such as title, author
  • Pricing Service – product price
  • Order service – purchase history for product
  • Inventory service – product availability
  • Review service – customer reviews …

Consequently, the code that displays the product details needs to fetch information from all of these services.

Problem

How do the clients of a Microservices-based application access the individual services?

Forces

  • The granularity of APIs provided by microservices is often different than what a client needs. Microservices typically provide fine-grained APIs, which means that clients need to interact with multiple services. For example, as described above, a client needing the details for a product needs to fetch data from numerous services.
  • Different clients need different data. For example, the desktop browser version of a product details page desktop is typically more elaborate then the mobile version.
  • Network performance is different for different types of clients. For example, a mobile network is typically much slower and has much higher latency than a non-mobile network. And, of course, any WAN is much slower than a LAN. This means that a native mobile client uses a network that has very difference performance characteristics than a LAN used by a server-side web application. The server-side web application can make multiple requests to backend services without impacting the user experience where as a mobile client can only make a few.
  • The number of service instances and their locations (host+port) changes dynamically
  • Partitioning into services can change over time and should be hidden from clients

 

Written By Chris Richardson
Full Article

Leave a Reply