你能比较一下 GraphQL 和 tRPC 吗?

介绍

Twitter上有很多关于“GraphQL与tRPC”的讨论，用于为您的应用程序构建现代后端。GraphQL 近年来作为 REST 事实上的继承者而变得流行起来，而 tRPC 解决了全栈应用程序中的端到端安全问题。这就像将苹果与橙子进行比较。

GraphQL 是一种查询语言，tRPC 是一种库。

作为过去几年使用 GraphQL 的开发人员，这促使我比较两者，看看他们都擅长什么（以及他们不擅长什么）。

文章修改和引用与：https://gethackteam.hashnode.dev/can-you-compare-graphql-and-trpc

正文

但首先;你可能用错了 GraphQL

GraphQL 是 API 的查询语言，它不是 REST 的一对一替代品。这是一种以比 REST 更灵活的方式查询 API 的方法，使您能够控制请求的响应。在许多Twitter对话中，我发现人们将GraphQL与REST进行比较，这与GraphQL不同。此外，GraphQL 类型系统并不意味着用于端到端类型安全，至少不是以第一种方式。而是作为记录 API 并确保 API 的运行时类型正确的一种方式。

我们可以将 GraphQL 与 tRPC 进行比较吗？

GraphQL 是 API 的查询语言，而 tRPC 是一组用于构建端到端类型安全 API 的库。如前所述，这就像将苹果与橙子进行比较。但是，让我们分解它们并了解它们的特征。

GraphQL 是一种查询语言

GraphQL API 通常使用 HTTP 作为传输层，GraphQL 查询作为 POST 请求发送到 API。然后，API 处理查询并将结果作为 JSON 响应返回。这与 REST API 的工作方式相同，但 GraphQL 是一种查询语言，而不是协议。这意味着您可以在任何传输层和您想要的任何协议上使用 GraphQL。这也是为什么你可以在前端应用程序中使用 GraphQL 的原因，因为它只是一种查询语言。

GraphQL 本身只不过是一种查询语言，由 GraphQL 实现库和框架根据其规范实现这种查询语言。这意味着有许多不同的方法来实现 GraphQL，并且有许多不同的方法来使用 GraphQL。这也是为什么在前端应用程序中有许多不同的方法使用 GraphQL 的原因。

tRPC 是一个库

tRPC 是一组库，它使用 TypeScript 来确保整个应用程序中的类型安全。其主要目的是使在单个代码库中构建端到端类型安全应用程序变得容易。基础是 tRPC 服务器，可在其中定义终结点（或路由）、这些终结点的类型定义，并处理与数据源（如数据库）的任何连接。

可以使用 tRPC 客户端库在前端应用程序中使用 tRPC API。您不会直接发送 HTTP 请求来获取数据，而是让 tRPC 客户端为您处理此问题，几乎就像 API 的 ORM 一样。此客户端可以进行强类型 API 调用，而无需依赖代码生成。您可以将 TypeScript 类型从服务器直接导入到前端应用程序中，而无需生成任何代码。

GraphQL 和 tRPC 的区别是什么？

这是一个非常主观的问题，但我认为了解 GraphQL 和 tRPC 的区别很重要。这样，您可以自己决定要在应用程序中使用的内容。

GraphQL 非常适合查询多个数据源

GraphQL 擅长将多个数据源组合到单个查询中。GraphQL 通常用于数据建模和架构，它非常适合此。例如，如果要查询来自一个服务（如无头 CMS）的数据和来自另一个服务（假设数据库）的数据，则可以使用 GraphQL 在单个查询中执行此操作。您甚至可以在字段或类型级别合并此数据。这是Facebook和GitHub等公司使用GraphQL的主要原因之一。

而 tRPC 并不是真正用于此目的。它用于构建端到端类型安全的 API，并不是真正用于组合多个数据源。你可以这样做，但这不是 tRPC 的目的。

RPC 非常适合端到端类型安全

tRPC 非常适合端到端类型安全，它允许您在前端应用程序中使用与在后端应用程序中使用的相同类型。GraphQL 没有内置的方式来在前端和后端之间共享类型定义，但您可以使用 GraphQL 模式来生成 TypeScript 类型定义。但这不同于端到端类型的安全。每次更新 GraphQL 模式时，都必须重新生成类型。

使用 tRPC 时，您将使用 TypeScript 构建所有内容。这意味着您可以将类型从服务器直接导入到前端应用程序中。tRPC 客户端可以直接从 tRPC 服务器访问 TypeScript 类型。在前端应用程序中查询 tRPC 时不需要外部库，因为它都是内置的 tRPC 库。

GraphQL 允许解耦服务;单个代码库的 tRPC

GraphQL 非常适合解耦服务，因为它与编程语言和传输层无关。这意味着您可以使用所需的任何编程语言和任何传输层。公开 GraphQL API 的服务可以用任何编程语言实现，例如 TypeScript 和 Go，并且仍然能够相互通信。对于技术多样化的团队和公司来说，这是扩展和限制团队之间依赖关系的好方法。

tRPC 并不是真正用于此目的。它用于在 TypeScript 中的单个代码库中构建端到端的类型安全 API！它将您的前端和后端紧密地结合在一起，例如在 monorepo 中。您可以在前端和后端应用程序中使用相同的类型，这允许您快速迭代应用程序。如果你正在构建一个全栈 TypeScript 项目，有什么不喜欢的？

tRPC 比 GraphQL 更容易使用

“tRPC 比 GraphQL 更容易使用”是人们在比较 GraphQL 和 tRPC 时反复出现的一句话。但是由于 tRPC 是一个库，而 GraphQL 是一种查询语言，因此无法进行比较。对于 GraphQL，开发人员可以使用众多可用实现之一来构建 GraphQL，而 tRPC 是一组开箱即用的库。这使得它不是一个公平的比较，但无论如何让我们分解一下。

例如，您可以使用模式优先的 GraphQL 服务器库构建 GraphQL API。您必须定义 GraphQL 架构，编写解析程序以从数据源收集数据，然后从架构生成类型。走这条路需要做很多工作，并且作为开发人员需要做出许多选择。

但你也可以使用代码优先的 GraphQL 服务器库构建 GraphQL API。这意味着您可以编写解析程序，然后从解析程序生成架构。代码优先库在开发人员体验方面更接近 tRPC，但仍然比使用 GraphQL 即服务（如 StepZen）更具挑战性。

然后，您还可以选择各种 GraphQL 客户端库。您可以使用 GraphQL 客户端库（如 Apollo Client 或 urql）来帮助您进行缓存和状态管理，也可以使用仅处理 HTTP 请求的库。有很多选择，当你不熟悉 GraphQL 时，可能不清楚。

结论

在这篇博文中，我解释了 GraphQL 和 tRPC 之间的区别。我希望这篇博文能帮助您了解两者之间的差异，并且您现在可以更好地决定在下一个项目中使用哪一个。在 GraphQL 和 tRPC 之间进行选择时要问自己的主要问题是：

是否要在单个查询中查询多个数据源并保持服务分离？如果是这样，GraphQL 是一个完美的选择。如果你想要端到端类型的安全，并且不关心前端和后端的解耦，tRPC 更适合。
您是否打算使用多种编程语言？选择GraphQL，因为它与编程语言无关。如果要在整个应用程序中使用 TypeScript，tRPC 可能更适合。
在 GraphQL 和 tRPC 之间进行选择时，还有许多其他事情需要考虑，但在我看来，这些是主要的。