In the previous chapter, we explored the API Gateway pattern, which provides a single entry point for all clients.

But consider the diverse needs of different client types. A mobile app running on a slow network needs compact responses with minimal data. A web application on a desktop can handle richer payloads and multiple parallel requests. A third-party integration might need entirely different data formats and authentication schemes.

Forcing all clients through a single gateway creates a tension.

The Backend for Frontend (BFF) pattern solves this by creating separate gateway layers for each client type. Each BFF is tailored to the specific needs of its client, providing optimized APIs that make sense for that platform.

In this chapter, you will learn:

Why a single API Gateway often is not enough
How the BFF pattern works
When to use BFF versus a general-purpose gateway
Strategies for organizing and managing BFFs
Common pitfalls and how to avoid them

The BFF pattern is particularly relevant for organizations with multiple client applications serving different user experiences.

The Problem: One Size Does Not Fit All

Consider an e-commerce platform with three client types: a web application, a mobile app, and a partner API.

Each client needs different data for the same conceptual screen:

Different Interaction Patterns

Different Release Cycles

When all clients share one gateway, changes must accommodate the slowest-moving client. A web team wanting to add a field must wait until mobile apps can handle it.

Single Gateway Becomes Overloaded

The gateway accumulates client-specific logic, becoming harder to maintain. Changes for one client risk breaking others.

The Solution: Backend for Frontend

The BFF pattern creates a separate backend for each type of frontend. Each BFF is tailored to its client's specific requirements.

Each BFF:

Speaks the language of its client
Aggregates data from backend services
Transforms responses to client-specific formats
Can evolve independently of other BFFs

How BFF Works

Example: Product Detail Endpoint

The mobile BFF provides a compact endpoint optimized for mobile clients:

The web BFF provides a richer endpoint for the web application:

BFF Aggregates Multiple Services

The BFF:

Receives a single request from the client
Makes parallel calls to relevant backend services
Transforms and combines the data
Returns a client-optimized response

BFF Ownership Models

Team Ownership

The frontend team owns their BFF. They control the API contract and release schedule.

Benefits

Teams move independently
BFF matches frontend needs exactly
Faster iteration on client-specific features
Clear ownership and accountability

Challenges

Potential code duplication across BFFs
Need coordination for shared concerns
Teams need backend development skills

Platform Team Ownership

A platform team owns all BFFs, providing APIs to frontend teams.

Benefits

Consistent patterns across BFFs
Shared infrastructure and tooling
Backend expertise concentrated in one team

Challenges

Platform team becomes a bottleneck
Slower response to frontend needs
Risk of one-size-fits-all thinking

The right model depends on team structure and organization culture. Many organizations start with platform ownership and gradually shift to team ownership as capabilities mature.

BFF vs API Gateway

The BFF pattern and API Gateway pattern solve related but different problems.

Aspect	API Gateway	BFF
Purpose	Single entry point, cross-cutting concerns	Client-specific API optimization
Number	One (or few for regions)	One per client type
Ownership	Platform/infrastructure team	Frontend team or platform team
Logic	Routing, auth, rate limiting	Data aggregation, transformation
Coupling	Loose coupling to clients	Tight coupling to specific client

They are often used together:

The API Gateway handles:

SSL termination
Authentication
Rate limiting
Request logging
Routing to appropriate BFF

The BFFs handle:

Client-specific data aggregation
Response formatting
Client-specific business logic
API versioning per client

Design Patterns for BFFs

Shared Library Pattern

Extract common code into libraries shared across BFFs.

Share:

Service clients (HTTP/gRPC calls to backend)
Authentication logic
Error handling patterns
Logging and monitoring setup

Do not share:

Response transformation logic
API endpoint definitions
Client-specific business rules

GraphQL BFF

Use GraphQL to let clients request exactly what they need.

GraphQL BFF benefits:

Clients request exactly what they need
Reduces over-fetching and under-fetching
Self-documenting schema
Strong typing

GraphQL BFF challenges:

More complex to implement
Caching is harder
Potential performance issues with deeply nested queries
Requires client-side GraphQL support

Composition BFF

Multiple BFFs compose into a unified API.

This works when domain teams own their BFF slices and a thin orchestration layer composes them.

When to Use BFF

Good Fit for BFF

Scenario	Why BFF Helps
Multiple distinct client types	Each BFF optimized for its client
Different release cadences	BFFs can evolve independently
Significant data transformation	Client-specific formatting
Different interaction patterns	Mobile vs web vs IoT
Separate frontend teams	Teams own their BFFs

