When to reach for it
- Two or more frontends have meaningfully different needs and you're burning roundtrips or shipping bytes nobody reads
- Your frontend makes 6+ requests per screen to stitch one view together
- You want auth, session, flags and rate limiting close to the client, not duplicated across mobile and web
- The shared API has become a committee — every frontend request is a backlog item on a team that doesn't ship to the App Store
- You're adopting GraphQL or tRPC and need somewhere to land the resolvers
What it actually costs
A new service per frontend. Deploy, on-call, observability, versioning and a CI pipeline — multiplied. Web and mobile BFFs drift in subtle ways; a shared concern (new auth claim) becomes three changes instead of one. If the frontend team owns it, they need backend skills they may not have. And it can quietly turn into a god service — business logic creeps in because it's convenient, and your domain is split across the BFF and the services it calls.
The failure mode nobody mentions
Logic gravity. A 'thin orchestration layer' accumulates real business rules because the frontend team can ship there faster than negotiating with the platform team. Eighteen months in, the BFF is the system of record for things downstream services don't know about, you can't replatform a client without rebuilding the rules, and pulling the logic back out is a quarter of work nobody scheduled.
When not to use it
One frontend, or two with near-identical needs — a well-designed API with field selection does the job without a new service.