Backend for Frontend (BFF): API Shaped for a Specific Frontend

Definition

A Backend for Frontend (BFF) is a backend layer designed specifically for one frontend or one class of frontend clients.

Example:

Instead of every client calling many backend services directly, the frontend talks to a BFF that exposes APIs shaped for that frontend.

Short mental model

A BFF is:

Practical Signals

Teams usually introduce a BFF when one or more of these problems show up:

1. One screen needs too many backend calls

The frontend must fetch and combine data from multiple services just to render one page.

2. Different clients need different API shapes

Web, mobile, and admin often do not want the same payload or the same number of requests.

3. Frontend code is doing too much backend stitching

The UI starts owning retry logic, merging responses, filtering fields, and translating backend models into UI models.

4. Shared APIs are slowing frontend work

Backend APIs are usually organized by domain ownership, but frontend development is organized by screens and user flows.

5. Auth/session logic leaks into every client

Token exchange, session enrichment, and permission-related details start getting repeated across apps.

Good interview answer

A team adds a BFF when direct frontend-to-service access starts creating too much coupling, too many requests, or too much client-side orchestration.

Common Responsibilities

A BFF often handles the following frontend-specific work:

Aggregation

Call multiple services and combine the results into one response.

Response shaping

Return exactly the fields and structure the UI needs instead of raw backend domain objects.

Orchestration

Control the sequence or parallelism of backend calls for a page or flow.

Auth/session adaptation

Keep some security-sensitive handling on the server side rather than pushing it into the client.

Client-specific policies

Examples:

Important boundary

A BFF should stay focused on frontend-oriented adaptation.

It should not slowly absorb unrelated business logic that really belongs in core backend services.

Strong Use Cases

1. Web and mobile have different needs

Mobile often needs fewer requests and smaller responses, while web may want richer data.

2. Dashboard or homepage composition

A single page needs data from many services and the browser should not orchestrate all of it.

3. Frontend team needs faster iteration

A BFF can let a frontend team evolve its API contract without changing generic shared backend APIs for every client.

4. Security-sensitive public clients

You want to keep more auth/session handling server-side instead of exposing everything directly from the client.

5. Legacy backend abstraction

Underlying services are inconsistent, but you want a stable contract for the frontend.

Weak use cases

A BFF is often unnecessary when:

Why Security Comes Up in BFF Discussions

A BFF can act as a safer boundary between public clients and backend services.

Examples:

Practical value

This reduces how much security-sensitive logic each frontend must implement by itself.

Important nuance

Security alone is not a reason to throw a BFF everywhere. But for SPAs, mobile apps, and multi-client systems, it is often one of the strongest supporting reasons.

Costs of Adding a BFF

1. More architecture to maintain

You now own another backend layer with its own deploy, observability, and failures.

2. More debugging paths

Problems can now come from the client, the BFF, or downstream services.

3. Risk of misplaced logic

If the BFF starts owning too much domain logic, it becomes a messy middle layer.

4. Possible duplication across BFFs

Some duplication is acceptable because web and mobile may genuinely need different behavior.

The real problem is not duplication by itself. The real problem is duplication without clear ownership or boundaries.

Interview framing

The tradeoff is simple: better frontend-specific APIs in exchange for another layer to build and operate.

API Gateway

An API gateway is usually infrastructure-focused. It often handles:

BFF

A BFF is frontend-focused. It usually handles:

Easy distinction

Some systems use both.

GraphQL and BFF Are Not the Same Thing

GraphQL is a query language and execution model.

A BFF is an architectural pattern.

A BFF can expose REST or GraphQL.

Useful nuance

A GraphQL layer can behave like a BFF if it is designed around frontend needs and handles orchestration across services.

But GraphQL by itself does not automatically solve:

Example: Product Page

Without a BFF, the frontend may call:

Then the browser combines everything.

With a BFF, the frontend can call:

And the BFF can return a UI-ready response such as:

That API is much closer to what the screen actually needs.

Scenario 1: Why not let the frontend call all services directly?

Because it increases coupling, request count, and client-side orchestration complexity.

Scenario 2: Why is BFF useful for mobile?

Because mobile often benefits from fewer requests, smaller responses, and more controlled server-side composition.

Scenario 3: Is BFF the same as an API gateway?

No. Gateway is usually infrastructure-oriented; BFF is frontend-oriented.

Scenario 4: Can GraphQL replace BFF?

Not always. GraphQL can help with flexible fetching, but BFF concerns like auth/session adaptation and frontend-specific orchestration may still remain.

Scenario 5: Best one-line answer

A BFF is a backend layer built specifically for a frontend so the frontend gets APIs shaped around its real UI and user-flow needs.