API Composition Techniques for Microservices
This article delves into the critical challenge of API composition in service-based architectures, where data for a single user interface is distributed across multiple microservices. It explores various techniques and their associated trade-offs, including client-side composition, API gateways, Backends for Frontends (BFF), GraphQL, and edge composition, covering implications for latency, caching, availability, and team ownership.
Read original on ByteByteGoIn modern microservice architectures, presenting a unified view to users often requires combining data from several disparate services. This process, known as API composition, is fundamental for building responsive and efficient user interfaces. The core problem arises when a single UI element (e.g., a user profile with recent orders) needs data from multiple independent services, each owning its specific domain data.
The API Composition Problem
When a frontend application interacts with multiple backend services directly, it faces the challenges of over-fetching (retrieving more data than needed) and under-fetching (requiring multiple round-trips for related data). The location where this composition occurs significantly impacts performance, resilience, and operational complexity.
Composition Strategies and Trade-offs
- Client-Side Composition: The mobile application or browser directly calls multiple services and merges the results. Pros: Simplicity for small apps, direct service interaction. Cons: Increased network latency for the client, complex error handling, over/under-fetching.
- API Gateway Composition: A dedicated gateway acts as an entry point, performing aggregation. Pros: Centralized logic, reduced client calls, can handle security/auth. Cons: Potential for a monolithic gateway, single point of failure if not well-designed.
- Backends for Frontends (BFF): A specialized gateway pattern where each frontend (web, mobile, smart device) has its own dedicated backend service for composition. Pros: Tailored APIs for each client, team autonomy. Cons: Duplication of logic across BFFs, increased operational overhead.
- GraphQL: A query language and runtime for APIs that allows clients to request exactly the data they need from a unified schema. Pros: Eliminates over/under-fetching, flexible for clients. Cons: Learning curve, complex caching, n+1 query issues if not optimized.
- Edge Composition (CDN): Composition logic runs close to the user at CDN edge locations. Pros: Reduced latency for globally distributed users. Cons: Limited compute capabilities, security concerns, complex deployment.
Key System Design Considerations
Choosing an API composition technique involves trade-offs in latency, availability, caching efficiency, versioning across frontends, and team ownership. For instance, moving composition server-side often reduces total load time for clients on weak connections by replacing many expensive client-to-server trips with one expensive client-to-server trip and many cheap intra-datacenter trips. Availability needs careful consideration, especially when one of the aggregated services fails. Caching strategies also differ significantly based on the composition layer's location.