GraphQL でエラー処理はどのように機能するのか?

Question

IT Interview Practice · Accepted Answer

GraphQL は、トランスポートが成功すれば常に HTTP **200** を返します。問題はステータスコードではなくレスポンス本文で報告されます。レスポンスには 2 つのトップレベルキー **`data`** と **`errors`** があり、両方が同時に存在することもあります。それが **部分データ** です。

## 部分データ + errors 配列

あるフィールドのリゾルバがスローすると、そのフィールドは `null` になり、`errors` にエントリが追加されますが、他のすべてのフィールドは引き続き解決されます。クライアントは成功した分に加えて、失敗した内容の説明を受け取ります。

```json
{
  "data": { "user": { "name": "Ada", "posts": null } },
  "errors": [
    {
      "message": "Failed to load posts",
      "path": ["user", "posts"],        // exactly which field failed
      "extensions": { "code": "DOWNSTREAM_TIMEOUT" }
    }
  ]
}
```

**`extensions.code`** フィールドは機械可読なエラーコードを運ぶため、クライアントはそれに応じて分岐できます。スローされたフィールドが自分自身だけを null にするか、上位へ波及するかは **null 許容性** によります。エラーになった非 null フィールド (`posts: [Post!]!`) は、代わりに最も近い null 許容の親を null にします。

```js
import { GraphQLError } from "graphql";

多くのチームは、**想定内** のエラー (検証、"email taken") を union/result 型を介してスキーマの一部としてモデル化し、`errors` 配列は **想定外** の障害のために予約しておきます — こうしてハッピーパスの型付けをきれいに保ちます。

## なぜ重要なのか

面接官は、エラーが部分的な `data` とともに本文に存在すること、コードが `extensions` に属すること、そして null 許容性がエラーの波及範囲を制御することを知っているか探ります。GraphQL のエラーを HTTP ステータスコードと混同するのは、REST しか使ったことがない人の典型的な兆候です。

部分データ + errors 配列

なぜ重要なのか

関連する質問