The Backend for Frontend (BFF) pattern: when to use it and how to build one
The younifyd team
July 8, 2026 · younifyd.com
A general-purpose REST API forces every client to make the same trade-offs: mobile apps over-fetch fields they never render, web apps chain three requests to paint one screen, and partners get an interface shaped like your database instead of their use case. The Backend for Frontend pattern fixes this by giving each client type its own thin API layer, purpose-built for its screens. Here's when the pattern pays off, the trade-offs teams discover late, and how to ship a BFF as configuration instead of another service to own.
The problem BFFs solve
Consider a product detail screen. The mobile app needs a name, one image, a price, and a stock flag — maybe 2KB of data. Your catalogue service returns 40 fields, and pricing and inventory live in two other services. Without a BFF, the mobile client makes three sequential round-trips over a high-latency network and throws away 90% of the payload. With a BFF, the client makes one request; the BFF fans out to the three services in parallel, merges the results, and returns exactly the fields that screen renders.
One BFF per client experience
The pattern's core rule: a BFF belongs to a client experience, not to the backend. The web BFF returns rich payloads for wide screens; the mobile BFF returns lean payloads and pre-formatted display strings; the partner BFF exposes a stable contract with strict rate limits. Each evolves at its client's pace. Resist the temptation to build one 'general aggregation layer' shared by all clients — that just recreates the general-purpose API you were escaping, with an extra hop.
The trade-offs nobody mentions upfront
BFFs are more code surface: every new service is another deployable to secure, monitor, and keep on-call for. Logic duplication creeps in — three BFFs each reimplementing 'fetch product + merge pricing' drift apart. And because BFFs sit on the hot path, their latency and availability are your product's latency and availability. Teams that hand-build BFFs as Node services spend a surprising share of their time on the undifferentiated parts: auth middleware, retries, caching, and logging.
Building a BFF declaratively
The undifferentiated parts are exactly what an orchestration platform gives you as configuration. In younifyd, a BFF route is a workflow: declare the parallel fan-out to your services, add a transformation step that shapes the response per client, and put the route behind the gateway with auth, rate limiting, and per-step caching. The 'service' you would have written disappears into a versioned workflow with an execution timeline — and adding the tablet BFF next quarter is a copy-and-modify, not a new repo.
When you don't need a BFF
Skip the pattern if you have one client type, if your API already returns lean client-shaped payloads, or if GraphQL already solves your over-fetching and your clients are happy owning queries. The BFF pattern earns its complexity when multiple client experiences with different data needs sit on top of multiple backend services — which describes most products past their first year.
Ship a BFF without a new service
Parallel fan-out, per-client transforms, and gateway policies — declared in minutes.
Try for Free