Backend-for-Frontend (BFF) English: Vocabulary for API Architecture Discussions

The Backend-for-Frontend pattern is a common topic in API design and microservices architecture discussions. If you participate in architecture reviews, technical design conversations, or API integration planning, you will encounter BFF vocabulary regularly. This guide explains the key terms and the English phrases that help you discuss the pattern clearly and precisely.

Core Vocabulary

BFF pattern (Backend-for-Frontend) An architectural pattern where a dedicated backend service is created specifically for one type of client — such as a mobile app or a web application — rather than having all clients share a single general-purpose API. The BFF handles the specific data and orchestration needs of its client.

“We introduced a BFF layer for the mobile app because the existing REST API returns far too much data for what the mobile screens need — we were seeing 300 KB responses for 4 KB of displayed content.”

API aggregation The process of combining data from multiple upstream services into a single response, handled by the BFF so the client does not need to make multiple requests.

“The homepage requires data from three services: user profile, recommendation engine, and notification count. The BFF handles API aggregation so the mobile app makes one request instead of three.”

Client-specific endpoint An API endpoint designed for the exact data and interaction shape that one client type requires, rather than a generic resource endpoint that any consumer could call.

“We have a client-specific endpoint for the mobile checkout flow — it combines cart data, address selection, and payment method in one optimised call, instead of the generic checkout API that web uses.”

Data shaping The process of transforming, filtering, or restructuring the data returned by upstream services before sending it to the client. The BFF shapes data to match exactly what the client needs — no more, no less.

“The product detail page on mobile only shows 6 of the 40 fields that the catalogue service returns — the BFF handles data shaping so the app never receives unused data.”

Orchestration layer The BFF’s role as a coordinator that calls multiple services, handles errors and retries, and assembles a composed response. The BFF acts as an orchestration layer so the client does not need to understand the upstream service topology.

“The BFF acts as an orchestration layer — if the recommendation service is slow, it can return a cached or default response rather than making the client wait or implement fallback logic itself.”

Coupling The degree of dependency between two components. In BFF discussions, coupling describes how tightly the BFF is tied to its specific client’s needs or to the specific APIs of its upstream services.

“The trade-off of the BFF pattern is that it increases coupling between the client and the BFF — when the mobile app changes a screen layout, the BFF endpoint usually needs to change too.”

GraphQL BFF A variant of the BFF pattern that uses GraphQL as the interface, allowing clients to specify exactly what data fields they need in each query. This reduces over-fetching without the BFF team having to create new REST endpoints for every new client screen.

“We chose a GraphQL BFF for the web app — instead of creating new endpoints every time the frontend team wants a different combination of fields, they just update their queries.”

Mobile vs web BFF The practice of maintaining separate BFF instances for mobile and web clients, because these clients have fundamentally different connectivity, latency, payload size, and interaction model requirements.

“We run separate mobile and web BFFs — the mobile BFF aggressively reduces payload size and batches requests, while the web BFF can afford larger payloads because it runs on faster connections.”

Key Collocations

• introduce a BFF layer — “We introduced a BFF layer between the mobile app and the microservices when the number of parallel API calls per screen reached seven.”
• aggregate upstream services — “The BFF aggregates upstream services in parallel — it fans out to three services simultaneously and waits for all three before responding.”
• shape the response — “Before returning data to the client, the BFF shapes the response to include only the fields the mobile design requires.”
• decouple the client — “One of the main reasons to use a BFF is to decouple the client from the internal service topology — the app doesn’t need to know about each microservice.”
• expose a client-specific API — “Each platform team maintains its own BFF and exposes a client-specific API — the iOS team owns the iOS BFF, the Android team owns the Android BFF.”
• avoid over-fetching — “The BFF helps avoid over-fetching by returning only the data each screen actually needs, rather than a general-purpose resource with 50 fields.”

Using This Vocabulary in Architecture Discussions

When proposing a BFF in an architecture review, the phrase “client-specific optimisation” is a useful framing: “The BFF gives us client-specific optimisation — the mobile experience can be tuned without affecting the web experience or the third-party API consumers.”

The trade-off discussion usually involves “added complexity” versus “reduced over-fetching”: “Introducing a BFF adds complexity — we’re adding a new service to maintain. The benefit is that we decouple client needs from service design and avoid over-fetching on mobile.”

One question that often comes up is “who owns the BFF?” The most common answer in English is: “The frontend team owns the BFF — they’re best positioned to know what data shape the client needs, and they can update the BFF without waiting for a backend team.” This ownership model is worth knowing how to articulate in architecture discussions.

Common Mistakes to Avoid

A common mistake is describing the BFF as “an API gateway.” An API gateway is a generic routing, authentication, and rate-limiting layer. A BFF is a client-specific service with business logic, aggregation, and data shaping. The two can coexist: an API gateway in front of client-specific BFFs.

Another mistake is saying that a BFF “replaces” microservices. It does not — the BFF sits in front of microservices and composes their responses. The underlying services remain unchanged.

Practice Tip

Draw a simple diagram of a BFF architecture for a system you know — even a simple one with a mobile app, a web app, and two or three backend services. Then describe the diagram out loud in English, using the vocabulary from this article. Specifically: explain what each BFF aggregates, how it shapes the data, and why the mobile and web BFFs have different endpoints. Speaking through a diagram is one of the most realistic ways to practise architecture vocabulary because it mirrors what you do in real design discussions.