使用GraphQL进行微服务互通是否有意义？

Question

关于使用GraphQL作为微服务前端的API网关，我已经读了很多。 但是我想知道GraphQL相对于Rest的所有优势是否也与微服务之间的通信不相关。 任何输入，利弊和成功使用示例都将受到赞赏。

Answer 1

要考虑的主要笔记 r：

• GraphQL不是魔术子弹，也不比REST“更好”。只是不同。
• 您绝对可以同时使用两者，因此不是两者皆有。
• 根据特定的用途，GraphQL（或REST）的规模可以大到大。
• GraphQL和REST并非完全替代：
  • GraphQL是一种查询语言，规范和工具集合，旨在通过HTTP在单个端点上运行，以优化性能和灵活性。
  • REST是一种利用其存在的协议的统一接口进行通用通信的体系结构样式/方法。

避免在微服务之间普遍使用GraphQL的某些原因：

• GraphQL主要在客户端需要一个灵活的响应而无需更改服务器代码即可控制时非常有用。

  • 当您授予客户端服务对所输入数据的控制权时，它可能导致公开太多数据，从而损害正在服务的服务上的封装。这是系统可维护性和变更能力的长期风险。

• 在微服务之间，延迟远没有客户端服务器之间的问题大，因此聚合功能也是如此。

• 当您有很多服务时，统一的界面确实很有用-但是graphQL可能会适得其反。

• 由QueryQL定义的灵活查询在性能优化方面可能更具挑战性。

• 立即更新对象的层次结构（graphQL自然结构）可能会增加原子性，幂等性，错误报告等方面的复杂性。

回顾：

• GraphQL非常适合服务器之间的通信，但很可能很适合一小部分用例。
• 您在服务之间是否有API网关的用例？也许这是您应该问自己的问题。 GraphQL只是一个（受欢迎的）工具。
• 像往常一样，最好将问题与工具匹配。

Answer 2

我没有在微服务环境中使用GraphQL的经验，但我倾向于认为它对微服务而言不是最好的。

为@Lior Bar-On的答案添加更多颜色，GraphQL更像是一种查询语言，并且本质上更具动态性。由于单个请求，它通常用于聚合数据集，这反过来又可能需要在微服务环境中对许多服务做出许多请求。同时，这也增加了必须转换来自各个信息源（其他微服务）的信息收集的复杂性。当然，复杂程度取决于您的服务的微细程度以及您可能希望支持的查询。

另一方面，我认为使用MVC架构的整体实际上可能会占上风，因为它拥有可查询的较大数据主体。