コンセプト、アイデア、戦略
コンセプト、アイデア、戦略フィールドとディレクティブのバージョニングのユースケース

フィールドとディレクティブのバージョニングのユースケース

まず、Gato GraphQLの「フィールドバージョニング」機能を説明したガイド フィールドバージョニングによるスキーマの進化 をお読みください

Gato GraphQLでは、フィールドおよびディレクティブが引数 versionConstraint を受け取ることができます。これにより、フィールドやディレクティブの特定のバージョン(つまり実装)を選択できます。

query GetPosts {
  posts(versionConstraint: "^1.0") {
    id
    title(versionConstraint: ">=2.1")
    excerpt @strUpperCase(versionConstraint: "~1.5.3")
  }
}

フィールド(またはディレクティブ)には、バージョンなしのデフォルト実装を持たせることもできます。これは、クエリで versionConstraint が指定されていない場合に使用されるものです。

イントロスペクションを実行する際は、デフォルトのフィールドおよびディレクティブのデータのみが取得されます。その結果、デフォルトのフィールドやディレクティブは versionConstraint 引数をサポートしていないため、イントロスペクション時にこの引数が表示されることはありません。

このため、フィールドまたはディレクティブに選択可能な2つ以上のバージョンが存在することを常に事前に把握しておく必要があり、それらのバージョン番号も知っておかなければなりません。この情報はデフォルトでは公開されていません。

では、バージョニングはどのような場面で役に立つのでしょうか?ここではいくつかのユースケースをご紹介します。

特定のユーザーに対するバグの迅速な修正を提供する

あなたのウェブサイトにGraphQL APIがデプロイされており、特定のユーザーからフィールドが期待どおりに動作していないというクレームが届いたとします。しかし、この問題はそのユーザーにのみ発生しており、他の誰も問題を経験していないようです。

問題を特定して修正したものの、全員に変更をデプロイする前に正常に動作することを確認したい場合、バージョン "1.0.1" の新しいフィールドリゾルバーとして変更をデプロイし、問題のあるユーザーにGraphQLクエリを変更してこのバージョンのフィールドを指定するよう依頼することができます。

{
  someBuggyField(versionConstraint: "1.0.1")
}

バグが実際に修正されたことを確認してから、はじめてコードをデフォルトのフィールドリゾルバーにコピーします。

選択したユーザーにリリース候補のテストを依頼する

フィールドまたはディレクティブがバージョニングされており、デフォルト(つまり非バージョン)の実装がない場合、イントロスペクション時にまったく表示されなくなります。

{
  someField
    # This directive has no default implementation,
    # so it won't appear during introspection,
    # but it can still be added in the GraphQL query
    # when providing a constraint that satisfies it
    @someExperimentalDirective(versionConstraint: ">1.0")
}

フィールドまたはディレクティブをデプロイしても GraphQL API では表示されない状態にしておき、選択したユーザーにテストを依頼することができます。その際、ユーザーはクエリ内で対応する versionConstraint 引数を指定して使用する必要があります。

受け入れられた後は、バージョニングが削除され、フィールドまたはディレクティブはイントロスペクションで表示されるようになり、すべてのユーザーが利用できるようになります。