How We Actually Implemented BFF in Practice

Implementation Overview

We implemented BFF (Backend‑For‑Frontend) as a set of three services, all built by the backend development team.

All BFFs were implemented by the backend team.

Three separate BFF services were created.

Serverless platforms and GraphQL were not adopted.

Any architecture must fit the team’s reality and the company’s business; blindly following standards is discouraged.

Why the backend team built the BFF layer

The BFF layer was treated as an aggregation and orchestration tier with strong business characteristics, its own cache and storage. Those responsibilities were judged unsuitable for the frontend team.

Traditional servers were chosen over serverless because the team lacked practical serverless experience and could not guarantee the required operational robustness.

Why three BFF services

The organization was divided into three business lines, each with its own front‑end, back‑end, testing, and product teams:

Selection line – shopping‑cart, product, menu, etc.

Middle‑back line – order, payment, fulfillment.

User‑marketing line – user, membership, marketing.

When a large requirement spans multiple lines, each line can coordinate internally, improving efficiency. Consequently we deployed three BFF services:

Selection‑line BFF

Middle‑back‑line BFF

User‑marketing‑line BFF

For most pages the front‑end calls its own BFF directly; only a few highly complex pages require additional front‑end aggregation, which is considered acceptable. A single massive BFF was avoided because coarse‑grained endpoints increase risk; multiple finer‑grained calls are safer.

Resulting Architecture

The overall architecture is illustrated below:

Service Mapping

Selection line : Shopping‑cart service, Product service, Menu service

User‑marketing line : Marketing system, User system

Middle‑back line : Order system, Payment system, Settlement service

Key Takeaways

There is no single standard for BFF implementation. The decision of who builds the BFF, whether to use servers or serverless, and how many BFFs to create depends on the weight of business logic, team expertise, and organizational constraints rather than pure technical superiority.

Debates such as GraphQL vs. REST, serverless vs. traditional deployment, or Node.js vs. Java are about tooling, not the core problem. The BFF’s purpose is to assemble data after micro‑service decomposition, and the implementation should be selected to fit the team’s reality and ensure stable operation.