Introduction: Why BFF Classification Is a Real Problem (Not a Theoretical One)
Backend for Frontend (BFF) is one of those patterns everyone claims to use, yet very few teams can clearly explain where it lives, what it owns, and how it should be classified inside a monorepo. That ambiguity is not harmless. In real production systems, especially monorepos, fuzzy BFF boundaries lead to duplicated logic, accidental coupling, bloated APIs, and teams stepping on each other’s toes. The original BFF concept, introduced by Sam Newman and later popularized by Netflix engineering teams, was never meant to be “just another backend.” It was a deliberate response to frontend-specific needs that generic APIs consistently failed to satisfy.
The problem is that monorepos magnify architectural confusion. When everything lives in the same repository—frontend apps, shared libraries, backend services, infra code—the lack of a clear taxonomy becomes expensive fast. Teams start asking the wrong questions: “Is BFF frontend or backend?” or “Should this live with React or Node services?” These questions are already symptoms of misclassification. The right question is how BFFs should be conceptually classified so that ownership, boundaries, and evolution are obvious. If you get that wrong, tooling and folder structure will not save you.
The Original Intent of Backend for Frontend (And How It Gets Distorted)
To classify BFFs correctly, you first need to respect why the pattern exists. Backend for Frontend emerged as a response to multi-client complexity: web, mobile, TV, and partner clients all had different data shape, latency, and interaction requirements. Netflix documented this publicly when explaining why a single “one-size-fits-all” API failed under real-world load and organizational scale. The BFF was never about convenience; it was about containment of change. Each frontend team owned its own backend surface so that UI evolution did not ripple across unrelated consumers.
Where things go wrong is when teams treat BFFs as lightweight API gateways or thin proxies. That is not what the pattern describes. A BFF is allowed—expected, even—to aggregate, adapt, cache, and reshape data. What it must not do is become a dumping ground for business logic that belongs in core domain services. This distinction is well documented in Domain-Driven Design literature, particularly in Eric Evans’ discussion of application services versus domain services. BFFs are application services, not domain authorities.
In monorepos, distortion happens faster because code proximity encourages misuse. When the domain service is “just one import away,” teams blur layers. Without a taxonomy that clearly labels BFFs as consumer-facing orchestration layers, you end up with monolithic services wearing a BFF badge. At that point, the pattern has failed, even if the folder is named correctly.
A Practical Taxonomy: Where BFFs Actually Belong in a Monorepo
Brutal truth: BFFs do not belong to frontend or backend categories. They belong to a third classification: experience-layer services. This classification matters more than directory structure. In a well-structured monorepo, you should be able to draw a clear line between domain services (core business logic), experience services (BFFs), and delivery clients (web, mobile, etc.). This model aligns closely with the layered architecture described by Martin Fowler and the hexagonal (ports and adapters) architecture popularized by Alistair Cockburn.
From a monorepo taxonomy perspective, BFFs should be grouped by consumer, not by technology. That means a web-bff, ios-bff, or admin-bff is more meaningful than node-services or graphql-apis. This classification encodes intent: each BFF exists to serve a specific user experience. If two frontends diverge in needs, they deserve separate BFFs, even if that feels like duplication. Netflix and Spotify have both publicly stated that controlled duplication at the edges is cheaper than forced reuse at the core.
Crucially, this taxonomy also clarifies ownership. Frontend teams should own their BFFs end to end, including deployment and operational concerns. This is consistent with Conway’s Law, which has been empirically validated multiple times (including in the “Team Topologies” book by Skelton and Pais). If your org structure and repo taxonomy disagree, architecture will decay no matter how clean your code looks today.
BFF vs API Gateway vs Domain Service: Stop Mixing These Up
One of the most damaging mistakes in monorepos is collapsing BFFs, API gateways, and domain services into the same mental bucket. An API gateway is an infrastructural component concerned with cross-cutting concerns like authentication, rate limiting, and routing. It should be boring and mostly declarative. A BFF, by contrast, is intentionally opinionated and consumer-specific. Lumping them together creates a hybrid that does both jobs poorly.
Domain services, on the other hand, are where business rules live. They should be stable, reusable, and consumer-agnostic. If your BFF starts enforcing business invariants or implementing complex workflows, you are leaking domain logic into the experience layer. This is not an abstract purity argument; it creates real operational pain. Changes requested by one frontend suddenly risk breaking others, and testing matrices explode. These failure modes are well documented in microservice postmortems shared by companies like Uber and Zalando.
In monorepos, classification must be explicit in both naming and dependency rules. A BFF may depend on domain services, but domain services must never depend on BFFs. Tooling like Nx, Turborepo, or Bazel can enforce this, but only if the taxonomy is defined first. Without that, you are just adding lint rules on top of conceptual confusion.
Concrete Structure Example: A Monorepo That Respects BFF Boundaries
Below is a simplified example of how a monorepo might reflect a sane BFF taxonomy. This is not about aesthetics; it is about encoding architectural intent in a way humans and tools can enforce.
/apps
/web-app
/mobile-app
/services
/bff-web
/bff-mobile
/domains
/user-service
/payment-service
/libs
/ui-components
/shared-types
// bff-web/src/handlers/getUserDashboard.ts
import { getUser } from "@domains/user-service";
import { getPayments } from "@domains/payment-service";
export async function getUserDashboard(userId: string) {
const [user, payments] = await Promise.all([
getUser(userId),
getPayments(userId),
]);
return {
displayName: user.firstName,
balance: payments.currentBalance,
recentPayments: payments.lastFive,
};
}
This example reflects patterns described by Fowler’s “Application Layer” and Newman’s microservice guidance. The BFF aggregates and reshapes data but does not own business rules. It is brutally explicit about being consumer-facing. That clarity is what keeps monorepos maintainable at scale.
The 80/20 of BFF Classification: What Actually Delivers Results
If you strip away debates and bikeshedding, a small set of principles delivers most of the value. First, classify BFFs by consumer experience, not by language or framework. Second, enforce one-way dependencies: experience → domain, never the reverse. Third, accept duplication at the edges as a feature, not a flaw. These three rules account for most of the architectural stability teams attribute to “well-designed monorepos.”
The remaining 80% of effort—tooling, folder names, build optimizations—only works if those core insights are in place. This aligns cleanly with Pareto’s principle and is echoed in real-world architecture case studies from ThoughtWorks Technology Radar. Teams that fail with BFFs usually fail on classification first, not implementation details.
Conclusion: Classification Is Architecture, Not Documentation
Backend for Frontend is not a buzzword problem; it is a classification problem. In monorepos, classification is architecture because it determines ownership, dependencies, and evolution paths. Treating BFFs as “just another backend” guarantees slow decay, no matter how talented the team. The original intent of the pattern, backed by industry experience and architectural literature, is clear: BFFs are experience-layer services, owned by frontend teams, optimized for change.
If your monorepo taxonomy does not make that obvious, it is lying to you. And architecture that lies always collects interest. The fix is not more diagrams or stricter lint rules, but a brutally honest reclassification of what BFFs are and are not. Get that right, and the rest becomes engineering instead of archaeology.