meta data for this page
Frontend Integration Strategies Comparison
Motivation
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
Explanation of the frontend integration strategies
Comparison
| 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 |
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.
Discussion