GraphQL有什么缺点吗？

Question

所有关于GraphQL的文章都会告诉你它有多棒，但它有什么缺点或缺点吗？谢谢。

Answer 1

缺点：

• 您需要学习如何设置GraphQL。生态系统仍在快速发展，所以你必须跟上。
• 您需要从客户端发送查询，您只需发送字符串，但如果您想要更多的舒适和缓存，您将使用客户端库 - ＆gt;您客户
中的额外代码
• 您需要事先定义架构=＆gt; 之前的额外工作
• 您的服务器上需要有一个graphql端点=＆gt;您还不知道的新图书馆
• Graphql查询更多字节，而不是简单地转到REST端点
• 服务器需要更多处理来解析查询并验证参数

但是，这些不仅仅是因为这些：

• GraphQL 并不难理解
• 额外的代码只有几KB
• 通过定义架构，您将阻止更多的工作修复错误并忍受毛茸茸的升级
• 有很多人转而使用GraphQL，因此有一个丰富的生态系统正在开发，具有出色的工具
• 在生产中使用持久性查询时（仅使用ID和参数替换GraphQL查询），实际上发送少于字节而不是使用REST
• 传入查询的额外处理可以忽略不计
• 提供干净的API和后端解耦可以更快地迭代后端改进

Answer 2

我找到了一些重要的concerns for anyone considering using GraphQL，到目前为止，要点是：

无限深度查询：GraphQL无法以无限深度进行查询，因此如果您有一棵树并希望在不知道深度的情况下返回分支，则必须进行一些分页。

特定响应结构：在GraphQL中，响应与查询的形状相匹配，因此如果您需要在非常特定的结构中进行响应，则必须添加转换层以重塑形状回应。

网络级缓存：由于通常使用GraphQL（通过单个端点进行POST），因此网络级缓存变得很难。解决它的方法是使用持久查询。

处理文件上传：GraphQL规范中没有关于文件上传的内容，并且突变不接受参数中的文件。要解决此问题，您可以使用其他类型的API（如REST）上传文件，并将上传文件的URL传递给GraphQL变异，或者将文件注入执行上下文，这样您就可以将文件放在解析器函数中。

不可预测的执行：GraphQL的本质是您可以查询组合所需的任何字段，但这种灵活性不是免费的。有一些值得关注的问题，比如Performance和N + 1 Queries。

超级简单的API ：如果您的服务公开了一个非常简单的API，GraphQL只会增加额外的复杂性，因此简单的REST API可以更好。

Answer 3

我在graphQL中遇到的最大问题是，如果您使用关系数据库，则使用连接。

1. 您可以允许/禁止一些字段，这使得连接变得非常简单（不简单）。这导致额外的查询。

2. 此外，graphql中的嵌套查询会导致循环查询，并且使服务器崩溃。必须格外小心。

3. 限制电话变得困难，因为用户可以在一次通话中触发多个查询。

提示：使用facebook的dataloader减少javascript / node的查询次数

Answer 4

它每年都在变得越来越好，并且就目前而言，GraphQL的community正在增长，结果，对于许多以前在其他答案中都强调的问题，有更多的解决方案。 但是要承认将所有资源投入GraphQL仍然使公司陷入困境，我想列出一些问题和解决方案，然后是未解决的问题和解决方案。

• 网络级缓存-正如Bruno所说的那样，它是持久查询 当然，您可以在客户端上进行缓存，没有人阻止您在数据库级别甚至Redis上使用缓存。但是当然，由于GraphQL只有一个端点，并且每个查询都不同-与使用REST相比，执行这种类型的缓存要复杂得多。
GraphQL中的
• 嵌套查询导致循环查询，并且可能导致 服务器-各种各样的解决方案已不再是问题。 其中有些列出了here
• 处理文件上传-我们已经有lots个solutions

但是还有更多的情况可以算作不利条件：

• 样板过度 （这是指，例如，对于创建新查询，您需要定义架构，解析器以及在解析器内部以明确说明GraphQL如何解析您的数据和内部字段，在客户端使用与该数据完全相关的字段创建查询）
• 错误处理 -我需要说的是，它与与REST的比较关系更大。 apollo可能在这里，但在 同时它比REST中复杂得多
• 身份验证和授权 -但正如我所说，社区正在以惊人的速度增长，already couple of solutions为此目标。

总而言之，GraphQL只是实现特定目标的工具，并且可以肯定，它并不是解决所有问题的灵丹妙药，当然也不是REST的替代品。

Answer 5

拥有一个端点并公开所有数据真的很棒。我发现GraphQL需要考虑以下几点：

1. 文件下载/上传的实现比较棘手（对于大文件，转换为字符串可能不是最佳选择）
2. 前端和后端都有很多样板代码和架构代码。
3. 遵循并支持GraphQL规范中提供的分页。
4. 允许自定义顺序和字段排序的优先逻辑。例如，如果我们获取用户数据以及相关的组和角色。用户可以根据用户名，组名或角色名对数据进行多种排序。
5. 身份验证和授权将取决于后端框架。
6. 确保为每个graphql命令触发单个查询的后端优化和数据库支持可能会比较棘手。

此外，在实施之后应该考虑专业人士：

1. 非常灵活，可以支持新项目并更新现有行为。

2. 易于实施的参数和自定义顺序添加条件

3. 使用大量自定义过滤器，并摆脱所有需要创建的操作，例如，用户可以将id，name等作为参数并执行过滤。另外，过滤器也可以应用于用户中的组。

4. 通过创建包含所有GraphQL查询和变异的文件，可以轻松测试API。
一旦理解了概念，突变就变得简单明了且易于实现。
5. 获取多个深度数据的强大方法。
6. 对Voyager和GraphiQL UI或Playground的支持使其易于查看和使用。
7. 使用有效的描述方法定义架构时易于文档编制。

Answer 6

我认为目前graphql必须是后端体系结构的一部分，对于文件上传，您仍然可以使用常规api