📶

REST vs gRPC vs GraphQLの自分なりのまとめと結論

2023/06/04に公開

背景

曖昧になっていたので整理

REST vs　gRPC vs GraphQL

ざっくり言うと、REST、gRPC、GraphQLはAPIの設計手法の違い
gRPCはGoogleのRemote Procedure Call（RPC）フレームワークであり、APIとは厳密には異なる概念。

比較表

以下の表はREST API/gRPC/GraphQLでChatGPT氏に比較表を作っていただき、少し編集したもの。

	HTTPプロトコル	エンドポイント	パフォーマンス	データ型のサポート
REST API	HTTP/1.1、HTTP/2	リソースごとにエンドポイントが設けられることが多い。そのリソースに対する操作をGET, POST, PUT, DELETEなどで表現。	△(JSONであることや、オーバ/アンダーフェッチは起こり得る)	JSON、XML、MessagePackなど
gRPC	HTTP/2	サービスごとに.protoファイルで定義され、サービス内の各メソッドが実質的なエンドポイントとなる。	◯(ProtobufとHTTP/2により一般的に良い)	Protobuf
GraphQL	HTTP/1.1、HTTP/2	`/graphql`の単一。一つのエンドポイントで全てのクエリとミューテーションを処理し、クライアントは具体的なデータ要求をクエリとして送信する。	◯(クライアントがほしいデータを指定するので、オーバ/アンダーフェッチは起こりにくい)	型付けられたGraphQLのスキーマ

REST

一般的な採用例が多く、実装例や知見がWeb上に豊富に存在
クライアントからサーバーへの設計が一般的で直感的で実装しやすい
JSONは特に可読性が高く、現代のJavaScriptフレームワークとの相性が良い
OpenAPIを使用してスキーマを作成することもできるが、スキーマとの一貫性を保つためのサードパーティ製ライブラリが存在するなど、サポートには差がある
実装が容易でエンドポイントの意図や可読性が高いが、APIの実装が都度必要なため、現代の運用においては手間がかかることことがある
キャッシュさせやすい

gRPC

RPC APIを構築できるフレームワーク
スキーマで型を定義できるので大規模で複雑になりそうなシステムに向きやすい・パフォーマンスも一般的に良い
Protobufはバイナリフォーマットなので、デバッグしようとすると慣れやエンコード/デコードの知識が必要。Protoファイルの書き方にも慣れが必要
HTTP/2で動かすときも知見がないと調べないといけない
メソッド名の呼び出しが公開されるので、分かる人が見るとエンドポイントを推測できそう
Pythonのクライントから、別で実装されているGoのメソッド(マイクロサービス)を呼び出したりできるので、マイクロサービス間の実装に向いている

GraphQL

データをクライアントが指定するので、フロント主導で構築するシステム向き
常POSTリクエストになるため、キャッシュどうする問題/N+1/フェッチできるデータの制限/常200に対するエラーハンドリング、使用するフレームワークにはやや知見がいる印象
ちゃんと作れれば、APIは1つで済むし実装コストは低くなる

キャッシュ・N+1問題

フレームワーク

未来を含む要件に応じて適切なフレームワークを選択する

結論

要件に依るものが大きいが、API実装するときに、ジュニアエンジニアが多い環境だったり、チョッパヤで実装したいならREST、自社サービスで運用も見据えてならGraphQLかgRPC(Webブラウザ〜サーバー間の場合はgRPC-Web)
https://grpc.io/blog/state-of-grpc-web/#the-grpc-web-spec
マイクロサービスが存在する場合は、部分的にgRPCを導入することも

参考になりそうなWantedlyの実装

備考

データフォーマットにXMLを使うもので、SOAPというものがあり、2000年はじめはSOAP vs RESTだったが、結局Web業界はRESTが採用されることが多い。古いシステムでSOAPが指定されているシステム仕様もまだまだある。
スキーマ言語がなぜ出てきたのかも理解した方が良い
下記も面白そう
https://logmi.jp/tech/articles/324081
分かりやすい解説
https://jp.quora.com/GraphQLがRESTに取って代わるということはありえますか

以上です、読んでいただきありがとうございました。

Discussion