仕事でGraphQLに関わる予兆があるのですが、なかなかGraphQLに馴染みがなかったので、まずは「はじめてのGraphQL」を読みました。
感想を一言でいうと、本当に読んで良かったという読後感です。
ぼくの悪い癖として、新しい技術を学ぶときはRFCや公式仕様/ドキュメントから入ってしまうことが多いです。 これまでGraphQLを学ぶのに挫折していたのも公式仕様から読もうとしてその時間がないからでした。 O'Reillyの「はじめての…」シリーズでは対象となる技術の全体感を示しながら、簡単なアプリケーションを作っていくことで、 実践に必要な最低限の知識を吸収できるのが良いですね。
この書籍では、具体的なアプリケーションとして写真の共有アプリを実装していきます。 利用するのは主にApollo ServerとApollo Clientです。 GraphQLでのファイルアップロード、クエリの深さや複雑度に対するバリデーション等、かなり実用的な内容に感じました。
GraphQLの魅力
GraphQLの世界においては、クライアントからサーバに対してGraphQLのDocumentが送信されていきます。
このDocumentで「何をしてくれ」という依頼を表現しますが、その種類(OperationType)は3つです。
query: 参照mutation: 書き込みsubscription: イベントに反応する形のlong-livedな参照
GraphQLの何が良いかというと、クライアントで必要な情報を1度に取得できるところでしょう。
RESTでシステムを実装しようと思うと、サーバサイドは各リソースに対してCRUD (GET/POST/PUT/DELETE)を定義するとともに、
クライアントはリソースごとにAPIを呼び出す必要がありました。
また、フロントエンドでは、それに応える形で1画面に表示すべき「リソース」の情報を描画するために複数APIを叩く必要がありました。
そしてこの構造により、バックエンド・フロントエンドチームは密な調整と結合を迫られてしまいます。
GraphQLではDocumentに複数のQueryを含められるため、必要な情報を一度のやりとりで揃えられます。
もちろんこれは理想世界の話であり、実践の場ではそれを阻む問題も多々あるのでしょうが、RESTの"痛み"を解決する方法としては魅力に感じました。
僕自身は、上述のRESTの痛みを解決する方法としてgRPCに代表されるRPCが再興している認識でしたが、 GraphQLはその代替となるのかもしれません。 ただ、一応書籍上は以下のように「GraphQLがRESTに成り代わるのは行きすぎた主張」と述べています。
GraphQLがRESTに成り代わるというのは行きすぎた主張でした。より実情に即した表現をするのであれば、 Webが発達するにつれてRESTが適合しない状況が生まれ始めているということです。そういった状況に適合する 形式のAPIとして、GraphQLが誕生しました。
フロントエンドとバックエンドが完全に分かれ、その間をAPIがつなぐというアーキテクチャを見ることが多くなってきました。 そういったAPIを提供しようと思った時、GraphQLにチャレンジするのはかなり筋が良いように感じています。
