読書メモ：初めてのGraphQL
はじめに
グラフデータベースが次に来ると聞き久しくなりますが、Neo4jやセマンティックウェブで一世を風靡したRDFデータを使うSPARQLなど、ひっそりと使われているとは思うものの、正直そこまで頻繁に使われているとは聞きません。
一方、GraphQLに関しては、イーサリアム界隈ではThe Graphや、Facebookをはじめとした多くのソフトウェア企業で活用されているのが見受けられます。
また、イーサリアムクライアントのGethでも、なんとGraphQLが組み込まれています。
私も個人的にGraphQLを使ってアプリを開発しようと考えているため購入しました。
以下にて、読んでわかったGraphQLのメリット・デメリット簡単にまとめたいと思います。
GraphQLのメリット
GraphQL自体は、MySQLやオラクルで代表されるスタンドアロンなデータベースソフトウェアではありません。
データをGraphQLというインターフェースを使って問い合わせる仕様が定められており、実装が多数存在します。
データを保存するバックエンドは、RDBでも可能なようですが、JSONを保存するのに適したドキュメントデータベースであるMongoDBがメジャーなようです。
また、GUIやインターフェースを提供するという面においては、SPARQLに似ています。
しかし、RDFなどの複雑怪奇な標準化路線上にあるSPARQLとは違い、REST APIの欠点を補うものとして使われます。
例えば、当記事でConoHaのREST APIを使ってDNSの情報を変更しましたが、REST APIで以下のように4回もリクエストをする必要がありました。
- Conoha APIでトークンを取得
- Conoha APIでドメインIDを取得
- Conoha APIでレコードIDを取得
- Conoha APIで対象のAレコードを新しいIP（
＄NEW_IP）に設定
GraphQLのクエリでは、上記のトークン、ドメインID、レコードIDを一気にクエリで取得することができます （GraphQL APIを提供していればですが・・・）
また、データの更新には（RESTでいうPUTを）Mutationという仕組みを使います。
開発者は、上記のようにRESTで何回も問い合わする必要はありません。
欲しいデータのみをクエリするため、レスポンスに返ってくる不要なデータを取得してしまうことはありません（例えば上記の例では description を使わないのにRESTではレスポンスで返ってきてしまう等）。
さらに、保存するJSONデータのスキーマを定義することでグラフとしてつなげることが出来ます。
このように（グラフ理論の）グラフを使った探索が可能な点がREST APIと比べた最大のメリットと言えそうです。
また、Pub-Sabモデルに対応しており、簡単にデータの更新を配信できるビルトイン機能も魅力的です（注：各実装により違いがあるようです）。
最後に、GraphQLクライアントソフトウェアを使うことで、最小限の労力でフロントエンドのアプリケーション開発ができます。
この点においてもデータ（ブロックチェーン）とフロントエンド（アプリ）を分離でき、スピーディに開発できることが特にdAppで好まれて使われている点ではないでしょうか。
GraphQLのデメリット
実際に使ってみるとわかるのですが、インストールをしたら直ぐに使い始められるリレーショナルデータベースとはまったく違います。
モジュールとして提供されており、Node.jsなどと連携して立ち上げる必要があります。
MongoDBなどと連携するのにもプログラムを書く必要がありプログラミングに不慣れだと大変です。
また、スキーマの定義もJavascriptでプログラムとして書く必要があります。
日本のSIerのエンジニアのように役割が細分化している環境において、このように複数の技術をまたぐ仕組みには、抵抗があるかもしれません。
またドキュメントは、日本語の資料が充実していないため英語で読む場面が多くなります。
GraphQL実装も特徴によって、選ぶ必要があります。
例えば、Express GraphQL、Apollo GraphQL、GraphQL Yogaなど色々あり、実装、機能、処理速度に違いがあるようです。
理解するためにGraphQL Yogaを使ってちょっとしたサンプルアプリケーションを書いてみましたが、MongoDBと連携したPub-Subの作成が案外難しく苦労しました。
要するにデメリットとしては、Webアプリ、GraphQLの仕様、個別の実装を把握する必要があり、技術的な負荷がそれなりに高いと言えます。
総じて複雑なREST APIの開発をするより楽なものの、リレーショナルデータベースの印象で使うと大変という感じです。
まとめ
GraphQLは、REST APIのデメリットである不要なデータを取得してしまうことなく、さらに目的のデータを取得するために何回もリクエストを行うことも軽減してくれます。
また、データ同士を（グラフ理論の）グラフ形式で繋ぐことができ、リレーショナルデータベースが不得意な処理、例えば「Aさんの友人の友人の情報」を付加の高いJOINを多用したSQLをすることなく取得できます。
上記だと、それを取得するREST APIを再開発する必要がありますが、GraphQLはスキーマを定義すればAPIとしてすぐに公開できます。
デメリットとしては、実装においてはそれなりに技術的な負荷が高いことや実装の種類によって機能に違いがあることではないでしょうか。
しかし、かなり有用なコンポーネントだと思うので、引き続き実際に使って知識を深めたいと思います。
ここまで読んでくださりありがとうございました。