When should I use a Backend for Frontend instead of an API gateway?

Here's how to think about when a BFF is the right call versus relying on an API gateway alone:

Use an API gateway alone when:

• All your client types (web, mobile, partner) can consume roughly the same data shape — a gateway routes, authenticates, and rate-limits, but doesn't need to reshape responses differently per client.

• You have a small number of clients with simple, similar needs — introducing a BFF for every case adds complexity you don't need yet. Your main problems are cross-cutting (auth, rate limiting, routing, observability) rather than "different clients want different data."

• You're early-stage and want to keep the architecture simple — a gateway in front of your services is often sufficient until client divergence becomes a real pain point.

Introduce a BFF when:

• Different client types have meaningfully different data or interaction needs — e.g., mobile wants a lean, aggregated payload to minimize round-trips on a slow connection, while the web app wants a richer, more granular response for a dashboard.

• A client is making multiple round-trips to assemble one screen's worth of data — that's the clearest signal a BFF (which aggregates and shapes data server-side) would help.

• You want to decouple client release cycles from backend service changes — a mobile BFF can maintain a stable contract for an app that updates slowly, even as underlying microservices evolve independently. Different client teams want autonomy over their own API shape and iteration speed, without going through a shared "generic" API team that has to balance everyone's competing needs at once.

• You're dealing with real orchestration — calling multiple services, combining results, handling partial failures — not just routing a single request to a single service. That's business logic a gateway isn't meant to hold.

The key distinction

• A gateway operates on one request in, one request out — it's a policy and routing layer, not an aggregation layer.
• A BFF operates on many requests in (to backend services), one composed response out — it's specifically for reshaping and combining data for a particular consumer.
• They're not mutually exclusive — a very common pattern is: client → API gateway (auth, rate limiting, TLS termination) → BFF (aggregation, client-specific shaping) → underlying microservices. The gateway handles cross-cutting concerns for all traffic; the BFF handles client-specific composition for its slice of that traffic.

A practical decision test

• Ask: "If I add a new client type tomorrow (e.g., a partner API), would it want the same response shape as my existing clients, or something meaningfully different?"

Same shape → a gateway (possibly with a shared general-purpose API behind it) is enough.

Meaningfully different → that's your signal to add a BFF for that new client, without necessarily touching the others.

Common mistake to avoid

• Don't reach for a BFF just because you have an API gateway and want "more layers." A BFF is justified by client divergence, not by architectural completeness — if one well-designed shared API already serves every client's needs adequately, adding BFFs on top is unnecessary complexity, not best practice.