The Backend for Frontend pattern, commonly abbreviated BFF, replaces a single shared API with a set of backends each tailored to one kind of client. Sam Newman described and named the pattern in an article published on November 18, 2015. Its central idea, in his words, is that “rather than have a general-purpose API backend, instead you have one backend per user experience.” A web application, a mobile application, and a third-party integration each talk to a backend built specifically for their needs.
The pattern arises from a tension in API design. A single general-purpose backend serving many different clients tends to become a compromise: it is too chatty for a bandwidth-constrained mobile client, too coarse for a rich web UI, and a coordination bottleneck for the teams that depend on it. By contrast, baking client-specific logic into each frontend duplicates work and pushes orchestration of multiple downstream services out to devices and browsers. A BFF resolves this by giving each experience a dedicated server-side component that aggregates and shapes data precisely for that experience.
Newman frames the user-facing application as two parts: a client-side piece outside the trust perimeter and a server-side BFF inside it. He surveys real variations, contrasting REA’s strict model of one distinct BFF per client platform with SoundCloud’s approach of letting similar mobile platforms share a BFF. He distills the guidance into Stewart Gleadow’s rule of thumb, “one experience, one BFF”: divergent experiences justify separate backends, while genuinely similar experiences can share one.
A theme Newman stresses is team alignment. He argues that “BFFs work best when aligned around team boundaries,” so the number of BFFs should follow team structure rather than a purely technical decomposition. A focused BFF lets a single team “define and adapt the API as the UI requires,” and coordinate the release of client and server components together, which speeds iteration on that experience.
The BFF is closely related to the API gateway and is catalogued as the Backends for Frontends variant of the API Gateway pattern. Where a single gateway is one shared front door for all clients, the BFF approach provides a separate gateway per client type, each optimized for and owned alongside its frontend. It trades some duplication for autonomy, removing the shared-gateway bottleneck at the cost of running and maintaining several edge backends.