GraphQL と gRPC と REST についての云々

この三つ、割と並列で語られる事が多い様に思うんだけど、実際にはコアのコンセプトが違うんではないか、 とか、なんとなく思ってるんで、その辺りをなんとなく書き下してみます。

GraphQL と gRPC と REST の違い

基本的に、GraphQL も gRPC も REST も、

Web Services の API を提供する

というレイヤーで使われているモノだ、と言えるかと思うんだけど、 これら三つは、多分、核となる考え方が、次に様に異なっている:

• GraphQL
  • クエリ言語をコアとして、そこから色々実装を生やす
• gRPC
  • API を RPC として定義し、実装を自動生成ベースで生やす
• REST
  • HTTP の セマンティクスをベースとした設計思想。実装は各自が適宜用意する

そのため、これらを並列に語る、というのは、微妙に違っていると言うか、 それぞれ何を解決したいか、は似通っているのだろうけれども、実際には、

• GraphQL
  • 従来の JSON や XML ベースの API 問合せを柔軟に改良したい
• gRPC
  • Protobuf の RPC を HTTP/2 などに載せて、PRC over http をカッチリと実現したい
• REST
  • HTTP ベースでのリソース表現を綺麗に表現したい

という感じなんだろう、と思われる。

GraphQL と gRPC と REST は共存できる

まぁ、

• GraphQL はクエリ言語
• gRPC は RPC API の為の Specs と Toolchain
• REST は API の為の設計思想

なので、これらの三つは、

REST の設計思想に従いつつ、gRPC ベースの問い合わせの中で GraphQL を使う

という様な、誰が得するのか良く分からない組合せ も やろうと思えば出来る と思う。

GraphQL と gRPC と REST の使い分け

個人的には、これらは次の様な感じで使い分けられるんじゃね？ と思っている:

• GraphQL
  • 非構造化データ の API 問合せの際のクエリ言語として使う
• gRPC
  • 構造化データ の RPC API を実装する際に使う
• REST
  • API だけではなく、 Web Services 全体の URL 設計指標 として使う

そのため、API や Web Page も含めて、Web Service などでこれらを利用する際には、 これらのどれか一つに実装を絞るのではなく、それぞれの特性・特長を見極めた上で、 その API などで提供したいデータの構造を加味しながら、それぞれを適切な場面に当て嵌めて行く、 というのが良いのではないか、と個人的には思っています。

以上

まぁ、最終的な結論としては、

GraphQL と gRPC と REST は対立項目ではなく、それぞれを適切に組み合わせる事も出来る類いのモノ

と言う認識になるのかな、と個人的には思っています。はい。