GraphQL vs gRPC：该选哪种现代 API？

在经典的 REST 之外，有两种现代 API 技术因解决了具体问题而格外突出：GraphQL，让客户端对其请求的数据拥有完全控制；以及 gRPC，一种用于服务间通信的高性能二进制协议。它们有时被当作可替代的方案，但实际上各自在不同领域大放异彩：GraphQL 面向客户端，gRPC 用于内部服务之间。理解二者的区别，能避免在错误的地方用错工具以及由此带来的代价。

本文我们对比 GraphQL 和 gRPC，梳理各自的优势与局限，并说明何时适合采用哪一种。

什么是 GraphQL

GraphQL 是一种用于 API 的查询语言，客户端可以通过单一入口精确请求所需的数据，不多也不少。它最大的优势在于面向客户端的灵活性：避免了多次调用和多余数据，因此在一个界面需要汇集多个来源的信息、或存在许多需求各异的客户端类型时尤为理想。它使用可读的文本格式，并能很好地从浏览器使用。其代价是服务端复杂度更高，且缓存更难处理。

什么是 gRPC

gRPC 是一种高性能协议，使用 HTTP/2 和一种紧凑的二进制格式（Protocol Buffers）让服务彼此通信。它最大的优势在于速度与效率：二进制消息非常轻量且快速，支持双向流式传输，并能根据严格的契约自动生成代码。它在 microservices 之间的内部通信中大放异彩，因为那里对性能和低延迟至关重要。它的局限在于：没有一个中间层时，无法直接从浏览器使用。

关键差异

以下是 GraphQL 与 gRPC 之间差异最明显的几个方面：

• 用途：GraphQL 面向客户端；gRPC 用于服务到服务。
• 格式：GraphQL 用可读文本；gRPC 用二进制。
• 性能：gRPC 更快、更高效。
• 客户端灵活性：GraphQL 最高。
• 浏览器：GraphQL 原生可用；gRPC 需要中间层。
• 契约：gRPC 严格且自动生成；GraphQL 灵活。

不同领域，并非对手

尽管常被拿来比较，GraphQL 和 gRPC 很少争夺同一个问题。GraphQL 的诞生是为了解决面向客户端的复杂数据获取：一个需要在单个界面汇集大量数据的 Web 或移动 App。gRPC 的诞生是为了后端服务之间高效的内部通信。事实上，许多现代系统会同时使用两者：在面向客户端的边界用 GraphQL，在内部 microservices 之间用 gRPC，各得其所。

如何选择

当挑战在客户端一侧时选 GraphQL：汇集大量数据的丰富界面、需求各异的多种客户端类型，或需要避免多次调用和多余数据。当挑战在后端一侧时选 gRPC：高性能、低延迟且两端都可控的 microservices 内部通信。如果你真正的疑问是“向外部暴露数据”还是“连接内部服务”，那么这个问题本身就已经告诉你该用哪个了。另外别忘了，对许多场景而言，REST 仍是一个有效且更简单的选择。

在 AxiomTech，我们会根据你的客户端和架构，用最合适的技术——GraphQL、gRPC 或 REST——来设计现代 API。如果你正在确定你的系统将如何通信，欢迎与我们聊聊，我们会根据你的真实需求提供建议。