GraphQL‑Based BFF Architecture with Metadata‑Driven Data Aggregation

GraphQL, originally proposed by Facebook, provides data aggregation and on‑demand fetching. This article presents a practice that pushes GraphQL down to the Backend‑For‑Frontend (BFF) layer and combines it with metadata technology to enable on‑demand querying of both data and processing logic.

The term BFF comes from Sam Newman’s blog "Pattern: Backends For Frontends". It was created to solve the mismatch between a single‑purpose backend service and the diverse UI requirements of mobile apps and desktop web, such as different UI layouts, platform‑specific features, and tight coupling between existing backend functions and web UI.

In the BFF context, two core contradictions arise: (1) business support efficiency – as the number of product‑display scenarios grows, API count explodes and the effort to support them grows linearly; (2) system complexity – business logic becomes tangled with procedural if…else… code, making maintenance difficult.

Two main BFF application modes are discussed:

Backend BFF – the BFF is owned by backend engineers and typically built on GraphQL. It encapsulates display fields as services, allowing front‑ends to query exactly what they need.

Frontend BFF – the BFF is owned by the front‑end team, reducing cross‑team coordination but introducing challenges in handling complexity and variability.

After analyzing both modes, the article chooses the backend BFF approach and proposes an architecture that separates data‑fetching units from display units, driven by metadata. The overall design includes three key aspects: fetch‑display separation, unified query model, and metadata‑driven execution.

Fetch‑display separation : a fetch unit encapsulates a single external data source and produces a simplified fetch model; a display unit encapsulates the logic for a single display field. This separation keeps units small, reusable, and easy to compose.

Query model unification : to avoid field explosion, the query model combines standard fields with an extension attribute that holds non‑standard, scenario‑specific data. This reduces the number of DTO fields while preserving flexibility.

The metadata‑driven architecture consists of three core components:

Business capabilities – fetch units, display units, and query models.

Metadata – descriptions of capabilities and their relationships.

Execution engine – consumes metadata to schedule and execute business logic.

GraphQL usage simplification : the article standardizes query interfaces into three patterns – 1‑to‑1, 1‑to‑N, and N‑to‑N – and wraps them in generic fetchers that return CompletableFuture. This reduces the learning curve for developers unfamiliar with GraphQL concepts such as Schema and RuntimeWiring.

Performance optimizations include:

Caching compiled schemas and queries to avoid repeated parsing overhead.

Replacing the default PropertyDataFetcher hotspot with a lighter implementation.

Parallelizing list processing by splitting large lists into tasks across CPU cores.

Improving DataLoader scheduling by dispatching as soon as the last load for a field instance is observed, thus eliminating the additive latency of the original FieldLevelTrackingApproach.

Sample code illustrating the conditional display logic:

if(category == "丽人") {
  title = "[" + category + "]" + productTitle;
} else if (category == "足疗") {
  title = productTitle;
}

These optimizations resulted in an average response‑time reduction of 1.457 ms, a 5.82 ms reduction at the 99th percentile, and roughly a 12 % drop in CPU utilization.

Impact on development workflow : the new architecture shifts developers’ focus to business logic, enables visual configuration of capabilities, and allows rapid composition of display scenarios without writing repetitive glue code. The workflow now consists of creating or reusing fetch and display units, defining a query plan, and invoking a unified query API.

In production at Meituan’s in‑store product, the approach achieved over 50 % reuse of display logic and more than a two‑fold increase in development efficiency.

The article concludes with a list of references and a brief recruitment notice for engineers interested in similar challenges.