Data Aggregation and GraphQL Adoption at Xianyu: Improving Development Efficiency

Overview: As business expands, traditional front‑end rendering + back‑end API development becomes costly for short‑lived activities. Xianyu explored data aggregation and introduced GraphQL to improve development efficiency.

Background: Front‑end wants structured data for direct rendering, while back‑end aims to provide domain APIs. Mock data and integration consume resources, slowing down rapid business growth. Data aggregation is proposed to let front‑end fetch data directly and free back‑end from low‑value work.

Solution: Data aggregation packs multiple service requests into a single call, returning all results at once, reducing network latency and simplifying data handling. Design principles include exposing generic data services, minimizing front‑end interaction, and using concurrent/async calls.

Data Aggregation 1.0: Xianyu built a lightweight (~1000 lines) decentralized service that registers in the service registry without code intrusion. Features: full concurrent calls, support for field selection, dependency calls, loop‑dependency checks, aliases, and merge calls.

@GraphQLDataFetcher(supportBatch = true)
@GraphQLDescription("查询用户信息")
public List
userInfos(List
userIds) {
    ResultDO
> users = readServiceClient.getBaseUserListByUserIds(StringUtils.join(userIds, ","));
    List
userDOList = users.getModule();
    //按入参userId的顺序排序
    return ObjectUtils.collectionOrder(userIds, users.getModule(), BaseUserDO::getUserId);
}

GraphQL Adoption: Xianyu uses TQL (Alibaba’s Java GraphQL implementation) which offers low‑intrusion integration, online IDE, execution strategies, and merge‑call optimization. The unified GraphQL gateway API executes queries with arguments, declared variables, and context.

public ExecutionResult execute(String requestString, Map
arguments,
                               Set
declaredVariables, Object context) {
    return execute(requestString, arguments, declaredVariables, context, false);
}

Frontend changes: Calls are switched to the unified GraphQL endpoint, using GraphQL syntax to specify required fields. Simple request APIs allow passing only an ID without writing query strings.

//graphqlAPI调用接口，id:ql语句id，param ql参数
request(graphqlAPI, id, param);

Benefits: Within six months, the aggregation service supported 30+ pages, covering >80% of similar requirements and cutting development cost by over 50%. GraphQL reduced R&D cost, shortened launch cycles, and enabled rapid page composition. Typical GraphQL overhead is <20 ms; most latency comes from underlying service calls.

Challenges: Response structure not always friendly, security concerns (unencrypted multi‑query strings), and incomplete meta‑information for services, leading to higher learning curve.

Conclusion: Data aggregation and GraphQL significantly lowered development effort and improved flexibility for both front‑end and back‑end teams at Xianyu, with plans to extend usage beyond Weex/H5 to native platforms.