TypeGraphQL结合TypeORM是否会根据客户端请求自动优化生成SQL查询？

1. 实际执行的SQL是什么？ #

你给出的示例代码实际会执行SELECT * FROM user的全量查询。
原因很简单：TypeGraphQL本身和ORM的查询逻辑是完全解耦的，你直接调用User.find()没有指定查询字段，TypeORM默认就会查询表的所有字段。TypeGraphQL只会在返回结果阶段，从拿到的完整User实例里提取客户端请求的id和name字段返回，其余字段会被直接丢弃。

2. 全量查询场景下GraphQL相比REST的优势 #

即使第一层查询走了全量字段，GraphQL的核心优势依然成立：

• 嵌套查询的效率优势：如果涉及多层关联查询（比如查用户+用户发布的文章+文章的评论），REST接口要么需要多次调用不同接口，要么后端需要提前写死聚合接口返回所有可能用到的关联数据，冗余非常严重。而GraphQL可以一次请求拿到所有需要的嵌套数据，不需要后端额外开发定制接口。
• 无版本迭代成本：后续业务需要新增返回字段时，只需要在实体类和GraphQL类型定义里新增字段即可，老客户端的请求不受任何影响，不需要像REST那样维护多版本接口。
• 内置类型校验：客户端请求的字段不存在、参数类型不符合要求时，会直接在GraphQL的Schema校验阶段返回错误，不需要后端业务逻辑重复做参数校验。

3. 实现动态生成指定字段SQL的方案 #

有两种常用的落地方案：

手动解析查询字段 #

你可以通过TypeGraphQL的@Info()装饰器拿到GraphQL的查询上下文，解析出客户端请求的字段列表，再传入TypeORM的查询参数中。可以用graphql-parse-resolve-info库简化解析逻辑，示例代码如下：

import { Resolver, Query, Info } from 'type-graphql';
import { GraphQLResolveInfo } from 'graphql';
import { parse, FieldsByTypeName } from 'graphql-parse-resolve-info';

@Resolver()
class UserResolver {
  @Query(() => [User])
  async user(@Info() info: GraphQLResolveInfo): Promise<User[]> {
    const parsedInfo = parse(info) as FieldsByTypeName;
    // 提取客户端请求的User类型字段
    const requestedFields = Object.keys(parsedInfo.fields.User.fields);
    // 传入select参数实现只查指定字段
    return await User.find({ select: requestedFields as (keyof User)[] });
  }
}

使用集成封装库 #

不想手动写解析逻辑的话，可以直接用成熟的集成方案：

• 可以改用MikroORM，它原生支持和TypeGraphQL配合，自动根据请求字段生成对应的查询SQL，还自带关联查询的N+1问题优化
• 也可以用TypeORM的第三方扩展包，比如type-graphql-typeorm-loader，封装了字段解析、关联查询优化的能力，直接接入即可使用。

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