GraphQL Code Generator中获取查询字符串的最佳实践

在GraphQL开发中，我们经常需要将生成的TypeScript操作转换为原始查询字符串。本文将探讨在graphql-code-generator项目中实现这一需求的几种方法及其优缺点。

问题背景

当使用graphql-code-generator生成TypeScript操作类型时，开发者有时需要获取这些操作对应的原始GraphQL查询字符串。常见的使用场景包括：

• 调试时查看实际发送的查询
• 缓存机制中需要查询字符串作为键
• 某些特殊API需要原始查询字符串而非AST

解决方案比较

1. 使用graphql/language/printer

传统方法是使用graphql-js提供的printer工具：

import { print as getGraphQlQuery } from 'graphql/language/printer';
const query = getGraphQlQuery(MyGeneratedTypescriptOperation);

缺点：

• 会增加约32KB的gzipped包体积
• 在某些打包环境下可能出现模块解析问题
• 需要额外依赖graphql包

2. 直接访问AST的source属性

更轻量级的替代方案是利用生成的DocumentNode中已包含的原始查询信息：

export const getGraphQlQuery = (doc: DocumentNode) => {
    return doc.loc?.source.body ?? '';
};

优点：

• 零依赖，不增加包体积
• 直接访问原始字符串，无需转换
• 性能更高

注意事项：

• 需要确保生成的DocumentNode包含loc信息
• 在某些极少数情况下，source可能不存在

深入技术细节

graphql-code-generator在生成操作类型时，默认会保留原始查询文本作为AST节点的loc属性。这个设计原本是为了错误报告和调试，但我们可以巧妙利用它来获取查询字符串。

相比之下，graphql/language/printer的工作流程是：

1. 接收AST（抽象语法树）
2. 遍历整个AST结构
3. 重新生成查询字符串
4. 返回结果

这个过程不仅计算开销更大，而且引入了不必要的依赖。

最佳实践建议

基于项目实践，我们推荐：

1. 优先使用source.body直接访问 - 在大多数情况下这是最有效的方式
2. 添加类型保护 - 确保代码的健壮性：

function ensureGraphQLQuery(doc: DocumentNode): string {
    if (!doc.loc || !doc.loc.source) {
        throw new Error('DocumentNode缺少source信息');
    }
    return doc.loc.source.body;
}

3. 考虑自定义插件 - 如果需要频繁使用，可以扩展codegen配置直接生成查询字符串

性能考量

在大型应用中，选择正确的方法可能带来显著的性能提升：

• 包体积：减少32KB的gzipped大小
• 运行时：避免AST的遍历和重新生成
• 构建时：减少依赖和模块解析问题

结论

在graphql-code-generator生态中，获取查询字符串的最优解往往是利用已有的AST元数据而非引入额外工具。这种方案不仅更高效，还能保持应用的轻量级特性。开发者应根据具体需求选择最适合自己项目的方法。