Backend for Frontend BFF Pattern Guide

By /

Backend Frontend BFF Pattern Implementation

Backend frontend BFF pattern introduces a dedicated server-side component for each client type that aggregates, transforms, and optimizes API responses. Therefore, mobile clients receive compact payloads while web dashboards get rich, denormalized datasets from the same underlying microservices. As a result, frontend teams gain autonomy over their data requirements without impacting shared backend APIs.

Why Monolithic API Gateways Fall Short

A single API gateway serving all client types inevitably becomes a compromise. However, mobile applications need minimal payloads to conserve bandwidth and battery, while desktop web applications demand rich data for complex dashboards. In contrast, the BFF pattern provides each client with a tailored API surface that matches its exact needs.

Additionally, monolithic gateways accumulate client-specific logic over time, creating maintenance nightmares. For example, conditional response shaping based on User-Agent headers leads to brittle, untestable code paths. Consequently, the gateway becomes a bottleneck for every frontend team's release cycle.

Backend frontend BFF architecture diagram
Per-client BFF services replace monolithic API gateways

Building a BFF Service Layer

Each BFF service owns the API contract for its specific client. Specifically, the web BFF might expose GraphQL for flexible querying while the mobile BFF provides REST endpoints with pre-shaped responses. Moreover, the BFF handles authentication token exchange, caching strategies, and error aggregation tailored to the client's capabilities.

import express from 'express';

interface ProductDetail {
  id: string;
  name: string;
  price: number;
  images: string[];
  reviews: { avg: number; count: number };
}

const app = express();

// Mobile BFF: compact response for bandwidth efficiency
app.get('/mobile/products/:id', async (req, res) => {
  const [product, reviews, inventory] = await Promise.all([
    fetch(`http://product-service/api/products/${req.params.id}`).then(r => r.json()),
    fetch(`http://review-service/api/reviews?product=${req.params.id}`).then(r => r.json()),
    fetch(`http://inventory-service/api/stock/${req.params.id}`).then(r => r.json()),
  ]);

  const compact: ProductDetail = {
    id: product.id,
    name: product.name,
    price: product.salePrice || product.basePrice,
    images: [product.images[0]?.thumbnail],
    reviews: { avg: reviews.average, count: reviews.total },
  };
  res.json(compact);
});

// Web BFF: rich response for dashboard rendering
app.get('/web/products/:id', async (req, res) => {
  const [product, reviews, inventory, related] = await Promise.all([
    fetch(`http://product-service/api/products/${req.params.id}`).then(r => r.json()),
    fetch(`http://review-service/api/reviews?product=${req.params.id}&limit=20`).then(r => r.json()),
    fetch(`http://inventory-service/api/stock/${req.params.id}`).then(r => r.json()),
    fetch(`http://recommendation-service/api/related/${req.params.id}`).then(r => r.json()),
  ]);

  res.json({ ...product, reviews: reviews.items, stock: inventory, related });
});

This demonstrates separate mobile and web endpoints aggregating the same backend services. Therefore, each client receives exactly the data it needs without over-fetching or under-fetching.

GraphQL as a BFF Layer

GraphQL naturally fits the BFF pattern because clients define their own query shapes. Furthermore, the GraphQL BFF resolves fields from multiple microservices transparently, acting as a federation gateway. Specifically, schema stitching or Apollo Federation allows composing a unified graph from distributed service schemas.

However, GraphQL BFFs introduce complexity around query depth limiting, cost analysis, and caching strategies. Moreover, persisted queries help mobile clients avoid sending large query strings over cellular networks while maintaining the flexibility benefits.

API aggregation layer design patterns
GraphQL federation enables flexible data querying across microservices

Backend Frontend BFF Deployment and Ownership Strategies

Frontend teams should own their BFF services to maintain deployment independence. Additionally, this ownership model means the web team can release BFF changes without coordinating with mobile or backend teams. For example, adding a new dashboard widget only requires changes to the web BFF and the frontend code.

Container orchestration platforms simplify BFF deployment alongside their clients. Meanwhile, shared libraries extract common patterns like authentication middleware and circuit breakers to avoid code duplication across BFF services.

Team ownership and deployment workflow
Frontend teams own their BFF services for independent deployment

Related Reading:

Further Resources:

In conclusion, the backend frontend BFF pattern eliminates the tension between diverse client needs and shared API surfaces. Therefore, adopt per-client BFF services when your application serves mobile, web, and third-party consumers with different data requirements.

Scroll to Top