Backend for Frontend (BFF)

Introduction

BFF (Backend for Frontend) provides a dedicated backend per client channel — mobile, web, partner — that aggregates microservices into the exact shape each frontend needs. Sam Newman coined it: one BFF per frontend type, owned by the frontend team. It's Facade at client boundary, not generic gateway.

The story

Retailer shared one API across web, iOS, Android. Mobile suffered over-fetching and version mismatches. Three BFFs — one per platform — let each team own its contract; mobile p95 −40%, feature lead time halved.

The business problem

One-size-fits-all API satisfies no client well:

• Over-fetching: mobile downloads web-sized payloads.
• Under-fetching: mobile makes 22 calls per screen.
• Release coupling: frontend blocked on shared API team.
• GraphQL complexity: one mega-schema for all clients.

The problem teams faced

BFF fits when:

• Client channels need materially different response shapes.
• Frontend teams want ownership of their API contract.
• Aggregation logic is client-specific not domain-specific.
• Multiple dedicated frontend apps (mobile, web, partner portal).

Understanding the topic

Intent: Per-client backend aggregating downstream services into tailored responses.

• Mobile BFF — compact payloads, few round trips.
• Web BFF — richer graphs, SEO-friendly shapes.
• Owned by frontend team — not central platform only.
• Composite + Facade — aggregates service tree per request.

Internal architecture

Mobile BFF home screen:

class MobileHomeBff {
  async getHome(userId: string) {
    const [featured, cart, recs] = await Promise.all([
      this.catalog.featured(),
      this.cart.summary(userId),
      this.recs.forMobile(userId),
    ])
    return { featured, cart, recs }  // compact mobile shape
  }
}

Visual explanation

Three diagrams cover BFF per client, aggregation, and boundaries:

Informative example

Before / after — shared API to mobile BFF:

// ❌ Mobile orchestrates 22 service calls
const catalog = await api.get("/catalog/featured")
const cart = await api.get("/cart")
// ... 20 more

// ✅ Mobile BFF — one call, server-side aggregation
// GET /mobile-bff/v1/home
const home = await mobileApi.get("/home")
// BFF parallel-fetches and returns { featured, cart, recs }

Execution workflow

Real-world use

Netflix multiple device APIs, SoundCloud BFF migration, many retail mobile BFFs behind API gateway.

Production case study

Retailer three-platform BFF split:

• Before: shared API; mobile p95 high; coupled releases.
• Decision: iOS, Android, Web BFFs owned by client teams.
• Outcome: p95 −40%; feature lead time halved.

Trade-offs

• Pro: optimal per-client API; frontend autonomy; fewer round trips.
• Con: N BFFs to maintain; duplication risk in aggregation.
• Con: extra hop — latency budget.

Decision framework

• Use when 2+ client channels need different shapes.
• One BFF per frontend type — not per feature.
• Skip when single web app and simple API suffices.

Best practices

• BFF composes — domain services decide business rules.
• Parallel fan-out with timeout per dependency.
• Frontend team owns BFF repo and deploy.

Anti-patterns to avoid

• BFF with pricing/checkout business logic.
• One BFF per developer — explosion of backends.
• BFF bypassing services to hit DB directly.

Common mistakes

• BFF fan-out to all 40 services for every request.
• Duplicated aggregation logic across BFFs — extract shared read services.

Debugging tips

• Trace BFF fan-out waterfall — find slow dependency on screen load.

Optimization strategies

• Cache aggregated responses with short TTL for home screens.

Common misconceptions

• BFF ≠ API Gateway. Gateway generic; BFF client-specific Facade.
• BFF is Composite assembling service responses.

Advanced interview questions

Summary

You can design per-client BFFs, aggregate safely, and govern against logic creep. Tell the mobile p95 −40% story — if you can do that, you own BFF.