Hasura GraphQL Engine 中基于过滤聚合的排序问题解析

背景介绍

在现代应用开发中，GraphQL 已成为数据查询的重要标准。Hasura GraphQL Engine 作为一个开源的 GraphQL 服务，能够自动将数据库结构转换为 GraphQL API，极大简化了后端开发工作。然而，在实际应用中，开发者经常会遇到一些高级查询场景的挑战，特别是在需要结合聚合计算和排序功能时。

问题场景分析

一个典型的使用场景是：我们需要查询用户列表，同时计算每个用户在不同角色下的关联记录数量（如"租户"和"管理员"角色下的建筑关联数量），并基于这些聚合结果进行排序。

在原生SQL中，这类查询可以通过条件聚合函数轻松实现：

SELECT 
  u.id,
  u.full_name,
  COUNT(CASE WHEN utb.role = 'tenant' THEN 1 END) AS user_houses_count,
  COUNT(CASE WHEN utb.role = 'administrator' THEN 1 END) AS user_jobs_count
FROM users u
LEFT JOIN users_to_buildings utb ON u.id = utb.user_id
GROUP BY u.id, u.full_name
ORDER BY user_houses_count ASC

然而，在Hasura GraphQL Engine中，直接通过GraphQL查询实现这种基于过滤聚合的排序却存在一定限制。

技术限制详解

Hasura当前版本在处理这类查询时存在两个主要限制：

1. 别名不可用于排序：虽然可以在查询中使用字段别名（如user_houses和user_jobs），但这些别名不能直接用于排序输入中，因为排序输入是基于GraphQL输入类型定义的。

2. 聚合过滤与排序分离：当直接使用关联表的聚合排序时，无法保留查询中定义的过滤条件，导致排序结果不准确。

现有解决方案评估

目前Hasura官方推荐的解决方案是通过数据库视图(VIEW)来预先定义过滤逻辑：

1. 创建针对不同角色的视图：

CREATE VIEW buildings_tenant AS 
SELECT * FROM buildings WHERE role = 'tenant';

CREATE VIEW buildings_admin AS 
SELECT * FROM buildings WHERE role = 'administrator';

2. 在Hasura中跟踪这些视图并建立关联关系

3. 使用这些视图的聚合字段进行排序

虽然这种方法可行，但它存在几个缺点：

• 需要额外的数据库对象维护
• 当过滤条件变化时需要创建多个视图
• 不够灵活，无法动态适应前端查询需求的变化

技术实现原理

从技术实现角度看，Hasura的排序功能是基于PostgreSQL的查询生成机制。当执行GraphQL查询时，Hasura会将其转换为优化的SQL查询。对于聚合排序，Hasura会生成包含COUNT或SUM等聚合函数的子查询。

问题在于，Hasura的查询生成器目前没有机制将主查询中的过滤条件传播到用于排序的聚合子查询中。这导致了排序时过滤条件丢失的问题。

潜在改进方向

从架构设计角度，Hasura可以考虑以下改进方向：

1. 增强聚合排序的过滤支持：允许将查询中的过滤条件自动应用到排序聚合中。

2. 扩展排序输入类型：支持在排序条件中指定额外的过滤参数。

3. 引入计算字段排序：支持基于查询中定义的虚拟字段（如别名聚合）进行排序。

开发者应对策略

在当前版本限制下，开发者可以采取以下策略：

1. 视图方案：如官方建议，使用数据库视图预先定义常用过滤条件。

2. 自定义函数：创建PostgreSQL函数封装复杂逻辑，通过计算字段暴露给GraphQL。

3. 应用层处理：对于小型数据集，可以在应用层获取数据后进行排序（不推荐大数据集）。

4. 混合查询：结合Raw SQL查询与GraphQL查询，在特殊情况下直接使用SQL查询。

性能考量

在处理大型数据集时，排序性能尤为重要。基于视图的方案通常性能较好，因为：

• 视图可以被索引优化
• 查询计划器可以更好地优化固定条件的查询
• 减少了运行时计算开销

而动态过滤条件的排序可能需要更复杂的查询优化，这也是Hasura当前实现的挑战之一。

总结

Hasura GraphQL Engine在简化数据访问层方面表现出色，但在处理复杂排序场景时仍存在改进空间。理解当前的技术限制和解决方案，有助于开发者设计更健壮的数据访问层。随着Hasura的持续发展，期待未来版本能够提供更灵活的排序功能，进一步减少开发者需要手动处理数据库层的需求。