GraphQLとは？
現在、API関連で非常に注目されている用語です。従来のRestAPIと比べて、ソフトウェア開発においてどのような特徴があるのでしょうか？
GraphQLは、APIのためのオープンソースのクエリ言語です。クライアントがサーバーからより効率的にデータを要求できるようにする技術です。
Facebookによって開発され、2012年から社内で使用されていましたが、2015年に公開されて以降、広く使用されるようになりました。従来のRestAPIとは異なり、クライアントは必要な情報だけを正確にサーバーに要求することができます。
GraphQLの核心的なアイデア
例えば、Facebookの投稿では、クライアントがサーバーにAPIリクエストを送信して、ユーザー名、投稿ID、投稿日、いいねの数などの情報を取得します。しかし、実際に表示するコンテンツに必要な情報は1～2個だけということもあり、多くの情報が冗長になっています。Facebookのような大規模なシステムでは、一見些細に見えるかもしれませんが、影響は確実にあり、塵も積もれば山となります。
そこで、Facebookのエンジニアたちはこのプロセスを最適化する方法を考案しました。GraphQLを使用すると、クライアントは特定のユースケースに必要な情報だけを要求して受け取ることができます。
GraphQLとRestAPIの違い
この2つの違いを簡単に説明すると？
長年使われている「GraphQLハンバーガー」のミーム（例え話）が、この技術の概念を理解するのに最適な説明となっています。
ハンバーガーを注文するお客様の例で考えてみましょう。ウェイターがRestAPIだとすると、「チーズバーガー1つ」としか注文できません。このウェイターにとって、チーズバーガーとは「バンズ、パティ1枚、トマト2枚、チーズ1枚」という決まった構成のものです。トマトを抜いたり、パティを2枚にしたりという注文はできませんし、ウェイターもそれを理解できません。
一方、GraphQLウェイターは、より柔軟で顧客中心的です。玉ねぎやトマトを抜いたり、ビーガンの方ならチーズも抜いたりできます（もっとも、チーズなしのチーズバーガーとは何でしょう？）。このウェイターなら、クライアントからサーバーへのリクエストを特定の用途に合わせて最適化できます。
限界は？
- GraphQLは、APIを置き換えるスーパーヒーローではなく、APIの上に追加される層として機能します。まだそれほど普及していないため、多くのオープンソース拡張機能がRestAPIと互換性がありません。
- 追加層があるということは、追加のキャッシュが必要になり、サーバーの負荷が増加します。
- RestAPIと比較して、GraphQLの実装には追加の時間と作業が必要です。
RestAPIの代替としてGraphQLを使用すべきか？そして必須なのか？
この質問は逆から考える必要があります。まず、従来のRestAPIをGraphQLで置き換える必要が本当にあるのでしょうか？これを判断するには、GraphQLがエンドユーザーにもたらす変化を検討する必要があります。エンドユーザーの視点からすると、実際には大きな違いはありません。したがって、RestをGraphQLに置き換えることは必須ではありません。
しかし、GraphQLは新しい技術であり、新技術には常に可能性があります。トレンドの先を行けば、テクノロジーの先を行くことができます。可能であれば、小規模なプロジェクトでGraphQLを試してみて、その機能や可能性を把握することをお勧めします。
より詳しい洞察については、こちらの記事をご覧いただくか、お気軽にメッセージをお送りください！
