界面与GraphQL模式设计中的联合

Question

假设我正在建立一个为自然灾害事件的时间表的GraphQL API。

目前有两种不同的事件：

• 飓风
• 地震

所有事件都有ID和日期。我计划使用光标进行分页查询以获取事件。

我可以想到两种不同的方法来建模我的域。

1。接口

interface Event {
  id: ID!
  occurred: String! # ISO timestamp
}

type Earthquake implements Event {
  epicenter: String!
  magnitude: Int!
}

type Hurricane implements Event {
  force: Int!
}

2。联盟

type Earthquake {
  epicenter: String!
  magnitude: Int!
}

type Hurricane {
  force: Int!
}

type EventPayload = 
  | Earthquake
  | Hurricane

type Event {
  id: ID!
  occurred: String! # ISO timestamp
  payload: EventPayload!
}

两种方法之间的权衡是什么？

Answer 1

我相信：

• 工会要提供< / strong>：一个字段 /其分辨率函数与一个对象解析，其类型属于特定的，已知的类型类型。
• 接口是关于请求：如果没有，客户将不得不重复他们感兴趣的字段，每种类型的片段。

它们具有不同的目的，可以一起使用：

interface I {
    id: ID!
}

type A implements I {
    id: ID!
    a: Int!
}

type B implements I {
    id: ID!
    b: Int!
}

type C implements I {
    id: ID!
    c: Int!
}

union Foo = A | C

type Query {
    foo: Foo!
}

此架构声明a，b和c有一些共同的字段，因此客户端更容易请求它们，并且查询foo只能产生a或c。

您可以编写foo：i！吗？尽管这将无缝起作用，但我相信这会带来不良的发展经历。如果您说的是foo提供i对象，则您的客户应为接收任何实施类型做好准备，包括b和将花时间编写和维护永远不会被调用的代码。如果您知道foo只能产生a和c，请明确告诉他们。

如果foo是要产生a，b或c，则相同。碰巧是实现i的类型列表，因此在这种情况下，您可以编写foo：i！吗？不！不要被那个愚弄。为什么？因为此列表是可以通过联邦 /模式缝制的扩展< / strong>！我相信这是某些GraphQl框架的很少使用的功能，但其采用量的增长。如果您从未使用过它，请尝试，它将为您的新想法带来微观服务间交流和其他中等流行语的新想法。简而言之，想象一下您在组织内部进行公共API，甚至在组织内部进行某种公共活动。其他人可以通过提供额外的东西来“增强”您的API。这可能包括实现界面的新类型。因此，我们回到了上一段。

到目前为止，看来我赞成您的第一个代码。

但是，这可能是针对这种情况的，在我看来，您对事件的定义既将有关其发生的数据和物理指标的数据混合在一起。您的第二个代码将它们分为两个类型的层次结构。我喜欢那个。感觉更友好。您的模式更加开放。想象一下，您的API是关于事件历史记录的，并且有人通过预测来增强它：您的eventpayload可以重复使用！

此外，请注意您的第一个示例不完整。实现接口必须 emparte 的类型，即重复，该接口的每个字段，就像我在上面的代码中所写一样。随着场的数量和实施类型的增加，这变得更加难以维持。

因此，第二个解决方案也具有一些优势。但是这样做，我早些时候对返回类型进行特定的blah-blah很难实现，因为有效载荷（要具体的）嵌入了另一种类型中，并且GraphQl中没有仿制药。

这是一个调和所有这些的建议：

interface HasForce {
    force: Int!
}

type Earthquake {
    epicenter: String!
    magnitude: Int!
}

type Hurricane implements HasForce {
    force: Int!
}

type Tsunami implements HasForce {
    force: Int!
}

interface Event {
    data: EventData!
}

type EventData {
    id: ID!
    occurred: String!
}

union HistoryMeteorologicalPhenomenon = Earthquake | Hurricane

type HistoryEvent implements Event {
    data: EventData!
    meteorologicalPhenomenon: HistoryMeteorologicalPhenomenon!
}

type Query {
    historyEvents: [HistoryEvent!]!
}

看起来这两个建议看起来更复杂，但它可以满足我的需求。另外，很少看这个高度的架构：更多的是，我们经常知道入口点并从那里挖掘。例如，我在historyEvents上打开文档，请参阅它产生两种现象，很好，我不知道存在其他联合类型和事件类型。

如果您要编写很多这些 union + event 对，则可以用代码生成它们，从而使一个函数调用会声明一对。较少的错误，实施更有趣，并且具有更多的中等文章潜力。

请注意，GraphQL结构独立于您的存储结构。可以让多个GraphQl对象从相同的 insert-your语言中提供数据，例如，您的DB驱动程序产生的对象。我可能没有一个小的开销，但我没有标准，但是提供更干净的API对我来说胜过这一点。基本想法是，解析器函数只需要从相同的源解决，因此与同一源对象相关的解析器函数将被调用。