Play
Patterns

Backends for frontends

Backends for frontends gives each kind of client, such as web, iOS and Android, its own small backend instead of one shared API.

Backends for frontends (BFF) puts one purpose-built backend between each type of client and your services, so a mobile app and a web app do not have to share an API shaped for neither.

Use it when clients want different things from the same data. Sam Newman, who named the pattern in 2015, started from mobile: a phone shows less on screen, wants fewer and smaller calls, and has a different release cycle from the web app. A general API serves both badly, since each team asks for changes that the other must review. With a BFF, the mobile team owns a backend that calls three services and returns exactly one trimmed payload.

The cost is more code to run. Each BFF needs deploys, monitoring and an owner, and logic that every client needs, such as auth rules, tends to be copied between them. Azure advises against it when all interfaces make the same calls. The usual rule is that one team owns both a client and its BFF, and shared behavior belongs in the services underneath.

Nearest in Quorum#

The game has the front door, not one per client. The API Gateway is one entry point that rate-limits and passes every request kind through to your App Servers, and a Load Balancer can send chosen request kinds to different App Servers, which splits traffic by request kind, not by client. Read API gateway patterns for where the BFF fits, and Research API gateway to unlock the Component.

References#