NestJS+React+GraphQL：用变量还是上下文传递filialIds更优？

我的技术栈是后端NestJS+MongoDB，前端React，通过GraphQL实现前后端通信。用户登录后，我会在请求头中设置filialIds；查询时需要通过Guard校验用户的filialIds与角色，服务层也需要获取filialIds。目前有两种实现方式：通过上下文（请求头）传递，或者通过GraphQL查询变量传递，想知道哪种更合适。

当前请求头实现方式代码 #

前端设置请求头 #

const authLink = setContext((_, { headers }) => {     
    const token = localStorage.getItem(`${localStorageAppPrefix}.token`);

    return {
      headers: {
        ...headers,
        filialIds: `${localStorage.getItem(`${localStorageAppPrefix}.filialIds`) ?? ''}`,
        authorization: token ? `Bearer ${token}` : '',
      },
    };

});

export const client = new ApolloClient({ 
    link: authLink.concat(httpLink), 
    cache: new InMemoryCache(), 
});

NestJS Guard校验 #

@Injectable() 
export class RolesGuard implements CanActivate { 
    constructor(private reflector: Reflector) {}

    async canActivate(context: ExecutionContext): Promise<boolean> {
      const ctx = GqlExecutionContext.create(context);
      const requiredRoles = this.reflector.getAllAndOverride<UserRoles[]>(
        ROLES_KEY,
        [context.getHandler(), context.getClass()],
      );
    
      if (!requiredRoles) {
        return true;
      }
    
      const queryFilialIds =
          safeJSONParse(ctx.getContext()?.req?.headers?.filialids ?? '') ?? [];
      const { roles, filialIds } = ctx.getContext()?.req?.user ?? {};
    
      const hasRequiredFilials = filialIds?.every(
          (filialId) => queryFilialIds.indexOf(filialId) !== -1,
      );
    
      const hasRequiredRoles = requiredRoles.some(
          (role) => roles?.indexOf(role) !== -1,
      );
    
      return hasRequiredRoles || hasRequiredFilials;
    }
}

服务层获取filialIds #

async getCount(context): Promise<number> {
  const filialIds =
    JSON.parse(context?.req?.headers?.filialids ?? '') ?? [];
  return this.userModel.countDocuments({ filialIds: { $in: filialIds } });
}

备选：查询变量传递方式代码 #

const { data } = useQuery(GET_USER, {
  variables: { filialIds: filialIds ?? [] },
  skip: !filialIds?.length,
});

两种方式对比与推荐 #

请求头方式的优势 #

• 全局一致性：一次配置后，所有GraphQL请求自动携带filialIds，无需在每个查询/突变中手动添加变量，减少前端重复代码，避免遗漏。
• 符合身份权限类信息传递习惯：filialIds属于用户身份关联的权限范围信息，和authorization token放在请求头中，逻辑上更统一，符合行业惯例。
• 后端逻辑更集中：Guard和服务层可以统一从请求上下文获取信息，无需在每个Resolver的参数中声明filialIds变量，减少后端代码冗余。

请求头方式的潜在问题 #

• 调试稍显繁琐：在GraphQL Playground或调试工具中，需要手动设置请求头，不像变量那样直接在查询面板中输入修改。
• 序列化风险：需要保证前后端数组转字符串、解析的逻辑一致，比如代码中用到的safeJSONParse和JSON.parse，要做好格式错误的兼容处理。

查询变量方式的优势 #

• 查询语义更清晰：变量明确出现在查询语句中，查看查询时就能直接知道请求依赖filialIds参数，可读性更强。
• 调试更直观：在调试工具中可以直接修改变量值，快速验证不同filialIds下的查询结果。

查询变量方式的潜在问题 #

• 代码冗余严重：每个需要filialIds的查询/突变都要手动添加变量参数，前端容易遗漏，后端每个Resolver也需要声明该变量，增加重复代码量。
• 权限校验风险：如果某个查询忘记传递filialIds变量，Guard可能无法正确校验，需要额外处理空值情况，增加逻辑复杂度。
• 边界混淆：filialIds是用户权限范围标识，属于请求上下文的一部分，而非业务查询参数，放在变量中会混淆业务参数和身份权限参数的边界。

最终推荐 #

优先选择**请求头传递filialIds**的方式，原因如下：

1. 减少前后端重复代码，提升开发效率，避免遗漏。
2. 权限类信息放在请求头中，逻辑上更合理，符合行业惯例。
3. 后端可以统一在上下文层面处理，Guard和服务层的逻辑更集中，便于维护。

如果担心调试问题，可以在NestJS中添加开发环境专属中间件，允许从查询变量中覆盖请求头的filialIds，调试时灵活切换，生产环境仍使用请求头方式。

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