HATEOAS 与 GraphQL 为微服务设置的决策标准？ [已关闭]

Question

我最近与某人交谈，他说他们将完全跳过 HATEOAS REST 端点的开发，转而使用 GraphQL。因此，我很好奇决定何时使用 GraphQL 与 HATEOAS 的标准是什么，或者 GraphQL 一般而言对于 API 网关/边缘服务器架构来说是更好的选择吗？

Answer 1

各自的优缺点是：

GraphQL

专业人士：

• 提供对返回数据的精细控制，以避免不必要的流量
• 无需反复返回井获取附加/“后续”数据
• 从上面的内容来看，它允许软件设计者通过减少延迟来提供出色的性能 - 每个查询都指定它需要的所有内容，而 GraphQL 实现只需一个客户端<->服务器事务
即可组装和交付它
• 缓慢弃用而不是版本化 API 的可能性
• 它是一种查询语言
• 内省是内置的

缺点：

• 不处理缓存（尽管现在有库可以处理这个问题）

仇恨/休息

专业人士：

• 缓存是一个很好理解的事情
• 相对成熟且易于理解
• 大量基础设施，例如 CDN 来分散负载
• 非常适合微服务
• 可以上传文件

缺点：

• “回井”问题
• 没有严格规定
• 服务器和客户端的每个实现都必须做出自己的决定
• 查询不规范

结论

一个有趣的比较是，人们使用 GraphQL 作为 REST API 的前端，但头脑清醒的人不会考虑做相反的事情。如果您采用联合/微服务设计，那么一个 GraphQL 服务器为其他服务器提供前端，他们可以在前端和微服务之间使用通用的 API 规范；如果微服务是 REST 模式，则这一点不太确定。

我认为，只要您牢记要问的正确问题，GraphQL 将成为精心设计的系统的重要组成部分。不幸的是，是否完全跳过 HATEOAS“取决于情况”。

来源

我自己的经验，加上 Phil Sturgeon 的 GraphQL 与 REST：概述

Answer 2

我喜欢 Ed 发布了我的概述的链接，但我认为还有另一篇文章比那篇文章更相关。

两者的状态表示完全不同。

https://apisyouwonthate.com/blog/representing-state-in-rest-and-graphql/

GraphQL 完全无法以有意义且标准化的方式提供一系列“后续步骤”，除了可能推送包含您应该尝试找到的潜在相关突变的字符串数组之外。

即使你这样做了，它也肯定无法帮助你与其他 HTTP API 进行通信，这真是一个耻辱。

总之，就是那篇文章了！ :)