One backend serves your iOS app, Android app, web SPA, and partner API. iOS wants compact JSON for slow networks. Web wants every field for the rich UI. Partners want a stable contract that never changes. You can't make one API perfect for all of them — every change for one client risks breaking another. Worse, mobile apps end up making 8 round-trips per screen because the API was designed for the web.
The Backend for Frontend pattern (Sam Newman, 2015) — give each client type its own dedicated backend tier that aggregates from internal services and shapes data for that client. iOS BFF, Android BFF, Web BFF, Partner API. Each tuned to its consumer.
02
Why one shared API hurts
The "one API for all clients" approach fails for predictable reasons:
Different aggregation needs. Mobile home screen needs user + recent orders + recommendations + balance — 4 calls become 1 round-trip on slow networks.
Different data shapes. Web wants every product field; mobile wants 5 fields + a thumbnail URL. Either over-fetch on mobile or under-fetch on web.
Different update cadences. iOS app ships every 4 weeks; web ships daily. API can't change at the speed of the fastest client without breaking the slowest.
Different security models. Internal mobile JWT vs partner OAuth bearer vs first-party cookie. Mixing in one API leads to mistakes.
Different rate limits. Mobile gets 1000 RPS per user; partners get 100 RPS per key. One ratelimiter rule doesn't fit.
03
The architecture
Each client type gets its own thin BFF service:
BFF sits between client and internal microservices.
Speaks client-optimal protocols outward (e.g., GraphQL for SPA, compact JSON+gzip for mobile, REST+OpenAPI for partners).
Speaks internal protocols inward (gRPC to microservices is common).
Aggregates multiple internal calls into one client response.
Owned by the client team — not the platform team. Mobile team owns iOS BFF. Web team owns Web BFF.
BFF Tier per ClientMermaid
flowchart LR
iOS[iOS app] --> iBFF[iOS BFF]
Android[Android app] --> aBFF[Android BFF]
Web[Web SPA] --> wBFF[Web BFF GraphQL]
Partner[Partner systems] --> pBFF[Partner API REST]
iBFF --> US[User service]
iBFF --> OS[Orders service]
iBFF --> RS[Recs service]
aBFF --> US
aBFF --> OS
aBFF --> RS
wBFF --> US
wBFF --> OS
wBFF --> RS
wBFF --> CS[Catalog service]
pBFF --> US
pBFF --> OS
Auth, rate limits, routing for ALL traffic. Stays thin — no client-specific aggregation logic.
BFF
Per-client backend with business knowledge
Lives behind the gateway. Knows the client's UI flows. Aggregates and shapes per-client. Often there's a gateway in front of multiple BFFs.
GraphQL aggregator
Client-specified queries against one schema
Client picks fields per query. Reduces over/under-fetching without separate BFFs. Operationally heavier than REST BFFs.
05
Deep dive — anti-patterns to avoid
BFF as business-logic dumping ground. The temptation is to put complex business logic in the BFF "because it's just a thin layer." Resist. Business logic belongs in the domain services. BFF should be aggregation, transformation, and protocol translation only. If you find yourself implementing pricing rules in the BFF, you're doing it wrong.
BFF for every team rather than every client type. "Marketing team's BFF, Growth team's BFF, Mobile team's BFF" — now you have 12 BFFs and overlapping responsibilities. Group by client experience: iOS, Android, Web, Partner. Not by internal team org.
BFF that calls another BFF. If iOS BFF calls Web BFF for some shared logic, that shared logic should be a downstream service, not a BFF. BFFs depend on services, not on other BFFs.
BFF as a permanent home for legacy contracts. "We can't change the iOS API because v3 of the app is still in the wild." Use the BFF to translate legacy → modern internal, not to enshrine the legacy forever. Plan the deprecation.
The senior interview answer
"We have a BFF tier — separate iOS, Android, Web, and Partner backends. Each owned by the team that owns the client. BFF aggregates 4-8 internal microservice calls into one client response, shapes data for the client's UI, and isolates protocol differences. Internal services stay client-agnostic; BFFs absorb the variability."
06
Real-world
Netflix
Coined the term as "edge service"
Different backend per client device class — iOS, Android, Smart TVs, Roku, Web. Each is a distinct BFF tuned to its device's quirks.
SoundCloud
Pioneer adopter
Sam Newman documented their migration from shared API to BFF tier. Common reference architecture.
Shopify
Storefront API as a BFF
GraphQL Storefront API is effectively a customer-app BFF. Admin GraphQL is a merchant-app BFF.
Spotify
BFFs over Apollo Federation
Per-platform GraphQL gateways federate across hundreds of internal services. BFF pattern with GraphQL infrastructure.
07
Used in problems
News feed mobile apps use a BFF that aggregates feed + ranker + user profile in one call. E-commerce uses separate BFFs for storefront, mobile app, and partner integrations. Uber's rider and driver apps each have their own BFF.
