在Apollo网关服务器上实现GraphQL查询白名单的最优方案及查询equality探讨

方案1：基于AST标准化的校验 #

GraphQL查询的核心是抽象语法树（AST），语义相同的查询无论字符串格式、字段顺序、片段定义如何变化，标准化后的AST都是等价的，这是解决查询equality问题的根本思路：

• 启动阶段：用graphql核心库的parse方法将预定义的.graphql文件解析为AST，然后通过visit工具遍历AST做标准化处理：排序字段/参数名称、移除注释/空格/自动添加的__typename节点、统一片段引用的展开方式。处理完成后生成稳定的哈希值，将哈希与标准化AST（或对应的查询标识）存入映射表。
• 请求阶段：将传入的查询字符串同样解析为AST，执行完全一致的标准化流程，生成哈希后直接与映射表中的条目比对。
• 优势：彻底规避字段顺序、片段定义导致的校验失效问题，性能上只要缓存好预生成的哈希，单次请求的解析+标准化开销远低于全量字符串比对。

方案2：自定义持久化查询（替代弃用的persistgraphql） #

Apollo生态本身支持持久化查询机制，自己实现一套轻量版本即可：

• 启动阶段：为每个预定义查询生成唯一标识（可以是基于AST的哈希，也可以是UUID），将标识与对应的查询AST/标准化字符串存入网关缓存。
• 请求处理：客户端优先发送查询标识，网关直接通过标识匹配白名单中的查询；如果客户端发送完整查询，网关先将其转换为标识（通过AST标准化哈希），再校验是否在白名单内，同时可以返回标识给客户端，引导后续请求使用标识以降低带宽和校验成本。
• 优势：从根源上避免查询字符串的比对问题，同时提升请求性能，贴合Apollo的设计逻辑。

方案3：细粒度Schema校验规则 #

如果不需要严格匹配完整查询，而是需要控制允许的操作或字段，可以基于Schema自定义校验规则：

• 先明确白名单：允许的操作名称（如Query.getUser、Mutation.createOrder）、允许访问的字段集合。
• 网关接收到查询后，解析为AST，用graphql库的validate方法结合自定义规则校验：检查所有操作是否在允许列表内，所有用到的字段是否属于允许的字段集合。
• 优势：灵活性更高，适合需要动态调整白名单、或允许部分自定义查询但限制字段范围的场景；但如果要求严格匹配完整查询，此方案不适用。

优化现有字符串比对方案 #

如果不想替换现有架构，只需解决当前的equality问题：

• 放弃手动处理字符串，改用graphql库的print方法：将解析后的AST重新打印为标准化字符串。print方法会按照固定格式输出（如字段按名称排序、统一缩进），语义相同的查询最终输出的字符串完全一致。
• 流程调整：启动时将预定义文件parse为AST→print为标准化字符串→生成哈希存入映射表；请求时执行相同的parse→print→哈希→比对流程。
• 优势：无需大幅改动现有逻辑，就能解决字段顺序、空格、片段导致的校验不一致问题，可靠性远高于手动字符串处理。

内容的提问来源于stack exchange，提问作者Ivan Kravchenko