次世代APIインターフェースGraphQL

GraphQLとは?
FacebookがAPIのインターフェースとして2012年くらいから開発しています。
2015年に公開され、2016年の9月に正式にproductionでの使用に耐えうるものとして公開されました。

FacebookのタイムラインやメッセージはGraphQLを使ってデータ取得をしているため、実は世の中のほとんどの人がすでにGraphQLのユーザーです 笑

何が次世代なの?
APIといえばRESTfulなendpointを経由してリクエストを送ることが一般化していますがGraphQLはRESTとは違った方法でAPI提供者とデータのやりとりを行うことを可能とします。なので次世代です。

GraphQLとRESTの違い
別に次世代である事がだけが目的では無いのですがGraphQLを使うことでいろいろなメリットがあります。

  • 必要なデータだけ取得可能
    RESTfulなAPIでは返ってくるデータの内容をコントロールすることができませんでした。
    ユーザー情報をとってくるRESTのendpointを使うとそのユーザーに関する情報がすべて返ってきたりしますね。それをGraphQLでは一部のデータだけしか返って来ないように指定することができます。
  • 複雑なクエリも1つのリクエストで取得可能
    複数のテーブルをまたぐようなリクエストをRESTでやろうとするとどうしても複数回のリクエストを送る必要があります。先程のユーザーの例を続けるとユーザー情報をとってくるリクエストが一回。またそのユーザーが所属する会社の詳細情報を取得するのにもう一回リクエストを送る必要があります。
    この様なリクエストはGraphQL内で事前にユーザーと会社の関係性を定義しておけば一回のリクエストを送ることで全ての必要な情報を取得することができるようになります。
  • mutations
    GraphQLにはRESTのPOSTリクエストと同じようにデータを追加するようなリクエストと送ることもでき、mutationと呼ばれています。mutationも複数のテーブルに対して更新をかけることができるので一回のリクエストで複数のテーブルの更新を行う事ができます。ちなみにMySQLとかでいうテーブルはGraphQLではTypeといい、スキーマファイルで事前に設定します。
  • pub/sub
    これはFirebase Databaseでも使用可能な機能ですが、一度subscriptionを
    特定のTypeにくっつけて置くとそのTypeに何らかの更新があった場合などに
    自動的にpushでデータが返ってきます。
    この機能を使うことでいちいちデータをクライアント側から読みに行かなくても
    データの更新があったときだけデータが送られてくるようになります。
    現在天野もpub/subを使ってチャットの実装などを行っています。
    pub/subは実はGraphQLの標準の機能ではないのですが、AppoloやRelayなどのGraphQLのライブラリに実装されていてドキュメントにもきっちり書いてあるのでGraphQLの機能と言うことにして説明しています。

利用シーン
いろんなメリットがあるGraphQLですが、具体的な利用シーンを考えてみました。

  • ECサイトから顧客情報の取得
    ECプラットフォーム提供者がデータをクライアントに送るのに、GraphQLを使うこと顧客リストと各顧客に紐付いている注文データを一つのリクエストで取得可能になります。
  • 銀行のリアルタイムデータの提供
    銀行のAPIを使っているクライアントがsubscriptionを設定することで口座に振り込みや支払いがあった際にリアルタイムで情報を取得できるようになります。

実際にあった話
今とある案件でPWAアプリの開発を行っています。天野はアプリの開発担当で入っていてデータ取得に関しては先に開発をされていた別のシステム会社のエンジニアさんと作業をする必要がありました。このアプリは美容室予約用のアプリです。

今回の作業はすでに存在するネイティブアプリのインターフェース改善を行いつつ、PWA, iOS, Androidアプリを作り直すことです。

既存のアプリがあることもあり、既存のアプリ用のREST APIを使うことができたため作業は特に問題なく進んでいました。

その中この美容室を経営されているクライアントさんから予約してくれたお客さんに前日の朝に次の日に予約があることをお知らせするプッシュ通知を送れるような機能の相談を受けました。

プッシュ通知の機能はFirebase Cloud MessagingやAppleのpush通知の機能を
使えば送れるのですが、クライアント側でその処理をするにあたり既存のRESTの
endpointではその様な情報は提供していませんでした。

明日の予約だけをリストアップできるようなクエリを呼ぶためにRESTのendpointを追加する必要があり、それにはそれなりの工数がかかってしまうという事でした。

GraphQLを使えばこの様に新たに機能追加やクエリ発行のためにRESTのendpointを追加することが必要でないため、バックエンドのエンジニアの方の手を煩わせずにフロント側からデータベースに入っている様々なデータにアクセスすることが可能になります。

ですのでこの様な機能追加の際もフロントエンドの側だけの作業で終えることができ、早くGraphQLが普及してくれないかなと思った瞬間でした。

これからのAPI提供者
APIを外部に公開するというとこれまでSQLデータベースを設置してそこにデータ参照や更新用のRESTのendpointsをたくさん用意する必要がありました。

GraphQLを使うことで、API提供者は各Typeの定義と外部ユーザーはどこまでアクセスできるかを定義するだけであとは外部のAPI利用者がそこに対して様々なクエリやmutationを発行してデータを操作できるようになります。

このREST endpointあればこんな機能が実装できたのにと開発者であれば一度は思った事ありますよね。

これまでのRESTが間に入っていたことによるいろんな制限を解消してくれるかもしれないGraphQLの可能性にワクワクする毎日です。ってそんなの俺だけか 笑

さらに詳しく
http://graphql.org/
本家のサイト

https://www.graph.cool/
GraphQLホスティングサービス。うちもこれ使ってます。
これでデータベースはserverlessになってます。

https://slack.graph.cool/
Graph Coolユーザーのslack

https://www.howtographql.com/
よくまとまっているGraphQLのチュートリアル