我是第一次实现 GraphQL 服务器。在阅读文档时，我发现建议使用带有 typeDefs 的 gql (https://www.apollographql.com/docs/apollo-server/migration-two-dot#existing-schema)。我知道 gql 的目的，但如果构造函数在内部解析 typeDefs，我不明白为什么它需要 Apollo Server。我的代码在有和没有它的情况下都有效。
为什么推荐使用gql？
更新 v1
由于将 gql 与 eslint 等工具结合使用，我立即注意到答案中描述的好处。如果没有 gql，可用的工具就不够聪明，无法区分模板字符串和 graphql。
【问题讨论】：
标签： javascript graphql apollo-server
这实际上只是 Apollo 团队的一个设计选择。 graphql-tools，这是 apollo-server 在后台使用的，支持 typeDefs 参数的多种类型，包括一个函数：
export type ITypeDefinitions = ITypedef | ITypedef[];
export type ITypedef = (() => ITypedef[]) | string | DocumentNode;
因为构造函数ApolloServer 实际上只是将您的typeDefs 传递给graphql-tools'makeExecutableSchema，所以您可以将架构的类型定义作为字符串或函数传递，它仍然可以工作。至少在 JavaScript 中。 TypeScript 定义实际上明确指定 DocumentNode 作为类型，所以如果你使用 TypeScript，那就不行了。
为什么apollo-server 明确要求您传入DocumentNode（这是graphql-tag 返回的内容）？正如一位 Apollo 开发人员在 this PR 中指出的那样：
支持非标记模板文字字符串作为 typeDefs... 可以定义没有 gql 标记的文档，这可能很诱人，但值得提醒自己的是，该标记具有一定的价值，因为它使更容易进行静态分析，自动检测字符串操作/变量插值（这通常是一种反模式），并提供更普遍的编辑器语法高亮支持。
如果您传入typeDefs，您应该确保将它们作为DocumentNode 传入，最简单的方法是使用gql 标签。传入其中一种其他类型似乎可行，但文档和类型定义清楚地表明您不应该这样做。请记住，Apollo Server 总是会在未来的版本中引入逻辑，当传入错误的类型时，如果此类代码尚不存在，则会导致意外行为。
【讨论】：