打字稿中不同GraphQL语法的优缺点

时间:2017-11-29 18:05:58

标签: typescript express graphql apollo

我一直在寻找关于GraphQL的不同教程,它们都是以不同的方式编写的。我想知道他们所有人的利弊是什么。另外,您如何在不同的文件中模块化类型,查询等?我看到的第一种方法是使用字符串来描述GraphQL架构,然后将其导出然后导入到架构文件中。这看起来像这样:

res

然后是下一种使用express-graphql包并使用对象来描述模式的方法。这看起来像这样:

const typeDefs = `
type Query {
  testString: String
}
`;

我见过的另一种方法是使用graphql文件。

这只是个人偏好还是使用一个而不是真正的好处?

据我所知,我提到的第一个可能缺少语法高亮,但这看起来与实际的graphql语法最接近。我首选的选择是使用graphql文件。但问题是如何将其全部模块化?如何将几个不同的.graphql文件合并在一起并在单个模式中使用它们?

2 个答案:

答案 0 :(得分:1)

如果您想在Node.js中使用带有TypeScript的GraphQL,可以查看TypeGraphQL

这个工具允许你通过使用装饰器定义typescript类来摆脱描述类型,查询,变异,args和输入的接口。 因此,您只有一个事实来源,无需跳过代码库来添加字段,更改其类型等。

答案 1 :(得分:0)

在模式文件或字符串中定义查询可以让您快速构建GraphQL接口原型。这非常适合入门并实施一些解析器。当架构增长时,架构定义也将大量增长。我们只有几种类型,但我们的模式文件超过1000 loc。这就是我们在JavaScript中定义类型并在定义中编写解析器的原因。大多数解析器都非常简单,并且使用包含实际类型解析逻辑的数据加载器。 new tool by GraphCool允许在模式定义中导入。这种方式使我的观点失败,并允许在使用模式语言的同时进行另一种扩展。

顺便说一下:GraphQL模式定义有语法高亮,例如:在Atom中通过language-babel