The Point

BFF (Backend For Frontend) is an architecture pattern where you build a dedicated backend layer for each frontend client, instead of having all clients share a single API.

Explanation

Why do you need BFF?

Different clients have very different data needs. Take an e-commerce platform as an example:

• Mobile app: small screen, limited bandwidth, needs only a few compact fields
• Web browser: can show richer data, needs more fields
• Third-party partners: yet another set of data format requirements

With a single shared API, two problems arise:

• Over-fetching: returning fields the client does not use
• Under-fetching: one request is not enough, so the client sends multiple requests

BFF adds a layer between clients and backend microservices:

Mobile App  →  Mobile BFF  ┐
Web App     →  Web BFF     ├─→  microservices
Partner API →  Partner BFF ┘

Each BFF handles:

1. Aggregating responses from multiple microservices (one request instead of many)
2. Trimming data to the format that specific client needs
3. Client-specific logic (e.g. mobile pagination)

Who maintains the BFF?

Usually the frontend team, so they can adjust the API format on their own without waiting for backend changes.

Knowledge Sugar

BFF vs API Gateway

These are easy to confuse, but they serve different purposes:

In practice they can coexist – the API Gateway sits in front handling common concerns, while BFFs sit behind it doing client-specific data aggregation.

When do you not need BFF?

• Only one client type (e.g. web only)
• The backend is a monolith with nothing to aggregate
• The team is small and maintaining multiple BFFs costs more than it saves