The Problem with Generic APIs

A single generic API serving web, mobile, and third-party consumers inevitably compromises. Web applications need rich, nested data for complex pages. Mobile applications need minimal, efficient payloads for bandwidth-constrained networks. Third-party integrations need stable, versioned contracts. The Backend for Frontend (BFF) pattern solves this by creating dedicated API layers for each client type. At Nexis Limited, we use BFF patterns in products that serve both web and mobile clients.

What Is a BFF

A BFF is a backend service dedicated to a specific frontend application. The web BFF aggregates and shapes data for the web application's needs. The mobile BFF provides optimized, minimal payloads for mobile clients. Each BFF calls the same underlying microservices but transforms the responses for its specific client.

When to Use BFF

  • Multiple client types (web, mobile, TV, kiosk) with significantly different data requirements.
  • Complex API aggregation — pages that require data from multiple backend services.
  • Client-specific business logic — web and mobile may have different feature sets or workflows.
  • Team independence — separate frontend teams can evolve their BFF without coordinating with other teams.

BFF Design Principles

Client-Driven API Design

Design BFF endpoints around client pages and screens, not around backend domain models. A dashboard BFF endpoint returns everything the dashboard needs in a single request — user info, recent activity, key metrics, and notifications — aggregated from multiple backend services.

Aggregation and Orchestration

The BFF orchestrates calls to multiple backend services and aggregates results. This reduces client-side complexity and network round trips. Instead of the frontend making 5 API calls to render a page, it makes 1 call to the BFF, which makes the 5 backend calls in parallel.

Response Shaping

The BFF transforms backend responses into the exact shape the frontend expects. Strip unnecessary fields, rename fields to match frontend conventions, flatten nested structures, and compute derived values. The frontend should receive data in the exact format it needs to render — no client-side transformation required.

Implementation Approaches

Dedicated BFF Service

A separate service (Node.js, Go, or Python) that handles requests from a specific client. This provides maximum flexibility but adds an additional service to deploy and operate.

Next.js API Routes as BFF

For Next.js web applications, API routes serve as a built-in BFF layer. Server-side data fetching in React Server Components can also function as a BFF, aggregating data from multiple sources during server rendering.

GraphQL as BFF

GraphQL naturally serves as a BFF — clients request exactly the fields they need, and the GraphQL server resolves data from multiple backend services. This is particularly effective when multiple client types query the same data with different field selections.

Anti-Patterns

  • BFF as a proxy: If the BFF just passes requests through without transformation, it adds latency without value.
  • Business logic in BFF: Business logic belongs in domain services, not in the BFF. The BFF should aggregate and transform, not process business rules.
  • Shared BFF: A BFF serving multiple client types defeats the purpose. Each significant client type should have its own BFF.

Conclusion

The BFF pattern is a practical solution for the mismatch between generic APIs and specific client needs. It reduces frontend complexity, optimizes network efficiency, and enables independent client evolution. Use BFFs when you have multiple client types with different data requirements.

Designing your API architecture? Our team builds optimized API layers for diverse client applications.