GraphQL是否可以避免数据传输对象？

Question

据我所知,数据传输对象(DTO)通常是小型,扁平,无行为,可序列化的对象,其主要优点是易于跨网络传输.

GraphQL有以下几个方面:

• 鼓励提供丰富的对象图,这些图(无论如何)与DTO的"扁平"部分相矛盾,
• 让客户准确选择他们想要的数据,这些数据可以解决"小"部分,
• 返回JSON-esque对象,它们解决了"无行为"和"可序列化"部分

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

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

Answer 1

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

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

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

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

在此用例中，您将使用任何 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

这是一个用例，当您将架构从一种转移到另一种并且您不想破坏客户消费者的事情时，因此您保留两个选项并最终停用其中一个。

希望这可以帮助！