Rest GraphQL有什么缺点吗？

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

缺点：

• 您需要学习如何设置GraphQL。生态系统仍在快速发展，因此你必须跟上
• 您需要从客户端发送查询，您可以只发送字符串，但如果您想要更舒适和更高速缓存，您可以在客户端中使用客户端库->额外的代码

---

• 在得到结果之前，您需要预先定义模式=>额外的工作
• 您需要在服务器上有一个graphql端点=>您还不知道的新库
• Graphql查询的字节数比简单地转到REST端点要多
• 服务器需要进行更多处理以解析查询并验证参数

但是，这些都被以下因素所抵消：

• GraphQL不难学
• 额外的代码只有几KB
• 通过定义一个模式，您将避免以后进行更多的工作修复bug和持久的复杂升级
• 有很多人转向GraphQL，因此有一个丰富的生态系统正在开发，有着优秀的工具
• 在生产环境中使用持久查询时（将GraphQL查询替换为简单的ID和参数），实际上发送的字节比REST少
• 传入查询的额外处理可以忽略不计
• 为API和后端提供了一个干净的解耦，允许在后端改进上进行更快的迭代

---

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

您可以允许/不允许几个字段，这一事实使得连接非常重要（不简单）。这会导致额外的查询

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

呼叫的速率限制变得很困难，因为现在用户可以在一次呼叫中触发多个查询

---

提示：在使用javascript/node的情况下，使用facebook的数据加载器减少查询次数

我发现了一些重要的问题，到目前为止，主要问题是：

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

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

网络级缓存：由于通过HTTP（单个端点中的POST）使用GraphQL的常见方式，网络级缓存变得很难。解决这个问题的一种方法是使用持久化查询

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

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

---

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

它每年都在变得越来越好，到目前为止，GraphQL的应用正在增长，因此，以前在其他答案中强调的许多问题都有更多的解决方案。 但为了承认仍然阻碍公司将所有资源投入GraphQL的因素，我想列出一些问题和解决方案，然后是未解决的问题和解决方案

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

但还有一些情况可以算作不利因素：

• 样板过度性（我的意思是，对于创建例如新查询，您需要定义模式、解析器和解析器内部，以明确说明GraphQL如何解析内部的数据和字段，在客户端创建与此数据完全相关的字段的查询）
• 错误处理-我需要说，它与REST的比较更相关。在这里有可能，但在 同时，它比在REST中要复杂得多
• 身份验证和授权——但正如我所说，社区正以惊人的速度增长，而且 为了这个目标

---

总而言之，GraphQL只是用于特定目标的工具，当然它不是解决所有问题的灵丹妙药，当然也不是REST的替代品。

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

文件下载/Uploa的实现