Frontend Integration Strategies Comparison


Inside a microservice architecture most of the data crossing bounded contexts is going to be integrated at the frontend. There are strategies to implement this integration but none of them is good for every case, they are trade-offs between complexity, independence of deployment and the tailoring of the responses for desktops, mobile apps, wearables and other clients like SMS gateways. This comparison aims to help you choose one as soon as you start the project and show you its limitations, so you know when it is time to change it if your requirements have changed.

Frontend Integration Strategies

  • API Composition: The frontend uses the APIs of the microservices of different bounded contexts managing the whole communication directly. There isn't any aggregation or composition layer
  • Gateway API: The frontend calls only one microservice how is responsible of calling all other backend microservices and coordinating the communication between all the services and delivering responses tailored to the device. This aggregation layer may be owned by different team who don't develop on the backend
  • Backends for Frontends: There is one gateway API serving one type of device like desktops and other ones for mobile apps and wearables
  • UI Fragment Composition (slides 13 and 14): Each microservice delivers html parts and a thin assembly layer puts them together. Each team is not only resposible for the backend microservices but also for delivering the html fragments

Gateway API, API Composition, UI-Fragment Integration and Backends for Frontends StrategiesExplanation of the frontend integration strategies

Original DIA file


Aspect API Composition Gateway API Backends for Frontends UI-Fragment Composition
Is an assembly or aggregation layer required? No Yes Yes Yes
Where is done the cross-bounded-contexts coordination between microservices? UI Aggregation Layer Aggregation Layer Backend Microservices
Can the aggregation layer take on logic? No Yes Yes No
Ability to tailor responses for desktops, mobile and wearable devices? For example, to return a product with a few fields Little High High Little
Has the ability to serve native apps or thick clients which don't understand html? Yes Yes Yes No
Does the communication with the backend require lots of calls? Yes No No No
Is the UI team always the creator of the backend microservices? No No No Yes
Do small changes require requests to multiple teams if each team is responsible for one microservice? Yes Yes Yes No
Is easy to ensure the consistency of the user experience? Yes Yes Yes No
Are bounded-context-crossing features like autosuggestions from the last orders of the customer easy to implement? No Yes Yes No

Source: "Building Microservices", Sam Newman, page 51-61

Criteria to start using an integration strategy

 There isn't a strategy which fits all cases but at the beginning:

  • If you have one type of client device:
    • If you have three or less backend microservices, start with API composition
    • If you have many microservices, start with UI-Fragment composition
  • If you have two or more types of client devices:
    • If you require strong tailoring of the resposes, start with Backends for Frontends
    • If you don't require strong tailoring of the responses, start with Gateway API

 As Sam Newman explains in this book, you will probably use a mix of strategies at the end.


Enter your comment. Wiki syntax is allowed: