BFF

What is BFF (Backend for Frontend)?

Backend for Frontend (BFF) is an architectural pattern in which a dedicated backend service is built specifically to support a single frontend application or a single type of client — such as a web app, mobile app, or smart TV app — rather than exposing one generic API to all clients.

The Problem It Solves

In many systems, a single backend API is shared by multiple frontends: a web client, an iOS app, an Android app, and maybe a third-party partner integration. Each of these clients often has different needs:

• A mobile app may need smaller, optimized payloads to save bandwidth.
• A web dashboard may need rich, aggregated data pulled from several microservices at once.
• A partner API may need a completely different data shape or authentication flow.

Trying to satisfy all of these requirements with one shared API leads to bloated endpoints, excessive conditional logic, and constant negotiation between frontend and backend teams over what the API should return.

How BFF Works

Instead of one shared backend, each frontend (or frontend team) gets its own dedicated backend layer:

[Web App] --> [Web BFF] --> Microservices
[Mobile App] --> [Mobile BFF] --> Microservices
[Partner API] --> [Partner BFF] --> Microservices

Each BFF acts as an intermediary between its client and the underlying microservices or data sources. It can:

• Aggregate data from multiple backend services into a single response
• Reshape and filter data to match exactly what the client needs
• Handle client-specific authentication or session logic
• Reduce the number of round trips the frontend needs to make

Benefits

• Tailored APIs – Each client gets exactly the data structure it needs, nothing more.
• Decoupling – Frontend teams can evolve their BFF independently without waiting on a shared backend team.
• Simplified frontend logic – Aggregation and transformation happen server-side instead of cluttering client code.
• Better performance – Fewer, smaller, and more relevant API calls per client.

Trade-offs

• More services to maintain – Each BFF is its own deployable unit, adding operational overhead.
• Potential code duplication – Similar logic may be repeated across multiple BFFs if not carefully managed.
• Team ownership questions – Someone needs to own and maintain each BFF, which usually falls to the frontend team.

When to Use It

BFF makes the most sense when you have multiple distinct client types with meaningfully different data or performance needs, and when frontend teams want more autonomy over the API shape they consume. For simple applications with a single client, a shared general-purpose API is often simpler and sufficient.

Conclusion

The Backend for Frontend pattern trades a bit of extra infrastructure for significantly cleaner, faster, and more maintainable client-specific APIs. It's a popular choice in microservice architectures where different clients have genuinely different needs — and it lets frontend and backend teams move faster, with less friction, by giving each frontend the backend it actually needs.