GraphQLについては名前くらいしか聞いたことがなく、どういうかは全く知らなかったのですが、最近調べる機会があったので、GraphQLを調べた際に知った特徴をまとめました。
GraphQLのことをこれから調べようと考えている方は、下記の特徴を覚えておくとGraphQLについて理解しやすくなるかと思います。
エンドポイントが一つだけ
RESTでAPIを作成する場合、ユーザー情報の取得やプロフィール情報の取得などの様々なAPIに、それぞれルーティング(例: “/users/” や “/profile/”)を設定します。
ですが、GraphQLで使用するエンドポイントは “/graphql” の一種類だけです。
“/graphql”だけしかないとすると、どのようにして取得する情報を決定しているのか？という話になります。
その問題について、GraphQLではクライアントからリクエストするスキーマによって解決しています。
スキーマ定義
下のスキーマは、GraphQLの公式サイトにも記載されている内容です。
クライアントからのリクエスト
次に示すのは、クライアントがリクエストするスキーマです。
{
me {
name
}
}
サーバからのレスポンス
下記がリクエストに対するレスポンスです。クライアントがリクエストしたスキーマの情報だけが返却されています。
{
"me": {
"name": "Luke Skywalker"
}
}
typeオブジェクト
上記のリクエストとレスポンスは、下記のスキーマが元になっています。
“type Query”で定義されている”me”に対するスキーマがリクエストされた場合、”User”を返却するように定義しています。
“User”は”id”と”name”を保持するものとして定義されています。
ここでのポイントは、”User”は”id”と”name”を保持していますが、上記のレスポンスではクライアントからリクエストされた”name”だけを返しているという点です。
type Query {
me: User
}
type User {
id: ID
name: String
}
GraphQLでは、クライアントが必要とした情報だけを過不足なく返却する約束になっています。
APIの開発にありがちな「余分な情報がレスポンスに含まれる」ことや「必要な情報が足りない」ことが起こらなくなります。
また返却可能なパラメータは「typeオブジェクト」としてスキーマが定義されているため、クライアント側を実装する際、パラメータについて悩む必要がありません。
クライアント側とサーバ側でスキーマを取り決めておけば、それに沿って開発をスムーズに進められると思います。
まとめ
GraphQLについてはほとんど知識がありませんでしたが、調べて感じたのは「上手く使えるとAPI開発において強力なツールになりえるな」という印象でした。
またGraphQLについて調べたことを記事に書きたいと思います。
この記事がGraphQLについて調べてみようという方の役に立てば幸いです。
