Backend for Frontend (BFF)

Your web app shows a product page with a large image carousel, 50 reviews, detailed specifications, seller information, and 12 related products. Your mobile app shows the same product with a single hero image, 3 reviews, the price, and a buy button. Your smartwatch app shows the price and an "add to cart" button.

If all three clients call the same REST API, you hit an impossible trade-off. The API returns everything (200+ KB of JSON, most of which mobile and watch discard), or you add query parameters for every variation (?include=reviews&limit=3&fields=name,price,image). The second option sounds clean until you have 15 client variations and the "generic" API becomes an unmaintainable tangle of conditional logic.

The Backend for Frontend (BFF) pattern creates a dedicated backend for each frontend type. The web BFF calls five microservices and returns a rich, 200 KB response. The mobile BFF calls three microservices and returns a 15 KB summary. Each BFF is a thin server-side layer owned by the frontend team that uses it. They control exactly what data their client receives, how it is structured, and when it changes.

Sam Newman (author of "Building Microservices") coined the pattern in 2015. Netflix runs separate BFFs for their web player, iOS app, Android app, and TV app. SoundCloud's mobile team built their own BFF to cut API response sizes by 60% and halve the number of network calls per screen. Spotify's mobile BFF strips out desktop-only fields and pre-aggregates data to minimize round trips on cellular networks.

Each BFF is a thin server (Node.js, Go, Python) that sits between one client type and the backend microservices. It has no database of its own. Its job is: receive a request from the client, fan out to the relevant backend services, cherry-pick the fields the client needs, shape the response, and return.

Web BFF response (rich, 180 KB):

{
  "product": {
    "name": "Mechanical Keyboard",
    "images": ["img1.jpg", "img2.jpg", "img3.jpg", "img4.jpg"],
    "price": 149.99,
    "specs": { "switches": "Cherry MX Brown", "layout": "TKL", "backlight": "RGB" },
    "reviews": [ /* 50 reviews with full text */ ],
    "related": [ /* 12 products with thumbnails */ ],
    "seller": { "name": "KeyCo", "rating": 4.8, "responseTime": "2 hours" }
  }
}

Mobile BFF response (compact, 12 KB):

{
  "product": {
    "name": "Mechanical Keyboard",
    "image": "img1_small.webp",
    "price": 149.99,
    "reviewSummary": { "average": 4.5, "count": 238 },
    "topReviews": [ /* 3 reviews, truncated to 100 chars */ ]
  }
}

Same backend data, different shapes. The mobile BFF skips the Review Service entirely (it only needs the summary, which the Product Service already caches). The web BFF calls all five services and stitches together the full page. The backend microservices stay general-purpose. They do not know or care which BFF is calling them.

Key ownership principle: The mobile BFF is owned by the mobile team. They add fields when the app needs them. They remove fields when the app drops a feature. They deploy on their own schedule. No meetings with the backend team to coordinate API changes. This is the core value proposition: each frontend team controls their own API surface.