具有动态键的对象的 Apollo/GraphQL 字段类型 [英] Apollo/GraphQL field type for object with dynamic keys

问题描述

假设我的 graphql 服务器想要获取以下数据作为 JSON，其中 person3 和 person5 是一些 id:

Let's say my graphql server wants to fetch the following data as JSON where person3 and person5 are some id's:

"persons": {
  "person3": {
    "id": "person3",
    "name": "Mike"
  },
  "person5": {
    "id": "person5",
    "name": "Lisa"
  }
}

问题:如何使用 apollo 创建模式类型定义?

Question: How to create the schema type definition with apollo?

此处的键 person3 和 person5 是根据我的查询(即查询中使用的 area)动态生成的.所以在另一个时间我可能会返回 person1、person2、person3.如您所见，persons 不是可迭代的，因此以下内容不能作为我使用 apollo 所做的 graphql 类型定义:

The keys person3 and person5 here are dynamically generated depending on my query (i.e. the area used in the query). So at another time I might get person1, person2, person3 returned. As you see persons is not an Iterable, so the following won't work as a graphql type definition I did with apollo:

type Person {
  id: String
  name: String
}
type Query {
  persons(area: String): [Person]
}

persons 对象中的键可能总是不同的.

The keys in the persons object may always be different.

当然，一种解决方案是将传入的 JSON 数据转换为使用 persons 的数组，但是没有办法处理这样的数据吗?

One solution of course would be to transform the incoming JSON data to use an array for persons, but is there no way to work with the data as such?

推荐答案

GraphQL 依赖于服务器和客户端提前知道每种类型可用的字段.在某些情况下，客户端可以发现这些字段(通过自省)，但对于服务器，它们总是需要提前知道.因此，基于返回的数据以某种方式动态生成这些字段是不可能的.

GraphQL relies on both the server and the client knowing ahead of time what fields are available available for each type. In some cases, the client can discover those fields (via introspection), but for the server, they always need to be known ahead of time. So to somehow dynamically generate those fields based on the returned data is not really possible.

您可以使用自定义的JSON 标量(graphql-type-json 模块)并为您的查询返回:

You could utilize a custom JSON scalar (graphql-type-json module) and return that for your query:

type Query {
  persons(area: String): JSON
}

通过使用 JSON，您可以绕过返回数据以适应任何特定结构的要求，因此您可以发送任何您想要的任何内容，只要它是正确格式化的 JSON.

By utilizing JSON, you bypass the requirement for the returned data to fit any specific structure, so you can send back whatever you want as long it's properly formatted JSON.

当然，这样做有明显的缺点.例如，您失去了之前使用的类型提供的安全网(实际上可以返回任何结构，如果您返回错误的结构，您将不会发现它，直到客户端尝试使用它并失败).您也无法对返回的数据中的任何字段使用解析器.

Of course, there's significant disadvantages in doing this. For example, you lose the safety net provided by the type(s) you would have previously used (literally any structure could be returned, and if you're returning the wrong one, you won't find out about it until the client tries to use it and fails). You also lose the ability to use resolvers for any fields within the returned data.

但是...你的葬礼:)

But... your funeral :)

顺便说一句，在将数据发送回客户端之前，我会考虑将数据展平到一个数组中(就像您在问题中建议的那样).如果您正在编写客户端代码，并使用动态大小的客户列表，那么使用数组比使用 id 键的对象更容易使用.例如，如果您使用 React 并为每个客户显示一个组件，您最终会将该对象转换为数组以映射它.在设计您的 API 时，与避免对您的数据进行额外处理相比，我会将客户端可用性作为更高的考虑因素.

As an aside, I would consider flattening out the data into an array (like you suggested in your question) before sending it back to the client. If you're writing the client code, and working with a dynamically-sized list of customers, chances are an array will be much easier to work with rather than an object keyed by id. If you're using React, for example, and displaying a component for each customer, you'll end up converting that object to an array to map it anyway. In designing your API, I would make client usability a higher consideration than avoiding additional processing of your data.

这篇关于具有动态键的对象的 Apollo/GraphQL 字段类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！