<前回(1)はこちら。>
発展的な型の実装
前節までは仕様で定義されたスカラ型のID
型などを使ってきましたが、アプリケーション側で定義が必要なインタフェースを使えるようにすることで、スキーマ上でアプリケーションの特性を表現しやすくなります。
インタフェースの定義
GraphQLで一般的なNode
インタフェースを実装します。Node
インタフェースはid: ID!
フィールドを持つインタフェースで、オブジェクトを一意なIDによって取得することが容易になります。Book
型とAuthor
型でNode
インタフェースを実装しましょう。
加えて、id
の値からNode
インタフェースをユニークに取得できるQuery.node(id: "ID")
フィールドを追加しています。
インタフェースの解決
スキーマ定義だけではインタフェースは解決できません。定義したインタフェースの具体的な型が、どれに対応するかを示す型解決の実装が必要になります。今回で言うと、先ほど定義したNode
インタフェースからBook
型やAuthor
型に落とし込むための実装が必要です。
インタフェース解決を委譲するモジュールを指定する
アプリケーションの名前空間にあるインタフェース別のモジュールを参照し、解決するモジュールを作ります。
作成したモジュールをGraphQL::Schema
でのスキーマ生成時に指定します。
Nodeインタフェースの型解決を実装する
委譲の実装を行ったうえで、今回のNode
インタフェースの型解決を実装します。Node
の具象型がid
の値に含まれるとすると、id
の値から型情報を抜き出して実際の型を返してあげる実装を行うことで、ライブラリ側でインタフェースから具体的な型を解決できます。
インタフェース解決の確認
こうして型の解決ができるようになったので、Query.node
フィールドのリゾルバを実装してみます。
Query.node
フィールドに対するクエリ結果から、実際の型に基づいていることが確認できます。
キャッシュによるパフォーマンス改善
GraphQLはキャッシュが難しい印象を多くの人が持っているかもしれません。実際、REST APIなどのエンドポイントベースのAPIとは違った戦略が必要になります。
クエリに対するレスポンスのキャッシュ
graphql-perlではキャッシュのしくみを手作りする必要があります。クエリ全体に対するレスポンスをキャッシュする方法と、フラグメント単位や型単位でキャッシュする方法が考えられますが、今回は単純な前者のキャッシュ実装を紹介します。
クエリのハッシュをもとにレスポンスを保存する
一番簡単なのは、クエリのハッシュをもとにレスポンスを保存しておく方法です。今回はキャッシュのバックエンドとしてよく使われるインメモリデータベースであるRedisを使用します。
クエリキャッシュを実装に組み込んで高速化する
クエリ実行時にキャッシュの確認と保存を行い、キャッシュが有効な場合はクエリの結果を高速に返せるようにします。
なお、実用的なキャッシュのためには、適切な生存期間の設定、キャッシュしてはいけないプライベートなレスポンスの除外のしくみが必要です。たとえば、データの操作が発生するMutation
はキャッシュしたくないですよね。紙面では解説を省きますので、詳しくはサンプルコードをご覧ください。
既知のクエリを事前にキャッシュするテクニック
本項では、クエリのキャッシュを利用した実用的なテクニックを紹介します。
アプリケーションの特性的にクエリが固定で予期できるサービスでは、定期的にキャッシュを作成するユースケースは珍しくありません。前項で作ったクエリのキャッシュを使い、定期的なキャッシュ作成のバッチ処理を行うと、ユーザーに常にキャッシュされたレスポンスを返すことができます。
リクエストを保存する
事前キャッシュの対象となるリクエストの保存の実装を考えます。Redisのソート済みセット型であるZSET
型を使い、リクエストの多いものからソートしつつユニークにもします。
この解説では考慮しませんが、実用的には、キャッシュ可否の判定やユーザー体験とデータの更新性を損なわない程度の生存期間を設定する必要があります。
保存されたリクエストのキャッシュを作成する
作成したリクエストログから、リクエスト数の多い順にキャッシュを作成します。
my $requests = App::GraphQL::Repository::Request
->get_all();
for my $request ($requests->@*) {
App::GraphQL->execute_with_cache($request);
}
ここではループで直列に処理していますが、実運用ではワーカーで処理を分散して実行すると処理時間面で有効です。
Persisted Query ── ハッシュでリクエストし効率と安全性を高める
クエリとハッシュの対応をストアに持つようにすれば、ハッシュとoperationName
、variables
パラメータだけを指定することで、クエリ本文を与えずとも実行できます。このアイデアはPersisted Queryと呼ばれています。
Persisted Queryでは、クエリはSHA256のハッシュとして指定されます。ハッシュをクエリ本文の代わりに受け取り実行する実装をしてみましょう。
こうすれば、該当するハッシュ値のPersisted Queryが保存されている場合は、ハッシュ値でクエリを指定できます。/graphql?extensions={"persistedQuery":{ "sha256Hash": "<ハッシュ値>" }}&variables=...&operation_name=...
の形式でのGETリクエストが現実的になり、リクエストのペイロードが大幅に削減されます。
メリットとしてはほかにも、Varnishなどのミドルウェアが活用できることや、保存されたクエリしか実行できないようにすればセキュリティが高まることなどが挙げられます。
まとめ
今回は、Perlで実践的なGraphQL APIを作成しました。みなさんも、PerlでGraphQLを採用してください。
さて、次回の執筆者は藤浪大弥さんで、テーマは「正規表現の脆弱性『ReDoS』徹底解説」です。お楽しみに。