GraphQL‑Based BFF Architecture and Low‑Code API Generation Platform at iQIYI

In 2015 Facebook introduced GraphQL (Graph Query Language). Since then companies such as IBM, Twitter, Walmart Labs, The New York Times and Coursera have migrated many of their internal services from RESTful APIs to GraphQL.

GraphQL offers several key characteristics: (1) automatic schema generation from queries and mutations, (2) fine‑grained data fetching through a mapping between the schema and resolvers so that only the requested fields are returned, and (3) a unified access point that can stitch together multiple back‑end APIs.

The iQIYI technical team, inspired by the low‑code development concept, built a Backend‑for‑Frontend (BFF) layer on top of GraphQL. This allows developers to create front‑end callable APIs through a drag‑and‑drop interface, effectively turning the BFF into a low‑code API generation platform.

Like a RESTful service, a GraphQL API handles HTTP requests, but it uses a single endpoint (typically POST) and resides in the system’s “middle layer”. The architecture diagram (Figure 1‑1) shows this placement.

The GraphQL execution process consists of four steps: validation against the schema, creation of an execution context, collection of the required fields, and resolver execution for each field followed by result formatting (Figures 1‑2 to 1‑4).

In GraphQL a type defines one or more field s, each bound to a resolver that fetches the corresponding data. For example, the UserInfo type has fields nickName , contractNo and fansNumber , each requiring a resolver that pulls data from separate micro‑services and aggregates the result.

The BFF architecture acts as a middle‑layer service that encapsulates business logic, reduces the number of redundant REST APIs, and handles varying data granularity required by different front‑end scenarios.

A comparison table (Table 2‑1) highlights GraphQL versus REST API on performance, documentation, debugging and learning cost, showing that GraphQL generally provides better performance and stronger typing at the expense of a higher learning curve.

Although GraphQL offers many benefits, Facebook only provides an official JavaScript implementation, which makes migration to Java projects more challenging. iQIYI therefore adopts the open‑source graphql‑java library.

The iQIYI API generation platform (a low‑code platform) built on graphql‑java adds four major enhancements: (1) Rest API support to lower front‑end integration cost, (2) dynamic monitoring via Prometheus by exposing real request URLs through Spring Boot Actuator, (3) flexible schema generation using Velocity templates and Java reflection, and (4) a visual API management console for creating, modifying and reusing APIs.

Implementation details include a Rest API gateway built with graphql‑java‑spring (Figure 3‑1) and a service flow where the client calls a /graphql prefixed Rest endpoint, which is mapped to a GraphQL query, resolved against the database, and finally translated into GraphQL syntax (Figure 3‑2).

Dynamic monitoring is achieved by overriding the method that provides tags to Spring Boot Actuator, thereby exposing the actual request URL to the /actuator/prometheus endpoint (Figures 3‑3 and 3‑4). The exposed metrics can be scraped by Prometheus (Figure 3‑5).

Flexible configuration is realized by defining GraphQL schema templates with Velocity and generating .graphqls files at runtime via Java annotations and reflection (Figure 3‑6). Developers only need to implement the SPI‑defined interfaces to add support for new micro‑services.

The visual API management platform dramatically improves development and operations efficiency, enabling rapid API creation, dynamic monitoring, and reduced duplication of effort.

In summary, constructing a GraphQL‑driven BFF layer allows iQIYI to aggregate multiple micro‑services, reduce backend duplicate development, and accelerate front‑end feature delivery. Backend developers only maintain new micro‑services and plug them into the BFF via SPI.

Key benefits include increased development efficiency, a low‑code platform for rapid API generation, easy monitoring with Prometheus, high throughput via Docker/K8s deployment, and simplified maintenance and extensibility.

Challenges remain: supporting dynamic schema extensions for ad‑hoc queries, limited Chinese documentation for Java implementations, and the need to migrate mapping storage from MySQL to more scalable solutions such as Zookeeper or Redis.

Future plans involve handling more diverse API request patterns, persisting API‑request mappings in a clustered store, and exploring a Go‑based GraphQL BFF to leverage better Kubernetes scaling characteristics.