Backend for Frontend Pattern

Definition

The Backend for Frontend (BFF) Pattern creates separate backend services for different frontend applications or user experiences. Each BFF is tailored to the specific needs of its frontend, providing optimized APIs and data aggregation rather than forcing all clients to use a generic API.

When to Use It

Supporting multiple client types (web, mobile, IoT)
Different frontends have significantly different needs
You want to optimize APIs for specific client experiences
Reducing over-fetching or under-fetching of data
Teams are organized by frontend platforms
Need for client-specific business logic

Pros & Cons

✓ Pros

Optimized APIs for each client type
Reduced payload size for mobile
Frontend teams have more autonomy
Easier to evolve client-specific features
Better separation of concerns
Reduced coupling between clients and services

✗ Cons

Code duplication across BFFs
More services to maintain
Potential inconsistencies between BFFs
Increased operational complexity
Risk of logic leaking into BFFs
More deployment pipelines

Architecture Diagram

Without BFF (Generic API for all clients):
───────────────────────────────────────────

┌──────────┐  ┌──────────┐  ┌──────────┐
│   Web    │  │  Mobile  │  │   IoT    │
│  Client  │  │   App    │  │  Device  │
└────┬─────┘  └────┬─────┘  └────┬─────┘
     │             │             │
     └─────────────┴─────────────┘
                   │
                   ▼
          ┌────────────────┐
          │  Generic API   │ ◄─ One size fits none
          │   Gateway      │    • Over-fetching
          └────────┬───────┘    • Under-fetching
                   │            • Complex clients
       ┌───────────┼───────────┐
       ▼           ▼           ▼
   ┌────────┐ ┌────────┐ ┌────────┐
   │ User   │ │Product │ │ Order  │
   │Service │ │Service │ │Service │
   └────────┘ └────────┘ └────────┘


With BFF (Tailored APIs):
──────────────────────────

┌──────────┐      ┌──────────┐      ┌──────────┐
│   Web    │      │  Mobile  │      │   IoT    │
│  Client  │      │   App    │      │  Device  │
└────┬─────┘      └────┬─────┘      └────┬─────┘
     │                 │                 │
     │ Rich data       │ Optimized       │ Minimal
     │ GraphQL         │ REST/JSON       │ Binary
     ▼                 ▼                 ▼
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│   Web BFF   │  │ Mobile BFF  │  │   IoT BFF   │
│             │  │             │  │             │
│ • Full data │  │ • Small     │  │ • Status    │
│ • Complex   │  │   payloads  │  │   only      │
│   queries   │  │ • Pagination│  │ • Commands  │
│ • Admin     │  │ • Caching   │  │ • Telemetry │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       └────────────────┼────────────────┘
                        │
            ┌───────────┼───────────┐
            ▼           ▼           ▼
        ┌────────┐ ┌────────┐ ┌────────┐
        │ User   │ │Product │ │ Order  │
        │Service │ │Service │ │Service │
        └────────┘ └────────┘ └────────┘


Example: Product Page Request
──────────────────────────────

Web BFF Response (Rich):
{
  "product": {...},
  "reviews": [...],
  "recommendations": [...],
  "inventory": {...},
  "pricing": {...},
  "seller": {...}
}

Mobile BFF Response (Optimized):
{
  "product": {
    "id": "123",
    "name": "...",
    "price": 29.99,
    "image": "thumbnail_url"
  },
  "rating": 4.5,
  "inStock": true
}

IoT BFF Response (Minimal):
{
  "id": "123",
  "price": 29.99,
  "available": 1
}

Key Principles:
• Each BFF owned by frontend team
• Business logic stays in services
• BFF handles aggregation & formatting
• Keep BFFs thin (avoid duplication)