What is Backend for Frontend (BFF)?
Last updated:
Last updated:
Backend for Frontend (BFF) is an architectural pattern in which each frontend — a web storefront, an iOS app, an Android app — gets its own dedicated backend layer, instead of all clients sharing one general-purpose API. Each BFF sits between its client and the underlying services, and is shaped specifically around what that client needs: the exact data, format, and payload size that work best for it.
The pattern solves a common problem with a single shared API: different clients have different needs. A mobile app wants small, trimmed-down responses to save bandwidth and battery, while a desktop web app can handle richer, denser data. A one-size-fits-all API forces the frontend to over-fetch data it doesn’t need or make several calls to assemble one screen. A BFF absorbs that work — aggregating calls to multiple backend services, reshaping the data, and returning exactly what its client expects in a single response.
The main benefits are optimized payloads, simpler frontend code, and independent evolution: each client team can change its BFF without affecting other clients, and backend services stay clean because client-specific logic lives in the BFF rather than leaking into shared services. The trade-off is more moving parts — several BFFs to build, deploy, and maintain — plus the risk of duplicated logic across them if shared concerns aren’t factored out.
In ecommerce, BFF is a natural fit for merchants serving buyers across web, mobile, and sometimes in-store or partner channels from the same commerce backend. A mobile BFF can serve lean product data tuned for a phone, while a web BFF delivers the fuller catalog and merchandising a desktop storefront needs — each drawing from the same underlying Adobe Commerce or headless services without compromise.