Skip to content

API Composer

API Composer is client API composer is gateway API composer is standalone
⛔ It is probably not practical for clients that are outside of the firewall and access services via a slower network 💡 This option makes sense if the query operation is part of the application’s external API. API are used by clients not internal services 💡 This option is suitable when composition is too difficult to implement it in an API gateway
💡 client running on the same LAN can effectively retrieve information from all services 💡 This option is suitable when endpoint result is used by multiple internal services. When we need to get request in internal communications

💡 To minimise latency when it is possible API composer must execute requests in parallel.

Challenges

Filter entities with pagination, data is located in different services

Solutions: - in-memory join - â›” low performance if data set is large - filter entities by one service, then filter by IDs and other input filter params in next service - â›” producer services must support bulk fetch API - â›” If data is large fetch API must be POST to send IDs from the request body and avoid headers length limits.

Pros and cons of using API composer in cases when needing filtering or pagination for aggregated data from different services

  • ✅ Easy solution and works normally if data set is not large
  • â›” Developers should be writing business functionality, not a query execution engine
  • â›” API composer duplicates the functionality of an RDBMS’s query execution engine

Pros and cons

  • ✅ Simple
  • â›” Increased overhead: several data queries to obtain all necessary data. There are multiple service queries the API composition pattern can’t implement efficiently.
  • â›” Risk of reduced availability: synchronous calls reduces availability. To decrease this you can implement one of the strategies:
    • API composer returns previously cached data when a Provider service is unavailable
    • API composer returns incomplete data
  • â›” Lack of transactional data consistency
  • â›” Retrieve data scattered across multiple services results in expensive, inefficient in-memory joins

Alternatives

💡 you should use the API composition whenever possible and use CQRS 2023101316023838 CQRS only when you must.

References

  1. Microservices patterns by Chris Richardson, chapter 7
  2. http://microservices.io/patterns/data/api-composition.html