What is Back-End for Front-End (BFF)?

A Back-End for Front-End (BFF) is an architectural pattern that introduces a dedicated server-side layer tailored to aggregate, format, and orchestrate data for one specific user interface or client experience. It acts as a strict translation layer between generalized backend microservices and specialized frontends, ensuring each client application receives exact payloads without over-fetching or complex client-side processing.

How Back-End for Front-End (BFF) works

The BFF pattern functions by shifting UI-specific orchestration away from core business services and placing it directly into a layer controlled by the frontend team. This isolation ensures that backend microservices remain client-agnostic, reducing system dependencies while the BFF handles interface-specific requirements.

Data aggregator

Consolidates multiple downstream API calls into a single response payload for the client interface. This minimizes network requests from the end-user device, directly reducing latency on mobile networks.

Payload formatter

Strips unnecessary data fields and restructures JSON responses to exactly match the target application’s UI components. This prevents the frontend from downloading megabytes of unused backend data.

Authentication translator

Manages token exchanges and session states securely on the server. It passes only the necessary authentication context to the client device, keeping complex security protocols isolated from the browser or mobile application.

Back-End for Front-End (BFF) vs API Gateway

Both architectures manage client-to-server communication, but an API Gateway handles generic, service-centric tasks like routing for all backends, whereas a BFF is client-centric and built to serve one distinct user experience.

Dimension	Back-End for Front-End (BFF)	API Gateway
Deployment scope	Client-centric	Service-centric
Primary function	Data aggregation and UI formatting	Routing, rate-limiting, and security
Ownership	Frontend engineering team	Platform or Backend engineering team
Scaling metric	Scales per specific client application	Scales per total system traffic
Domain logic	Strictly UI orchestration	Cross-cutting infrastructure concerns

When to consider Back-End for Front-End (BFF)

Consider Back-End for Front-End (BFF) if:

Your enterprise operates distinct commerce platforms, such as a B2B procurement portal and a consumer mobile app, requiring vastly different data structures from the same core inventory microservices.
Mobile conversion rates are suffering due to latency caused by over-fetching data payloads designed originally for a desktop web interface.
Your frontend engineering teams are blocked by backend deployment cycles when trying to release iterative UX improvements.

It may not be the right priority if:

If you only have one client platform, or if your web and mobile interfaces consume identical data shapes without complex aggregation, a BFF adds needless network and maintenance overhead.

Why Back-End for Front-End (BFF) matters for enterprise commerce

A Back-End for Front-End (BFF) helps enterprise retailers deliver faster, more consistent digital experiences across web, mobile, and other sales channels. By tailoring APIs to each frontend, businesses can accelerate feature releases, improve application performance, reduce integration complexity, and scale omnichannel commerce more efficiently. This translates into higher customer satisfaction, faster time-to-market, and lower development costs. AWS recommends the BFF pattern for optimizing frontend performance and simplifying interactions with microservices-based architectures.

Common misconceptions

A BFF is just another name for an API Gateway

Reality: An API Gateway is generic, service-centric, and handles cross-cutting tasks (like rate-limiting or routing) for all backends. A BFF is client-centric, built specifically to serve one distinct user experience (e.g., iOS app vs. desktop browser).

We need to build one BFF per device type (e.g., iPhone vs. Android)

Reality: You need one BFF per distinct user experience or data requirement, not necessarily per device. If your mobile web and mobile app share the exact same UI payload needs, they can share a single BFF.

We should put our checkout calculation logic inside the BFF to speed up the mobile app

Reality: Core domain logic belongs in your microservices or core backend. The BFF should only handle data aggregation, UI-specific formatting, and experience-tailored orchestration.

The BFF allows direct database access to save an API hop

Reality: A BFF should not talk directly to databases or share cached state across different types of client applications. It translates data fetched from downstream APIs.

How Kyanon Digital applies Back-End for Front-End (BFF)

Kyanon Digital implements the BFF architecture within headless commerce builds for enterprise clients managing multiple digital channels across Vietnam, Singapore, ANZ, and the US. By utilizing GraphQL and Node.js to create these client-specific translation layers, our engineering teams ensure that mobile native apps, web storefronts, and B2B portals receive exact data payloads.

This approach focuses on measurable outcomes, specifically reducing TCO by preventing core backend modifications for UI updates, and improving time-to-market for channel-specific deployments.

Explore our services:

Back-End for Front-End (BFF)