Navigating Microservices: A Deep Dive into Experience APIs (xAPI) and Aggregation Strategies
Overview
An experience layer APIs plays an important role on using the domain APIs by the application. It separate the client side logics and calculations from the client side. Provide the high performance application to interact with the end customers.
Challenges
Here are some of the challenges from both business and technical perspectives when dealing with the absence of Experience APIs(xAPI) in the context of multiple domain services
- Complex Integration Logic
- Testing and Debugging Complexity
- Higher Development Costs
- Number of API calls increased.
- Increase network traffic
- Security risk: The absence of standardized authentication and authorization mechanisms can result in security vulnerabilities.
- Scalability Challenges: Inefficient data retrieval and processing methods may not scale well
- Testing and Debugging Complexity: Troubleshooting errors, identifying the source of problems, and conducting comprehensive testing become more time-consuming and resource-intensive tasks.
Our Solution
An experience layer added above the domain services. This will act as a single source of data from all the domain services. It will be responsible for the all the aggregation on the requested data.
- Performance Optimization: The experience layer can be optimized specifically for client-side interactions, making it well-suited for providing fast responses to user actions. It can cache data, perform data transformation, and aggregate information from multiple domain APIs, reducing the number of requests the client-side needs to make to retrieve and process data.
- Enhanced Security: The experience layer can act as a security barrier, enforcing authentication and authorization checks before forwarding requests to the domain APIs.
- Easily perform rollback process is case of failure.
- Worked on Event based API calls.
- Abstraction in source service.
- Improvement in network traffic
- Reduce the number of call from the client.
Use case
In this use case, there are multiple mocro-services for different proposes. Service one is responsible for managing the clients for the application. A client can have multiple users associated with it. To manage the users, there is another service called users management service. Also, Each user is able to create some entities (client fields), So to manage these clients created by the users, it will be managed by the client field services.
List of services to be used
- Client management
- User management
- Client field management
Client Management Service
The Client Management Service manages client-related data. It provides information about clients, including unique identifiers, client codes, names, and the markets they operate in.
End-Point: /client-management
Sample:
{
“data”: {
“ClientId”: 2,
“ClientCode”: “A_ROYAL”,
“Name”: “Royal”,
“Markets”: [“DZ”, “AS”]
}
}
User management
The User Management Service is responsible for managing user-related information. It provides data about users, including their names, email addresses, roles, and geographic information.
End-point: /user-management
Sample:
{
“data”: {
“UserName”: “John Doe”,
“Email”: “John.Doe@abc.com”,
“UserType”: “admin”,
“Organisation”: “Royal Internal”,
“PlatformTeam”: “Y”,
“UserCountry”: “United Kingdom”,
“UserCity”: “London”,
“UserRegion”: “EMEA”
}
}
Client field management
The client fields Service handles fields-related data. It defines categories, their attributes, and rules. It also includes information about collaborators who work on fields and associated client IDs.
End-point: /client-fields
Sample:
{
“data”: {
“ClientId”: 2,
“ClientCode”: “A_ROYAL”,
“Name”: “Royal”,
“Markets”: [“DZ”, “AS”]
}
}
Aggregation Server (GraphQL)
GraphQL Query: getClientFieldDetails(displayId: Int): A GraphQL query that takes a displayId as an argument and queries the Aggregation Service to retrieve aggregated data.
Description: The Aggregation Server acts as the interface for clients to request aggregated data. It leverages GraphQL, allowing clients to specify the displayId for the desired client fields and retrieve all associated data in a single query.
Pros and Cons:
Pros:
- Data Aggregation: This approach allows for the aggregation of data from multiple services into a single coherent response, simplifying data retrieval for clients.
- Modular Architecture: The use of separate microservices for User Management, Client Management, and client fields Management promotes a modular and scalable architecture.
- Caching: The implementation of caching in the GraphQL server enhances query performance by reducing the need to make redundant calls to the Aggregation Service.
Cons:
- Complexity: Managing multiple microservices and their interactions can introduce complexity in terms of development, deployment, and maintenance.
- Latency: Aggregating data from multiple services may introduce latency, especially if there are dependencies on each other’s responses.
- Error Handling: Handling errors and failures across multiple services and ensuring graceful degradation can be challenging.
- Data Consistency: Ensuring data consistency and synchronization across services can be complex and may require careful design and synchronization mechanisms.
Flow Diagram:
The flow diagram above illustrates the sequence of actions involved in this use case, from the initial GraphQL query to the Aggregation Service’s response.
