Assume we have successfully created 6-7 microservices and everything is going well. Now, for the new use case, we must introduce a new service into the product, and that newly added service must communicate with three or four other services.
So, what is the best method for implementing this newly added service to support the product?
API Composition Pattern is a very high level of pattern support for this.
The API Composition Pattern is a design pattern used in software development where multiple API endpoints are combined into a single API endpoint. This pattern is particularly useful when working with microservices architectures, where applications are divided into smaller, independent services that communicate with each other over APIs.
The API Composition Pattern enables developers to create a higher-level API that provides a more comprehensive set of functionality by combining the capabilities of multiple underlying APIs. This can simplify the process of building client applications, as they only need to interact with a single endpoint rather than multiple endpoints.
There are several approaches to implementing the API Composition Pattern, including using API gateways or building custom API endpoints. The choice of approach will depend on the specific requirements of the application and the architecture being used.
Let’s deep dive into this step by step with real life example.
Assume we have three services: order, payment, and logistics. How would a user receive the necessary data if he wishes to retrieve the specifics of an order(s)?
Querying microservices solutions is a classic problem.
To query Microservices, a popular pattern known as API composition is used.
In this pattern we have a one common component called “composer”. let’s draw this composer below.
Let’s see what composer does..?
- It takes user query.
- Identifies the services to talk to.
- Get the response in return.
- Returns the joined/calculated response.
Now the giant question is how to implement this..
Q. Do we need to write “composer” from scratch … hmmmm “NO”.
Because an API gateway is a classic example of composer, we place one in front of our microsevices and configure the rules. That’s all these is to it, buddy.
The request to the specific Microservice might occur in two ways.
- Sequential - It takes longer to compute.
- Parallel - More machine resources are required.
The implementation of the consumer depends on programming language has been selected and current use case in hand.
All these are backend talks, here we usually forgot to talk or improve end user experience.
Let’s see how we can do this.
The significance of API composition is not restricted to microservices; it also plays a significant part in providing a fantastic US experience.
Just think the situation like below.
As a result, in order to improve the user experience, we should migrate or build composer at the server level, with the added benefit of better data utilisation. So let’s try yo put composer at the server level and see the changes.
When we moved the composer at the server level in the preceding scenario, the end user will have a far superior experience.
Branch Composition.
Branch composition is nothing more than a multi-level API composition service implementation.
Advantage of API composition pattern.
- Simple to implement.
- user has a single point of interaction.
- Hides the implementation details and complexities.
- Security and rate Rate limiting can be implemented at composer (first line of defence).
- Can cover bad design decisions and wrap then within a new Interface.
- Hides legacy system and we can replace them gradually.
like Grass is not always green, need to visit the disadvantage as well.
- What if we fetch large data from microservice ---Joining then on API gateway level would be ineffective.
- Overall availability is challenging
- Having transaction data consistency is very difficult.
- Composer needs to be managed and maintained.
- Composer may become bottleneck for the product. 💡