Not a Good Fit

Scenario	Alternative
Single client type	General API Gateway
Identical needs across clients	Shared API Gateway
Simple CRUD operations	Direct service access
Limited development resources	Single gateway simpler to maintain

Best Practices

1. Keep BFFs Thin

BFFs should aggregate and transform, not implement business logic.

Good BFF responsibilities:

Combine data from Product and Review services
Transform snake_case to camelCase
Resize image URLs for mobile
Add pagination metadata

Bad BFF responsibilities:

Calculate shipping costs (business logic)
Apply discount rules (business logic)
Validate order contents (should be in Order service)
Send notifications (should be in Notification service)

2. Define Clear Contracts

Document the API contract for each BFF using OpenAPI or similar.

Mobile BFF Contract:

3. Monitor Per-BFF

Track metrics separately for each BFF to understand client-specific issues.

Metrics to track per BFF:

Request rate
Latency (p50, p95, p99)
Error rate
Downstream service call patterns
Response sizes

4. Handle Failures Gracefully

BFFs should provide degraded responses when backend services fail.

If the Review service is down, return product data without reviews rather than failing entirely.

BFFs can share:

Deployment pipelines
Monitoring infrastructure
Service client libraries
Authentication patterns

BFFs should not share:

Endpoint definitions
Response schemas
Client-specific transformations

Common Pitfalls

Pitfall 1: BFF Becomes a Monolith

The BFF accumulates more and more logic until it becomes a new monolith.

Prevention: Regularly review what belongs in the BFF vs. backend services. Refactor business logic to appropriate services.

Pitfall 2: Excessive Code Duplication

Similar logic implemented differently in each BFF.

Prevention: Extract shared functionality into libraries. Use code generation for service clients. Establish patterns that all BFFs follow.

Pitfall 3: Too Many BFFs

Creating a BFF for every slight variation in client needs.

Bad

iOS BFF
iPad BFF
iPhone BFF
Android BFF
Android Tablet BFF
Web BFF
Mobile Web BFF

Prevention: Group by meaningful differences. iOS and Android apps with similar needs can share a Mobile BFF. Only create separate BFFs when requirements genuinely diverge.

Pitfall 4: Ignoring Versioning

BFF APIs need versioning just like any API.

Prevention: Version BFF endpoints from the start. Plan deprecation cycles. Communicate changes to client teams.

Summary

The Backend for Frontend pattern addresses the limitations of a single API Gateway when serving diverse client types:

The problem: Different clients have different needs for data, formats, protocols, and release cycles. A single gateway becomes bloated with client-specific logic.
The solution: Create a separate BFF for each client type, tailored to its specific requirements.
Ownership: Frontend teams often own their BFFs, enabling independent evolution. Platform teams can also own BFFs with different trade-offs.
Used with Gateway: BFFs often sit behind an API Gateway that handles cross-cutting concerns.
Keep it thin: BFFs aggregate and transform; business logic belongs in services.
Avoid pitfalls: Prevent BFFs from becoming monoliths, manage code duplication, and avoid creating too many BFFs.

Backend for Frontend (BFF)

Ashish Pratap Singh

The Problem: One Size Does Not Fit All

Different Interaction Patterns

Different Release Cycles

Single Gateway Becomes Overloaded

The Solution: Backend for Frontend

How BFF Works

Example: Product Detail Endpoint

BFF Aggregates Multiple Services

BFF Ownership Models

Team Ownership

Benefits

Challenges

Platform Team Ownership

Benefits

Challenges

BFF vs API Gateway

The API Gateway handles:

The BFFs handle:

Design Patterns for BFFs

Shared Library Pattern

GraphQL BFF

GraphQL BFF benefits:

GraphQL BFF challenges:

Composition BFF

When to Use BFF

Good Fit for BFF

Not a Good Fit

Best Practices

1. Keep BFFs Thin

Good BFF responsibilities:

Bad BFF responsibilities:

2. Define Clear Contracts

Mobile BFF Contract:

3. Monitor Per-BFF

Metrics to track per BFF:

4. Handle Failures Gracefully

5. Share Infrastructure, Not Logic

Common Pitfalls

Pitfall 1: BFF Becomes a Monolith

Pitfall 2: Excessive Code Duplication

Pitfall 3: Too Many BFFs

Pitfall 4: Ignoring Versioning

Summary

Get Premium