コロナ時代のGraphQL
GraphQLのチュートリアル、 How to GraphQL をやった。どんな技術であるのかについて、概論やイメージは浸透しているだろうから、この記事はあらためてそれを紹介するというよりも、初めて実装に触れた学習者の立場から手応えを交えて書く。すなわち、GraphQLはどんな場面に適していて、実際に使えそうかどうかまでを扱う。
なお「コロナ時代のGraphQL」というタイトルは、単に「2020年上半期時点のGraphQL」というだけの意味であって、それ以上の含意はない。
RESTとGraphQLを取り巻く認識論の世界
RESTとGraphQLは本質的に異なるパラダイムにある。この前提を持たないまま、個別の詳細についてみることを始めると、比べられないものを比べて評価するという不毛な状況に陥りかねない。よってまずは用語を整理するところから始める。
まず graphql.org の見出しにはA query language for your API とある。つまり、 GraphQL はそもそも、フレームワークでもプロトコルでもなく、クエリ言語であるということ。この定義をしっかり押さえておきたい。
RESTと GraphQL を比較することはよくある。しかし、実はこれがなかなか難しい。『Real World HTTP 第2版――歴史とコードに学ぶインターネットとウェブ技術』より引用する。
RESTはHTTPのシンタックスをプロトコルの土台として使っていますが、通信のセマンティクスもHTTPにならうようにしましょう、という考えです。（渋川 302）1
要するに、RESTとはHTTPの上に説かれた「考え」、設計思想に過ぎないのである。
さらにことを複雑にするのは、例えばMicrosoft社でさえ、RESTの提唱者にしてREST界の法王の Roy Fielding をして Microsoft REST APIガイドラインはRESTfulではない と憤慨せしめてしまうように、誰もが雰囲気でRESTという言葉を使っていることである。そしてこの曖昧な受容があまりに一般化してしまった現状は、不毛な神学論争を非常に誘発しやすい。
さらに Roy 自身がRESTの定義を書いた こちらの記事 も読んでみてほしい。RESTに定義があるのならばそれに従えばいい、簡単な話だと思うだろう。しかし困ったことに、REST提唱者によるRESTの定義は、「RESTとはこうあるべきではない」という方式に綴られた、否定による定義だ。これではいよいよ神学の領域に踏み込まないと答えは得られないだろう。
要するにこういうことである（REST警察に捕捉されないよう祈る！）。RESTとは実体を持たない思想である。それに対して、GraphQLは言語とランタイムという実体を持つ。
本記事に限らず、これらの技術について何かを語ろうとするときには、このことをまず念頭に置くこと、これが議論のスタートラインとなる。
で、使えそうか？
チュートリアルを踏まえて、 GraphQL の手応えを書くという話だった。そして変化の大きいプロジェクトに導入しようとは思えないのが正直な感想である。
先に述べたように、いくら便利なライブラリが詳細な実装を隠蔽してくれていても、本質的にはこれは新しいパラダイムである。
クライアントが発行するクエリと、それに対応するレスポンスの凡例をみていくと、確かにそれは画期的で、エレガントな技術にみえる。しかしいかんせん学習コストが高いのと、漸進的に置き換えるにしても実装コストが高くつくであろうことを踏まえて、どんな苦労が待ち受けているかの絵を描きづらいところが一番の難点だ。導入事例が乏しくて不安がある、というように言い換えてもよい。
これだけであればただの感想であるので、いちおういくらか客観的な評価を援用する。 ThoughtWorks 社の Technology Radar においては、GraphQLは初登場から4年間にわたって評価保留中とみなされている2。つまり、あえて採用することを止めはしないが、積極的なお墨付きはまだ与えられない、ということである。
既存プロジェクトへの導入という観点からは、大量のAPIを統合してシンプルなインターフェイスを提供するプロキシサーバー的な使い方が紹介されているのも面白い。以下にモデルを引用する。
面白いのは面白いのだが、これも結局のところ、レガシーサーバーの仕様に沿って新しいサーバーを実装して、しかもレガシーサーバーは捨てられないことになる。システム全体を維持するためのコストはむしろ増大し、いいことなしなような気もする。
どこでなら使えそうか？
以上の結論は、 GraphQL を中規模以上のプロジェクトに導入することを、保守・運用も見据えて考えた時の話になる。
それを踏まえて、逆に単発の小さなプロジェクトにおいてなら、試してみるのは十分ありとは思う。
例えばマルチプラットフォームで素早く展開したい場面。異なるデバイス向けのAPIを提供するのに、 BFF アーキテクチャを取るよりなら、一台のGraphQLサーバーだけを用意するのは十分理にかなった判断だろう。その意味で、 AWS Amplify が GraphQL を無条件にサポートしているのは結構な御膳立てであるし、はじめに使うのであればここから入門するのがよさそうである。
おわりに
以上、2020年時点で GraphQL を触ってみた手応えを述べた。結論としては、本格的に採用するには時期尚早と思う。とりわけ日本国内で長期的なプロジェクトへの導入を検討するとなると、誤った実装に突き進んでしまったり、保守に手が回らなくなってしまうリスクを避けて、僕であればこれは見送る判断をすると思う。
もっとも、技術自体がまだ萌芽段階にあるのは明らかである。 GraphQL Landscape を見て欲しい。採用企業のリストはいまだ100社にも満たない。 GraphQL という名詞の知名度を考えると、これは想像よりもはるかに少ない。このことからも、多くの開発者がこの技術の向かう先に注目しつつも、まだ採用には踏み切っていないということがわかるだろう。
ひとまず現時点での評価は以上になる。しかしこれが今後数年をかけてどう移ろっていくか。それを見守る楽しみを得られたのはひとつの収穫である。
-
渋川よしき. Real World HTTP 第2版――歴史とコードに学ぶインターネットとウェブ技術. O'Reilly Japan. ISBN978-4-87311-903-8. https://www.oreilly.co.jp/books/9784873119038/↩
