通常、GraphQL クライアントはこれについて考える必要はありません。サーバー側で処理する必要があります。
サーバー側でこれに対処するために使用できる手法がいくつかあります。
スキーマ スティッチング
スキーマ スティッチングは、問題に対する簡単なアプローチです。古いスキーマを使用して、PostGraphile スキーマとマージします。そうすれば、クライアントが通信するとき/graphql
に、両方のスキーマにアクセスできます。その後、古いスキーマのすべてを非推奨としてマークし、徐々に使用を段階的に廃止できます。ただし、可能であれば、代わりに PostGraphile プラグインを使用することをお勧めします...
PostGraphile プラグイン
PostGraphile はプラグイン システムを中心に構築されており、 のようなものを使用してmakeExtendSchemaPlugin
、古い GraphQL スキーマを PostGraphile スキーマに混在させることができます。これはここに文書化されています: https://www.graphile.org/postgraphile/make-extend-schema-plugin/ただし、古いタイプ/リゾルバーが次のような方法で実装されている場合graphql-tools
は、おそらく開始する最も簡単な方法です:
const { makeExtendSchemaPlugin, gql } = require('graphile-utils');
const typeDefs = gql`\
type OldType1 {
field1: Int!
field2: String
}
extend type Query {
oldField1: OldType1
oldField2: OldType2
}
`;
const resolvers = {
Query: {
oldField1(/*...*/) {
/* old logic here */
},
//...
},
};
const AddOldSchemaPlugin = makeExtendSchemaPlugin(
build => ({
typeDefs,
resolvers,
})
);
module.exports = AddOldSchemaPlugin;
これにより、レイテンシが追加されないため、最高のパフォーマンスが得られます。また、レガシー フィールド/ミューテーションを非推奨としてマークすることもできます。
スキーマ委任
このアプローチを使用して、独自の新しい GraphQL スキーマを作成し、それを他の GraphQL スキーマ (従来のスキーマと PostGraphile によって生成されたスキーマ) に「委任」します。これによりレイテンシが少し増えますが、GraphQL スキーマの最終的な形をより詳細に制御できますが、この力には大きな責任が伴います。タイプミスをすると、そのタイプミスを長期間維持する必要があります。個人的には、PostGraphile で使用される生成されたスキーマのアプローチを好みます。
ただし、質問に答えるために、Apollo Link には「コンテキスト」機能があり、クエリの実行方法を変更できます。通常、これはヘッダーを追加するために使用されますが、URI をオーバーライドしてクエリの送信先を決定するために使用することもできます。私はこれを自分で行ったことはありませんが、クライアント ディレクティブやフィールド名に基づいて自動的に切り替えることができる Apollo Link があったとしても驚かないでしょう。
https://github.com/apollographql/apollo-link/tree/master/packages/apollo-link-http#context