Backend for Frontend (BFF)

The One-Size-Fits-All Problem

Traditional approach: One API for all clients.

Problems:

• Mobile gets too much data (wastes bandwidth) - Mobile apps receive full user objects with all fields, wasting precious bandwidth on mobile networks
• Web doesn’t get enough features - Web apps need richer data and more features, but the generic API doesn’t provide them
• Can’t optimize for specific clients - One API can’t be optimized for both mobile (minimal data) and web (rich features) simultaneously
• One API tries to serve everyone - Attempting to satisfy all clients leads to compromises that satisfy none perfectly

Solution: Backend for Frontend (BFF) - Each client type gets its own tailored backend API, optimized for its specific needs and constraints.

---

What is Backend for Frontend?

BFF (Backend for Frontend) is an architectural pattern where each client type (mobile, web, desktop) gets its own tailored backend API optimized for its specific needs. Instead of forcing all clients to use a one-size-fits-all API, BFF creates specialized backends that understand each client’s requirements.

The Core Concept

The BFF pattern recognizes that different clients have fundamentally different needs:

• Mobile apps need minimal data to save bandwidth and battery
• Web apps need rich data and features for complex UIs
• Desktop apps might need different protocols or data formats

By creating a dedicated backend for each frontend, you can optimize data transfer, reduce over-fetching, and provide client-specific features without compromising any client’s experience.

Key Concept

Each BFF:

• Tailored to specific client needs - Understands the client’s constraints and requirements
• Optimizes data for that client - Returns only the data needed, in the optimal format
• Provides client-specific features - Can include features unique to that client type
• Can use different protocols - Mobile might use gRPC for efficiency, web might use REST for simplicity

---

Why Use BFF?

Example: User Profile

Mobile needs:

{
  "id": 123,
  "name": "John",
  "avatar": "small_url"
}

Size: ~100 bytes

Web needs:

{
  "id": 123,
  "name": "John Doe",
  "email": "[email protected]",
  "avatar": "large_url",
  "bio": "Long bio text...",
  "preferences": {...},
  "recentActivity": [...],
  "friends": [...]
}

Size: ~5000 bytes

Without BFF: Mobile gets 5000 bytes (wastes 4900 bytes!)
With BFF: Mobile gets 100 bytes (50x smaller!)

---

BFF Architecture Patterns

Pattern 1: Separate BFF per Client

Each client has dedicated BFF:

Pros:

• Complete isolation - Each BFF is completely independent, allowing changes without affecting others
• Independent deployment - Deploy mobile BFF updates without touching web BFF
• Different tech stacks possible - Mobile BFF could use Node.js, web BFF could use Python

Cons:

• More infrastructure - Need to deploy and maintain multiple BFF services
• Code duplication risk - Common logic might be duplicated across BFFs (mitigate with shared libraries)

Pattern 2: Shared BFF with Adapters

One BFF with client-specific adapters:

Pros:

• Shared code - Common logic is shared, reducing duplication
• Less infrastructure - Single BFF service to deploy and maintain
• Easier maintenance - One codebase to update for shared features

Cons:

• Coupling between clients - Changes to one adapter might affect others
• Harder to scale independently - Can’t scale mobile and web BFFs separately

---

Implementation Examples

Mobile BFF (Minimal Data)

Web BFF (Full Data)

---

Adapter Pattern Implementation

Adapters transform data for each client:

---

When to Use BFF

Use BFF When:

• Clients have very different needs - Mobile and web require fundamentally different data structures and features
• Mobile needs differ significantly from web - Mobile needs minimal data, web needs rich features
• Performance optimization needed per client - Each client has different performance requirements
• Client-specific features required - Some features are only relevant to specific client types
• Different protocols needed (REST for web, gRPC for mobile) - Different clients benefit from different communication protocols

Don’t Use BFF When:

• Clients have similar needs - If all clients need the same data, BFF adds unnecessary complexity
• Simple API with few differences - The overhead of maintaining multiple BFFs isn’t justified
• Limited resources (BFF adds complexity) - BFF requires more infrastructure and maintenance
• Small team (harder to maintain multiple backends) - Multiple BFFs require more development and operational effort

Start Simple

Start with a single API. Add BFF only when you have clear evidence that clients need different optimizations. Don’t over-engineer!

---

BFF vs API Gateway

Feature	API Gateway	BFF
Purpose	Routing, cross-cutting concerns	Client-specific optimization
Aggregation	Can aggregate	Always aggregates
Transformation	Minimal	Heavy transformation
Client Awareness	Generic	Client-specific
Use Case	Single entry point	Client optimization

They can work together:

Client → API Gateway → BFF → Services

---

Key Takeaways

Client-Specific

BFF provides tailored APIs for each client type. Mobile gets minimal data, web gets full features.

Performance Optimized

Each BFF optimizes for its client. Mobile saves bandwidth, web gets rich data.

Adapter Pattern

Use adapter pattern to transform data for each client. Shared logic, client-specific transformations.

Code Reuse

Share common logic in libraries. BFFs can share code while providing client-specific APIs.

---

Next Steps

• Learn Real-time Communication - WebSockets, SSE, long polling
• Master Rate Limiting - controlling API usage
• Review API Gateway - how BFF fits with API Gateway