跨多个API /版本的同名GraphQL类型的最佳命名约定？

Question

我正在设置一个GraphQL模式，该模式可以与多个不同的Source API以及这些API的多个不同版本（即/ v1 /和/ v2 /）进行通信。我在为类型制定好的命名策略时遇到了一些麻烦，因此任何建议都将不胜感激。

例如，假设我们有一个称为“ ShowAPI”的REST API和另一个名为“ MovieAPI”的REST API。 “ MovieAPI”同时具有/ v1 /和/ v2 /端点，它们也需要支持。

两个API都具有视频文档类型，但是具有完全不同的数据和结构集（但也有一些共同点）。所以我的本能是在模式中定义两个不同的类型

type Video {} #ShowAPI video
type MovieVideo{} #MovieAPI video

这将允许我在Source API之后映射每个模型。当然，我还需要支持MovieAPI的/ v1 /和/ v2 /，所以我更新了一些命名

type Video {} #ShowAPI video
type MovieVideoV1{} #MovieAPI video v1
type MovieVideoV2{} #MovieAPI video v2

然后我想到，有一天我可能不得不添加第三个API，其中也可能包含视频文档。而且ShowAPI有一天也可能会获得第二个版本，因为它拥有自己完全独特的字段集，所以我再次对其进行了更新。

type ShowVideoV1 {} #ShowAPI video v1
type MovieVideoV1{} #MovieAPI video v1
type MovieVideoV2{} #MovieAPI video v2

此时，它变得非常冗长，混乱，并且难以维护。

你们将如何处理？我是否应该尝试将MovieVideoV1和MovieVideoV2中的不同字段组合在一起，并使用单一类型 MovieVideo 和另一种类型 ShowVideo ？我是否应该同时混入ShowAPI和两个版本的MovieAPI的字段并制作一个视频类型？

我认为理想的情况是，如果我使用一种类型，但是只使用片段来分隔Source API，然后对全部使用Video。例如。如果查询看起来像这样：

query {
  Video (videoID:123, sourceAPI:"MovieAPIV2") {
    videoID,
    sourceAPI, #sourceAPI set by resolver
    ... on MovieAPIV1 {
      ID
      UniqueField1
    }    
    ... on MovieAPIV2 {
      ID
      UniqueField2
    }
    ... on ShowAPI {
      ID
      UniqueField3
    }
  }
}

这种方式的问题是，当我希望允许他们只是探索API并构造适合他们的任何查询时，我将迫使API使用者以这种方式构造他们的查询。