この三つ、割と並列で語られる事が多い様に思うんだけど、実際にはコアのコンセプトが違うんではないか、 とか、なんとなく思ってるんで、その辺りをなんとなく書き下してみます。
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 は対立項目ではなく、それぞれを適切に組み合わせる事も出来る類いのモノ
と言う認識になるのかな、と個人的には思っています。はい。
