APIのスキーマ定義技法の比較
この3つの関係性を大まかに捉えると、「かつてはREST APIが事実上のスタンダードだったが、いろいろな所で使われるうちに適応しにくいケースが出てきて、そうした課題を解決するためにgRPCやGraphQLが出てきた」
Webフレームワークを採用しておりREST APIを作成するコストが低い
Readが多くてCDNがとても効果的
HTTPキャッシュといった既存のHTTPの資産の一部はWebブラウザと相性が良いものが多く、ネイティブアプリやSPAのバックエンドとしてのAPIサーバとして考えた場合には、REST APIで使えるものは限定的です。特に、マイクロサービス同士の通信ではキャッシュが効かないこと、もしくは通信がデータセンター内で完結することが多いと考えられるため、gRPCのような通信方式の方がパフォーマンスに優れています
メインの言語でライブラリがなければ非推奨
gRPCは規模が大きいフレームワークのため、良い実装がない言語において、自分で実装するのはあまり現実的ではありません。
静的型付き言語においては、生成したコードによって型を保証したり、IDEによる補完が期待できるため、開発者体験の向上も見込めます。OpenAPIやGraphQLでもシリアライズをProtocol Buffersにして通信効率を上げたり、クライアントライブラリを生成することで同じレベルの開発者体験は実現できますが、gRPCではそれらが全てフレームワークに含まれているため、導入・運用がとても楽です 単一のmicroservicesはデータそんなもってないから
HTTP層でキャッシュが効かない
GraphQLでは別々のクエリで同じリソースを取っていたとしても、クエリの中身を解析するまでは分からないため、アプリケーション側でキャッシュ機構を作り込む必要があります
kadoyau.icon ライブラリが頑張ってる
例えば、ニュースアプリでは「記事一覧の画面に遷移したときに、記事タイトルだけではなく本文など記事に関するデータを全て取得する」ことで、オフライン状態でも記事詳細に遷移できるようになります。このような場合、GraphQLで個別にフィールドを制御する重要性は薄れます。むしろ、詳細画面の実装を一覧画面で気にする必要が出てくるため、実装としては複雑になるでしょう。
また、アプリ側がNULL安全な言語を利用している場合、NULLが混在すると別々のクラスにする必要があるため、よりフィールドごとの制御の効果が薄くなります。ただし、コンポーネントに必要な情報だけを持つクラスを定義する場合や、Viewに強く紐付いたデータ設計を行う場合は、必要なデータを必要なだけ取ってこられるため、フィールドごとの制御は非常に効果が高くなります。
https://gyazo.com/c0b5a6f04644a72c735ed9458af46b75