GraphQLにおけるinput objectの命名について

Question

GithubのAPI v4を参考にしつつGraphQLのスキーマ設計をしようとしていまして、1点質問させていただきます。

Githubではinput objectは{mutationName}Inputと命名する規則が存在するようです。

この命名規則について、以下の理解をしています。

• pros: input objectとmutationの関係が明瞭になる
• cons: 再利用性が低くなる

この理解のうえで、「prosが小さく、consが大きいのでは」と感じています。

「そのpros/consの認識は誤っている」、「他にこんなpros/consがある」などあればお教えいただきたいです。

よろしくお願いします????

補足: 「再利用性が低くなる」というデメリットについて

例えばこのリンクの例においては、Githubの命名規則には従わずに、
createMessage, updateMessageというmutationの引数に共通してMessageInputというtypeを利用することにより、再利用性を獲得しています。

しかしGithubの命名規則に従った場合、以下のようになるかと思います。

type Mutation {
  createMessage(input: CreateMessageInput): Message
  updateMessage(input: UpdateMessageInput): Message
}

input CreateMessageInput {
  content: String
  author: String
}

input UpdateMessageInput {
  id: ID!
  content: String
  author: String  
}

これではinput objectが個別に作成され再利用されていないため、たとえばMessageというリソースに対して属性が追加されたときに、２つのinput objectそれぞれに修正を加えなくてはならないと思います。

ちなみに共通化するため以下のように書ければよいのですが、input objectではこの記法はサポートされていないと思っています。

interface MessageInput {
  content: String
  author: String
}

input CreateMessageInput implements MessageInput {  # 無効な記法
}

input UpdateMessageInput implements MessageInput {  # 無効な記法
  id: ID!
}

Answer 1

自己解決しました。

結論「"cons: 再利用性が低くなる"について、そもそも再利用性が期待されるべきではない。よってconsは存在せず、prosのみが存在するので、"Github的命名規則"を採用するのが是である」

createMessageとupdateMessageはそもそも異なる操作であり、それぞれのinputのフィールドは本質的に=常に共通するわけではない。
（例えば「updateではauthorは変更できず、contentのみを引数にとる」ということは十分にあり得る。）

そのためCreateMessageInputとUpdateMessageInputは（共通の定義を再利用するのではなく）別々に、独立に定義されるべきである。