A mobile app opens an order screen and makes several requests in sequence. The web version presents the same order differently and needs additional details. The team keeps stretching one universal API until it contains conditions for mobile, web and partner clients.
A Backend for Frontend, or BFF, is a layer shaped around the needs of a particular client experience. That can be useful. It is not an invitation to copy the entire business model for every interface.
What does the screen actually need?
On mobile, response size, round trips and perceived load time matter. An internal web portal may need richer tables, filters and analytics. If one API sends too much data or forces clients to assemble views through many calls, a dedicated BFF can simplify the journey.
It can aggregate data, shape responses and hide parts of the internal service structure. Core rules — whether an order can be refunded, which discount is allowed and who may change its status — should still live in the appropriate domain services.
Does the team gain speed or another queue?
In a good arrangement, the product team owns its BFF and can change an interface without waiting for every consumer of a shared API. In a bad one, it creates another central team that must approve every field.
Ownership matters as much as deployment. Who maintains the BFF, who investigates latency, and who protects compatibility for older app versions?
It is not the same as an API Gateway
An API Gateway usually handles shared external concerns such as routing, common access checks and request limits. A BFF is concerned with the needs of a particular frontend. The two can coexist, but neither automatically requires the other.
A BFF should not become the only place where critical authorisation is checked. The service performing a protected business operation still needs to enforce its own access rules.
When a shared API is the better deal
If mobile and web use largely the same flows and neither response size nor client coordination is a problem, extra BFFs create more components to test and operate.
I would begin with the screens themselves. How many requests do they make? How much unwanted data do they receive? How often do separate client teams block one another? Then decide whether another layer will genuinely help.
A BFF is valuable when it lets the team change the customer experience faster without scattering the same business rules across several places.