GraphQL

アプリケーションのデータモデルを表したグラフ構造から、特定のノードから始まる木構造を取り出し、リソースの読み込みを解決する

メリット

クライアントが自分都合で必要なデータのみを取得できるため、オーバーフェッチやアンダーフェッチを防げる

デメリット

N+1が起きる可能性がある

木構造をたどりながらその都度リソースの読み込みを解決していくため

対策

DataLoader

ヘビーなQueryを実行できてしまうことで、サーバーへの負荷が高まる可能性がある

循環参照するようなリソースの場合は、際限なくQueryを深くできてしまう

サーバーサイドで処理する際に、処理が重いフィールドを大量に混ぜ込んだQueryを実行できてしまう

対策

Query complexityの計測と制限

Queryの複雑さをコストとして表現する

フィールドごとにコストをカスタマイズすることで、重いフィールドを大量に混ぜ込んだり、ネストを一定の深さに抑えたりできる

リクエストボディが肥大化する可能性がある

先述したQuery complexityでの対策とかをしない限り、Queryが複雑になり、リクエストボディがその分高くなる

対策

Query complexityでの制限をかける

POSTリクエストなのでCDNキャッシュが効かない

CDNはGETをキャッシュする

GrapghQLサーバー側をGETリクエストで受けつけるようにすれば、キャッシュ効くが、URLのサイズ制限に引っかかる可能性がある

対策

Persisted Queriesの利用

GETでハッシュIDをリクエストパラメータに入れてリクエストする

GrapghQLサーバー処理の前段で、ハッシュ値から正しいリクエストボディに変換するようなリバースプロキシ的な処理を入れる　リバースプロキシ的なのはGETで受けつけるようにする