Webフロントエンド向けにGraphQL/REST/gRPCがよく比較対象になるので雑にまとめたい。
WebとiOS/Androidなクライアントに対して静的型を生成したいときというユースケースがメイン。マイクロサービス間通信とか他の用途ではまた別の議論があると思う。
筆者はGraphQL推しなのでそこがメインの主張になると思うけどREST/gRPC側の意見も是非聞きたい。

「Webフロントエンド向け」という前提を置くとGraphQLにしかない大きなアドバンテージがあると思ってて、よくあるのがリソース指向でAPIを定義したいサーバーサイドと、画面・ユースケースベッタリなAPIがあると便利なフロントエンドでこのミスマッチをどう解決するかというやつ。
REST/gRPCだと、クライアントサイドでJOINするか、BFFを置いてリソース指向のAPIを画面向けに束ねる処理を書くかしかないと思う。GraphQLはまさにそこを解決していて、リソース指向なSchemaに対して画面ベッタリなQueryを発行することができる。このへんはいい感じの記事なりサンプルがないとGraphQL触ってない人には旨味がいまひとつ伝わらないかもしれない

RESTだとSwagger/OpenAPIを使うことになると思うが、本来型がないRESTに型を載せているしんどさとかJSON Schemaみたいなのを学習コストがある気がする。

gRPCはもっとローレベル（？）なところに目が向いていて、protobufがバイナリな都合でprotobuf3からOptionalがなくなってそれはWebフロントエンド向けという用途ではその点だけでも不便な気がする。oneofなどで代替もできるが、変なハマりどころもあってやっぱうまくいかなかったのが数年前の記憶で今はよくなってるのかもしれない。

GraphQLクライアントとして高機能なやつではApolloとRelay、軽量なやつではurqlなどがある。
最近v11がリリースされたRelayは、以前はContainerベースのAPIがちょっと馴染みにくい感じがあったが、v11からはHooksベースのAPIがstableになってApolloよりも採用機会が増えてくる気がする。GraphQLを作ったFacebookが作ってるだけあって、公式サイトのガイドで一通り触ってみるだけでもApolloよりも強力なところがすぐに分かると思う。RelayはIDとPagingのSpecを独自に持っていて、それを前提にした機能が組み込まれていてめちゃ便利（どう便利かあとで書く？）
https://relay.dev/

GraphQLとgRPCに関しては、それでドメインロジックを記述してしまっても良いのではないか？というアイデアというか妄想がある。主にサーバーサイドの言語で外部への依存を排除して、非同期やトランザクションとかを無視してPOXOと関数でドメインロジックを記述するのをよくやると思うけど、これをGraphQL/gRPCでやってしまって良いのではないか？
GraphQLに関して言うとdirectiveで権限やバリデーションくらいのロジックを含めることができるのでいけるのではないかと思っているけど、ググってもいい感じの記事が見つからない。やってみてよかったもないしするなってやつもない。

結論

自分にGraphQL寄りなバイアスがあってフェアな結論でないかも知れないことは十分承知で、それでもGraphQLが他の2つに比べて大きく優位だと思う。

• 自分が前提としているシステムの規模はある程度の規模のマイクロサービス
• RESTはリソースに対する取得・作成・更新・削除を定義するのが基本なはずで、ここに十分なビジネスロジックを表現するのは難しい
• マイクロサービスのアグリゲーションをBFFで行うのはほとんど必須で、そうなるとgRPCよりもGraphQLが有利
  • マイクロサービスはgRPCを喋ってBFFよりクライアントサイドはGraphQLというのはよくある構成っぽい
  • AirbnbのViaductはその構成を前提とした仕組み
  • マイクロサービスの数が多くなってくるとアグリゲーションを手で書くのは現実的ではなくなってくる。そうするとSchema Stitching, Apollo Federation, GraphQL Meshといった自動化の技術はほぼ必須になる
    • この3者の踏み入った比較はまだなさそう
    • アグリゲーションのロジックがBFFに集中しないのがFederationの特徴で、おそらくそれがスケールする気がする