GraphQL Backend‑For‑Frontend Architecture and Optimization Practices

Introduction

GraphQL, originally proposed by Facebook, provides data aggregation and on‑demand fetching capabilities that are widely used between front‑end and back‑end. This article explores a different practice: sinking GraphQL beneath the Backend‑For‑Frontend (BFF) layer, combining it with metadata techniques to achieve on‑demand data and processing logic queries.

1. Origin of BFF

The term BFF comes from Sam Newman’s blog "Pattern: Backends For Frontends". It addresses the problem that mobile apps and desktop web have different UI requirements, multiple client platforms (iOS, Android, etc.), and existing back‑end services are tightly coupled with desktop‑oriented UI.

2. Core Contradiction in the BFF Context

Because the back‑end provides a single stable service while the front‑end demands flexible, multi‑platform adaptations, the contradiction shifts from back‑end/front‑end coupling to BFF/front‑end coupling. In Meituan’s product‑display scenario, the growing number of display scenes leads to API explosion, linear growth of support effort, and high system complexity.

3. BFF Application Mode Analysis

3.1 Backend BFF Mode

In this mode the BFF is owned by back‑end engineers. The most common implementation is based on GraphQL: display fields are wrapped as services, GraphQL composes them, and the front‑end queries the needed fields directly. Advantages include on‑demand querying and reduced front‑end coupling, but challenges remain in service granularity, data‑graph partitioning, and field explosion.

3.2 Frontend BFF Mode

Here the front‑end team owns the BFF, reducing cross‑team coordination but requiring strong front‑end infrastructure and exposing the same complexity issues (service granularity, model design, etc.).

4. Architecture Design Based on GraphQL and Metadata

4.1 Overall Idea

We choose the backend BFF mode and place GraphQL under the data‑aggregation layer. The architecture separates data‑fetch units from display units, uses metadata to describe their relationships, and builds a unified query model.

4.2 Data‑Fetch and Display Unit Separation

Data‑fetch units encapsulate a single external data source and produce a simplified fetch model. Display units encapsulate the logic for a single presentation field. Both are reusable assets.

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

4.3 Query Model Unification

Instead of a growing POJO with hundreds of fields, we define abstract presentation fields that map to multiple concrete display units. Standard fields are kept in the core model, while non‑standard fields are stored in an "extension" map to avoid model explosion.

4.4 Metadata‑Driven Architecture

The system consists of three core parts: business capabilities (fetch units, display units, query model), metadata (describing capabilities and their dependencies), and an execution engine that consumes the metadata to schedule and run the logic.