Backend for Frontend (BFF)

What is BFF?

The Backend for Frontend (BFF) pattern creates separate backend services for each frontend application. Each BFF is tailored to the specific needs of its client (web, mobile, IoT).

The Problem

A single generic API struggles to serve different clients:

Issues:

• Mobile needs less data but web needs more
• Different authentication flows
• API becomes bloated serving all clients
• Changes for one client risk breaking others

The BFF Solution

Each BFF:

• Aggregates data for its specific client
• Returns only what the client needs
• Handles client-specific auth
• Transforms responses to optimal format

What a BFF Does

Example: E-Commerce Dashboard

Web BFF Response

{
  "user": { "name": "Alice", "avatar": "full-size.jpg" },
  "orders": [
    {
      "id": 1,
      "items": [{ "name": "Widget", "price": 29.99, "image": "widget-lg.jpg" }],
      "tracking": { "carrier": "FedEx", "eta": "2026-03-18", "map_url": "..." }
    }
  ],
  "recommendations": [{ "id": 5, "name": "Gadget", "reviews": 142 }]
}

Mobile BFF Response

{
  "user": { "name": "Alice", "avatar": "thumb.jpg" },
  "orders": [
    { "id": 1, "status": "In Transit", "eta": "Mar 18" }
  ]
}

Same data, different shape — each optimized for its client.

BFF vs API Gateway

They can work together:

When to Use BFF

Good fit:

• Multiple client types with different needs
• Frontend teams want autonomy
• Significant response shaping per client
• Different authentication per platform

Avoid when:

• Single client type
• Clients have similar data needs
• Small team (overhead not justified)
• GraphQL already solves data shaping

Trade-offs

Interview Tips

• Explain why a single API is problematic for diverse clients
• Describe how BFF aggregates and shapes data
• Compare with API Gateway (they complement each other)
• Mention that GraphQL can sometimes replace BFF
• Discuss ownership: frontend teams own their BFF