根据我阅读的文章，GraphQL 在往返方面更节省资源，并且它还可以完成 REST 可以提供的功能。考虑到 Web 应用程序将从头开始，软件架构师和开发人员可能决定继续使用 REST 而不是 GraphQL 的原因是什么？此外，鉴于这是一个持续的项目，将从 Web 和移动端使用，并且需要 openID 连接。
【问题讨论】：
标签： rest web-applications architecture graphql
在我看来，除其他方面外，这也是用例的问题：
【讨论】：
这是一个相当广泛的问题，但我会尝试根据自己的经验回答。
REST 提供对特定资源的访问，例如用户或产品。请求的结果可能是您想要或使用什么数据的假设，即无论您是否使用所有数据，它都可能是关于该资源的一切。
还有N+1的问题。以用户拥有并属于多关系场景为例；使用 RESTful API，您可以向用户发出请求，例如/users/:id 然后向他们的所有关系发出请求，例如/users/:id/relationships，这已经是两个请求了。可能存在关系端点的假设，以在结果数组中包含关系（朋友、家人等）和用户，但如果 API 不这样做 假设，您将不得不向每个用户端点发出请求，以获取每个关系中每个用户的数据。
这个例子也可以更深入；如果您想要所有二级关系（例如朋友的朋友）怎么办？
GraphQL 解决了这个问题，它允许您明确提出您的需求。您可以构造一个查询以深入返回数据：
query myQuery($userId: ID!) {
user(id: $userID) {
id
name
relationships {
id
type
user {
id
name
relationships {
id
type
user {
id
name
}
}
}
}
}
}
片段可以稍微清理一下，并且可能存在递归问题，但您应该明白这一点；一个请求即可获得所需的所有嵌套数据。
如果您不太需要这种嵌套或相互连接的结果集，那么 GraphQL 可能无法在收益和复杂性之间进行权衡。
但是，我发现 GraphQL 的最大好处之一是它的可扩展性和自文档化。
【讨论】：
可能有多种原因。我相信这是非常主观的，但对我来说这是基于：
REST 是古老而稳定的方式。它被大多数人使用，并为 API 消费者提供了一个简单的接口。因为它很旧（绝不是坏事），所以大多数开发人员都知道它并且知道如何使用它。
GraphQL 是镇上的新人。它确实为大多数系统节省了一些性能（往返和有效负载），但确实改变了我们对后端的看法。它不提供资源端点，而是提供数据模型的图，并让消费者决定要获取哪些数据。
就“新人”而言，GraphQL 还没有经过实战考验。它对大多数人来说是新的，因此基本上没有被其他人、先行者和初创公司采用。
但同样，这是一个带有主观答案的主观问题。目前我正在为一家初创公司使用 GraphQL 来测试它的耐用性，看看它是否能解决我们的需求。到目前为止，它确实如此。如果您要决定是否使用 REST 或 GraphQL 开始一个新项目，您应该考虑您的需求以及您希望花费多少金钱/时间来学习新事物，而不是做您所知道的事情并更快地实现您的目标。
【讨论】：