apollo-clientのerror policy毎の挙動の違いをまとめてみる

初めに

絶賛ダイエット中の技術開発部の村上(@pipopotamasu)です。

一時期コロナ太りで60kg近くまで増えた体重を52kg台に落とすことに成功しました🚀

普段会社ではideagramや新規プロダクトのフロントエンド部分を開発しています。

私が所属する開発チーム内ではGraphQLを採用しており、フロントエンドではそのクライアントライブラリとしてapollo-clientを利用しております。

今までエラーハンドリングを雰囲気でやってきた戒めをこめて、今日はapollo-clientのerror policyについて書こうと思います。

apollo-clientのエラーについて

error policyを説明する前に、apollo-clientの2種類のエラータイプを紹介します。それはGraphQL errorsとnetwork errorsです。

GraphQL errors

名前の通りGraphQLに関連するエラーです。

例えば…

queryやmutationのシンタックスエラー
Schemaの型定義と違っていたときのバリデーションエラー
リゾルバ内部で発生したエラー

などなどです。このようなエラーが起きた場合、以下のようなレスポンスbodyで返ってきます。

{
  "data": null,
  "errors": [
    {
      "message": "err msg",
      "locations": [{ "line": 2, "column": 3 }],
      "path": ["someMutation"],
      "extensions": {}
    }
  ]
}

慣習的にこれらのエラーは、200のHTTPステータスコードで返すようGraphQL serverライブラリで実装されていることが多いです。

そしてGraphQL errorsにはpartial data(もしくはpartial response)という概念があります。

上記のGraphQLのレスポンス例では、dataプロパティはnullになっていますが、GraphQLエラーが発生したからといって必ずしもnullになるわけではありません。GraphQLエラーは起こっているけど、何かしら返却されているdataをpartial dataといいます。

GraphQLの仕様に説明や例があるのでよろしければご覧ください。

http://spec.graphql.org/June2018/#sec-Errors

network errors

400系や500系のHTTPステータスコードが返ってくるようなエラーです。

例えば…

サーバーからの応答がない
リクエストしているエンドポイントが存在しない

これらの例から分かる通り、このnetwork errorsはGraphQL特有のエラーではありません。

apollo-clientのerror policyの挙動を理解する上で、この2種類のエラーがあるということを念頭に入れる必要があります。

apollo-clientのerror policyについて

さて、apollo-clientのerror policyとは一体なんなのでしょうか？

ざっくり言うと、「エラー発生時のレスポンスに含まれる、errorsフィールドとdataフィールドの値をどう扱うか」を決めるものになります。

例えば以下のようにapollo-clientが提供するhooksメソッドの返り値にはdata, errorオブジェクトが含まれます。

const { data, error } = useQuery(gqlQuery);
const [fn, { data, error }] = useLazyQuery(gqlQuery);
const [fn, { data, error }] = useMutation(gqlQuery);

error policyはエラー発生時のAPIコールのレスポンスをどのようにdata, errorオブジェクトに伝達するかを決めるわけです。

error policyにはnone, ignore, allの3種類あり、それぞれエラー発生時の挙動に違いがあります。