Language: English
Where Does BFF Come From?
Tracing why the BFF layer emerged as a frontend-owned tier: from clients calling backend services directly, through the Gateway pattern, to how responsibilities divide across frontend, BFF, and backend.
Discussions about whether to adopt a BFF usually stall at “another layer means more pain.” But when you trace what that layer was born to take responsibility for, the criteria for making that call change.
Clients Calling Services Directly
The starting point is clients calling backend services directly.
With a single service, there is no problem. With several, rendering a single screen takes three or four calls from the client. Call ordering, failure handling, what to display when results come back partially. All of that lands in client-side code.
Furthermore, every time a service is added or split apart, the client’s calling code has to change. With both web and mobile, the same change goes into both.
What was meant to be a simple configuration keeps getting more complex on the client side.
The Gateway Pattern
The idea of absorbing this complexity in a consolidation layer is the Gateway pattern.
Multiple backends are gathered behind a single endpoint. Concerns like authentication, rate limiting, logging, and telemetry concentrate in this layer. Clients see a single point of contact.
Both clients and individual backend services can hand off the complexity they used to carry themselves. GraphQL is one implementation that developed within this current too.
Data Shapes Differ per Client
Still, the Gateway’s responsibility is aggregating backends. Concerns skewed toward the UI fall outside its remit.
The classic case is when each client needs different data structures. Web and mobile have different screens, and need different shapes. Stuffing this into the Gateway bloats the shared platform. It’s also bad from a scaling perspective.
Putting UI-driven shaping logic in the Gateway raises one more problem. You end up aligning the Gateway’s change cycle with how often the UI changes. Because the Gateway is the front door for every client, its change blast radius is wide. Frequently poking at it is architecturally unsound.
You need a layer devoted to client-side optimization. That is the motivation for BFF.
BFF Responsibilities
A BFF stands alone as a layer belonging to the frontend.
Because it can be swapped per client, web and mobile can each be optimized independently. Even in a microservices setup, the frontend side and the backend side no longer need to keep their steps in sync. Separated responsibilities preserve each side’s autonomy.
Areas that can be carved out into a BFF include:
- Consolidation of UI-convenience logic (authorization decisions, A/B testing)
- Composing multiple APIs into UI-oriented responses
- Per-screen data shaping
- Light caching of responses and fetch results
Resource-oriented data returned by backends gets tidied into shapes screens can easily work with. The data needed to render one screen is gathered behind the scenes by the BFF and returned together.
What Stays Backend-Side
As policy, push as much toward the backend as possible.
- Implementation of business logic and domain rules
- Orchestration across multiple backends (consistency and transactional concerns)
- Persistence and guarantees of data integrity
- Heavy aggregation and analytics workloads
Write business logic in the BFF and the backend needs its own copy too, giving you double maintenance. Try to reconcile consistency across multiple backends in the BFF and all of that complexity piles into the BFF. Make the calls synchronously in sequence and latency stacks up accordingly.
Designs like these should have backends issue tasks among themselves and propagate them asynchronously. A BFF confines itself to UI-facing shaping and doesn’t take on the domain.
Three Layers of Responsibility
| Layer | Responsibility |
|---|---|
| Frontend | Presentation |
| BFF | Shaping and composing data |
| Backend | Exposing data as general-purpose APIs (resource-oriented) |
The basic form is one BFF per client. Separate ones for web and mobile is the typical arrangement.
Combining the Two
Gateways and BFFs are used together. They differ only in where responsibility lives: whether it belongs to the backend or to the frontend.
A Gateway carries shared infrastructure where funneling endpoints through a single point pays off, like authentication, rate limiting, and telemetry. A BFF handles high-churn areas tied directly to the UI, like UI-convenience composition, shaping, and A/B testing.
Architecturally, placing the Gateway behind the BFF is the natural shape. Assume both are in use, then decide what goes where.
Choosing Implementation Technology
The fact that a BFF belongs to the frontend also informs the choice of implementation technology.
Frontends change frequently, driven by UI needs. BFFs follow along, changing just as often.
Which means implementation costs that impede change hit BFF agility head-on. An operation like preparing a schema language and building a code generation pipeline may be correct in itself, yet adds steps to every change.
Technology choices should be judged on whether they can withstand that change frequency. I wrote up the concrete comparison in a separate post.
Based on the first half of my lightning talk E2E type-safe yet effortless BFF adoption, given at the TSKaigi 2026 after-party “TSKaigi2026しか型ん” (a pun: shikatan “can’t be helped”, with 型 “type”).