GraphQL 是否消除了数据传输对象？

Question

据我了解，Data Transfer Objects (DTO) 通常是小型、扁平、无行为、可序列化的对象，其主要优点是易于跨网络传输。

GraphQL 有以下几个方面：

• 鼓励服务rich object graphs，这（无论如何在我的脑海中）与 DTO 的“扁平化”部分相矛盾，
• 让客户choose exactly the data they want，解决“小”部分，
• 返回JSON-esque objects，用于处理“无行为”和“可序列化”部分

GraphQL 和 DTO 模式是否相互排斥？

这就是导致这个问题的原因：我们设想了一个带有网关的微服务架构。我正在设计一个 API 以适应该架构，该架构将服务（除其他外）geometries。在许多（可能是大多数）情况下，几何图形对客户端应用程序没有用处，但它们在其他应用程序中至关重要，因此必须提供服务。然而，它们是序列化的，几何图形可能很大，因此让客户可以选择拒绝它们可以节省大量带宽。我见过的处理几何图形的 RESTful API 通过在查询字符串中提供 "returnGeometry" parameter 来做到这一点。我从未对这种方法感到完全满意，我最初设想为一组相当深的相关/嵌套返回对象提供服务，其中许多客户会选择拒绝。所有这些都让我考虑使用 GraphQL 接口。随着设计的进展，我开始考虑扁平化输出（完全或部分），这导致我考虑 DTO 模式。所以现在我想知道是否最好将所有内容扁平化为 DTO 并跳过 GraphQL（我想是支持 REST 吗？）。我考虑过使用 GraphQL 服务的 DTO 的中间立场，让客户选择他们想要的属性，但我想知道这是否不恰当地混合了模式和技术。

Answer 1

我认为区分 GraphQL 的 2 个典型用例和结合前两个的隐藏的第 3 个用例是值得的。

然而，在所有这 3 个中，GraphType 的本质是选择性地决定要从域实体中公开哪些字段。听起来很熟悉？它应该，这就是 DTO。 GraphQL 与否，例如，您不想在用户表上公开“密码”字段，因此您需要以一种或另一种方式向客户隐藏它。

这是因为 GraphQL 不对您的持久层做出任何假设，并为您提供了根据您认为合适的方式处理输入类型/查询的工具。

1. GraphQL 端点直接暴露给客户端（例如网络、移动）：

在这个用例中，您可以使用任何 GraphQL 客户端直接与您的 graphql 端点通信。这里的 DTO 是实际的 GraphType 对象，其结构取决于您添加到公开的 GraphType 中的字段。

在内部，您将使用字段解析器将您的 DTO 转换为您的域实体，然后使用您的存储库来持久化它。

DTO 转换发生在内部GraphType 的字段解析器。

GraphQL --> DTO --> Domain Entity --> Data Store

2. 向客户端公开的 REST 端点，它在内部使用 GraphQL 端点：

在此用例中，您的 Web 和移动客户端通过 REST 使用传统 DTO。然而，控制器连接到一个内部公开的 GraphQL 端点 - 与用例 #1 不同 - 其 GraphTypes 是您的域实体的精确映射，包括密码字段！

DTO 转换发生在控制器调用端点之前。

DTO --> Domain Entity --> GraphQL --> Data Store

3.结合1和2

这是一个用例，当您将架构从一个转移到另一个时，您又不想破坏客户消费者的东西，因此您将两个选项都保持打开状态并最终停用其中一个。

希望这会有所帮助！