HATEOAS vs为微服务设置的GraphQL决策标准？

Question

我最近和一个人说话,他们说他们正在完全跳过HATEOAS REST端点的开发,转而支持GraphQL.所以我很好奇为什么标准设置用于决定何时使用GraphQL与HATEOAS,或者GraphQL是一般的API网关/边缘服务器架构的更好选择？

Answer 1

每个人的利弊是:

GraphQL

优点:

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

缺点:

• 不处理缓存(虽然现在有图书馆可以处理这个)

HATEOAS/REST

优点:

• 缓存是一个众所周知的问题
• 相对成熟且易于理解
• 许多基础设施,例如CDN来分散负载
• 非常适合微服务
• 文件上传是可能的

缺点:

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

结论

一个有趣的比较是人们使用GraphQL作为REST API的前端,但是在他们正确的思想中没有人会考虑进行相反的操作.如果您选择联合/微服务设计,那么其他一个GraphQL服务器前端,他们可以在前端和微服务之间使用API​​的通用规范; 如果微服务是REST,这不太确定.

我认为,只要你想到正确的问题,GraphQL将成为精心设计的系统的重要组成部分.不幸的是,是否完全跳过HATEOAS,"它取决于".

来源

我自己的经验,加上Phil Sturgeon的GraphQL与REST:概述

Answer 2

我喜欢Ed在我的概述中发布了一个链接，但我相信还有另一篇文章比那篇文章更具针对性。

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

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

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

即使这样做，它肯定也无法帮助您与其他HTTP API通信，这实在令人遗憾。

无论如何，这就是那篇文章！:)