翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

GraphQL の追加プロパティ

GraphQL は、規模を問わずシンプルさと堅牢性を維持するためのいくつかの設計原則で構成されています。

宣言型

GraphQL は宣言型です。つまり、ユーザーはクエリしたいフィールドを宣言するだけでデータを記述 (整形) できます。レスポンスはこれらのプロパティのデータのみを返します。例えば、ISBN 13 id の値が 9780199536061 の DynamoDB テーブル内の Book オブジェクトを取得するオペレーションを次に示します。

{
  getBook(id: "9780199536061") {
    name
    year
    author
  }
}

このレスポンスでは、ペイロード内のフィールド (name、year、author) が返され、それ以外は何も返されません。

{
  "data": {
    "getBook": {
      "name": "Anna Karenina",
      "year": "1878",
      "author": "Leo Tolstoy",
    }
  }
}

この設計原則により、GraphQL は、複雑なシステムで REST API が処理するオーバーフェッチとアンダーフェッチという根強い問題を排除します。その結果、データ収集がより効率的になり、ネットワークパフォーマンスが向上します。

階層的

GraphQL は、要求されたデータをアプリケーションのニーズに合わせてユーザーが形作ることができるという点で柔軟です。リクエストされたデータは、常に GraphQL API で定義されたプロパティのタイプと構文に従います。例えば、次のスニペットは、Book 9780199536061 にリンクされているすべての保存済み引用文字列とページを返す quotes という新しいフィールドスコープを使った getBook オペレーションを示しています。

{
  getBook(id: "9780199536061") {
    name
    year
    author
    quotes {
      description
      page
    }
  }
}

このクエリを実行すると次の結果を返します。

{
  "data": {
    "getBook": {
      "name": "Anna Karenina",
      "year": "1878",
      "author": "Leo Tolstoy",
      "quotes": [
         {
            "description": "The highest Petersburg society is essentially one: in it everyone knows everyone else, everyone even visits everyone else.",
            "page": 135
         },
         { 
            "description": "Happy families are all alike; every unhappy family is unhappy in its own way.",
            "page": 1
         },
         {        
            "description": "To Konstantin, the peasant was simply the chief partner in their common labor.",
            "page": 251
         }
      ]
    }
  }
}

ご覧のように、リクエストされた本にリンクされている quotes フィールドは、クエリで記述されたのと同じ形式の配列として返されました。ここでは示していませんが、GraphQL には、取得するデータの場所にこだわらないという利点もあります。Books と quotes は別々に保存することもできますが、アソシエーションが存在する限り、GraphQL は引き続き情報を取得します。つまり、クエリは 1 回のリクエストで多数のスタンドアロンデータを取得できるということです。

イントロスペクティブ

GraphQL は自己文書化されている、つまりイントロスペクティブです。スキーマ内の基になる型やフィールドをユーザーが確認できるようにするいくつかの組み込み操作をサポートしています。例えば、Foo およびdate フィールドのある description 型があります。

type Foo {
	date: String
	description: String
}

_type オペレーションを使うと、スキーマの下にあるタイピングメタデータを検索できます。

{
  __type(name: "Foo") {
    name                   # returns the name of the type
    fields {               # returns all fields in the type
      name                 # returns the name of each field
      type {               # returns all types for each field
        name               # returns the scalar type
      }
    }
  }
}

これは応答を返します。

{
  "__type": {
    "name": "Foo",                     # The type name
    "fields": [
      {
        "name": "date",                # The date field
        "type": { "name": "String" }   # The date's type
      },
      {
        "name": "description",         # The description field
        "type": { "name": "String" }   # The description's type
      },
    ]
  }
}

この機能は、特定の GraphQL スキーマがどのタイプとフィールドをサポートしているかを調べるために使用できます。GraphQL は、さまざまなイントロスペクティブなオペレーションをサポートしています。詳細については、「イントロスペクション」を参照してください。

強力なタイピング

GraphQL は、型と項目のシステムを通じて厳密な型指定をサポートしています。スキーマで何かを定義する場合は、実行前に検証できる型でなければなりません。また、GraphQL の構文仕様に従わなければなりません。この概念は他の言語のプログラミングと何ら変わりはありません。例えば、先ほどの、Foo 型があります。

type Foo {
	date: String
	description: String
}

Foo が作成されるオブジェクトであることがわかります。Foo のインスタンス内には、date および description フィールドがあり、両方とも Stringプリミティブ型 (スカラー) です。構文的には、Foo が宣言されていて、そのフィールドがスコープ内に存在していることがわかります。このように型の確認と論理構文を組み合わせることで、GraphQL API は簡潔でわかりやすいものになります。GraphQL のタイピングと構文の仕様については、こちらを参照してください。