問題タブ [graphql-tools]

スキーマ スティッチングに依存する既存の GraphQL コードを移行して、代わりにフェデレーションを使用しようとしています。

拡張機能/型定義の重複に関連するエラーを適切に処理する方法を理解するのに苦労しています。

このリポジトリの例に従おうとしています: https://github.com/apollographql/federation-migration-example。

before-migrationフォルダー内で、プロジェクトは次のようにスキーマを定義します。

この例は、現在の構成に似ています。

after-migrationフォルダにはこれがあります：

あるパターンから別のパターンに正常に (ダウンタイムなしで) 移行する方法はありますか? このような例に従おうとすると、スティッチ サービスから、まだスティッチ サービスから"Field "Reservation.user" already exists in the schema. It cannot also be defined in this type extension."イニシャルを削除していないので、これは理にかなっているというエラーが表示されました。extend type Reservation

問題は、この例に基づいて、あるパターンから別のパターンに移行するときにダウンタイムが発生するはずだと私が信じていることです。最初のステッチ タイプ拡張が最初に削除されると、既存のクライアントが を照会しようとしたときにエラーが発生しますReservation.user。フェデレーション スタイルの拡張機能を追加する前に最初の拡張機能を削除しないと、競合エラーがスローされます。

ドキュメントhttps://www.apollographql.com/docs/federation/migrating-from-stitching/は、ステッチングからフェデレーションに移行するために従うことができる特定の手順があることを示しています。

1. サブグラフにフェデレーション サポートを追加する
2. GraphQL スキーマをレジストリに登録する
3. Apollo Server のインスタンスをゲートウェイとして起動する
4. スキーマ スティッチング ゲートウェイからサブグラフにスティッチング ロジックを移行する
5. スキーマ ステッチ ゲートウェイから Apollo Server ゲートウェイにトラフィックを移動する
6. フェデレーテッド スキーマからスキーマ ステッチ フィールドを削除し、移行を完了します

ただし、これらの手順を適切に実行する方法がわかりません。ステップ 4.「スキーマ スティッチング ゲートウェイからサブグラフへのスティッチング ロジックの移行」では、上記で述べた種類の競合が必然的に発生するようです。ただし、ドキュメントの記述方法は、両方のアプローチが同時に共存できることを暗示しているようです (ドキュメントでは、スティッチング サーバーとフェデレーション サーバーの両方を同じプロセスでホストできることさえ提案しています)。

transformSchemaまたはonTypeConflict https://www.apollographql.com/docs/apollo-server/api/graphql-tools/#transformschemaの使用を検討しましたが、これらが自分の状況にどのように適用されるかを理解するのに苦労しています。ドキュメントによると

の既定の動作はmergeSchemas、同じ名前を持つすべての型の中で最初に検出された型を取ることです。

これは「ルートフィールド」ではなく型を指しているため、必要なものとは異なると思います。フィールドがまだ存在しない場合にのみFilterRootFields、ステッチタイプの拡張を条件付きで適用するために使用できるかどうか疑問に思っています。これがどのように機能するか正確にはわかりませんが、スキーマ データ自体に基づいてルート フィールドを条件付きでフィルタリングする例を見つけることができません。

この問題にアプローチする標準的な方法はありますか?

私は両方の概念に慣れていないので、意見に基づいている場合はすみません。現在、Apollo Federation と、graphql-tools パッケージによって提供されるスキーマ スティッチングを調べていますが、同様のパッケージにも当てはまると思います。どちらかを優先するための特定の要件/条件を説明する表のようなものを作成できますか?