Backend-for-Frontend and Client-Specific API Design Questions

Short answer / recommendation
Use a hybrid: an API Gateway for cross-cutting concerns (auth, rate limit, routing, coarse caching) plus per-platform Backend‑for‑Frontend (BFF) services for aggregated views. This balances latency, developer productivity, and team autonomy while containing operational complexity.

Trade-offs by pattern

• API Gateway

  • Latency: low if gateway only routes; can add aggregation to reduce chattiness but risks higher latency if it orchestrates many services.
  • Caching: good for shared, coarse cache at edge.
  • Dev productivity: centralizes contracts — faster for infra teams, slower for product teams if gateway becomes bottleneck.
  • Code duplication: low if gateway handles common joins.
  • Schema evolution: central point simplifies compatibility but becomes a coordination chokepoint.
  • Ops complexity: moderate; single deploy surface but may require complex routing/transformations.

• Client-side composition

  • Latency: higher due to multiple round-trips; worse on mobile networks.
  • Caching: per-client caches possible but inconsistent.
  • Dev productivity: fastest for full-stack teams wanting direct control; burdens UI teams with integration logic.
  • Code duplication: high across web/iOS/Android.
  • Schema evolution: each client adapts independently — flexible but noisy.
  • Ops complexity: low server-side but increases client maintenance overhead.

• BFFs (per-platform)

  • Latency: optimized—single call from client to BFF; BFF can parallelize and aggregate backend calls.
  • Caching: BFFs can implement platform-specific caching strategies (short-lived, view-level).
  • Dev productivity: high for product teams—BFFs owned by teams, iterate quickly on view models.
  • Code duplication: minimized across clients (shared view logic centralised per platform); some duplication across BFFs possible.
  • Schema evolution: BFFs shield clients from backend changes; enable gradual evolution.
  • Ops complexity: higher than pure gateway — more services to operate, but bounded by team ownership.

Why hybrid for multiple internal product teams

• Multiple teams need autonomy to iterate on view models and experiments—BFFs give that while keeping clients lightweight.
• API Gateway handles security, telemetry, global caching and route management to avoid duplicating infra logic across BFFs.
• This minimizes client-side duplication and poor mobile latency, accelerates developer velocity, and lets individual product teams evolve schemas behind their BFFs.

Operational recommendations

• Standardize BFF templates, logging, and contract testing to reduce duplication and ops burden.
• Use API gateway for cross-cutting policies + lightweight aggregation where beneficial.
• Define clear ownership: product teams own BFFs; platform team owns gateway and shared libraries.