Connectを構成する技術について理解する
弊社のサーバーサイド/フロントエンドの開発にはConnectが使われています。
gRPCに触れた経験がほとんどなかったこともあり、Connectを使っていて混乱することが多かったため、Connectについて詳しく調べてみました。
混乱した点
- proto/gRPC/Connectの境界線が曖昧で、今触っているのがどれに関連する箇所なのかわからない
- gRPCのAPIのはずなのに、RESTのAPIみたいに呼び出せてるのはなんで?
Connectを構成する技術を分解して理解する
以下の3つの技術に分解し、1つずつ理解を進めました。
- Protocol Buffers
- gRPC
- Connect
Protocol Buffers
- データのシリアライズを目的とした技術スタック
-
.proto
ファイルのmessage
構文でシリアライズするデータの構造を定義すると、データを扱うためのコードを自動生成してくれる - gRPCはリクエスト・レスポンスのシリアライズの手段としてProtocol Buffersを採用している
- gRPCに限らずシリアライズの手段として様々な箇所で使用されている汎用的な技術
gRPC
- RPCを実現するための技術スタック
-
.proto
ファイルのservice
構文でRPCサーバーのインターフェイスを定義すると、RPCサーバー・クライアントのコードを自動生成してくれる - HTTP/2で通信するように設計されている
Connect
- gRPC、REST、HTTP/1.1/HTTP/2を横断的にサポートするRPCフレームワーク
- Connectを使うことで、Connectプロトコルを介してgRPCをブラウザ上のクライアント(JavaScript)から呼び出せるようになる
混乱していた点について改めて整理してみる
proto/gRPC/Connectの境界線
自分が実装に関わった箇所は、以下のように分類することができそうでした。
- proto
-
.proto
ファイルのmessage
でデータ構造を定義する
-
- gRPC
-
.proto
ファイルのservice
でgRPCサーバーのインターフェイスを定義する
-
- Connect
- WebブラウザのフロントエンドからConnectプロトコルを介してgRPCのAPIを呼び出す
gRPCのAPIなのに、RESTのAPIみたいに呼び出せる理由
Connectが、gRPCのAPIにREST APIとしての互換性を持たせていたから。
ConnectプロトコルというConnect独自のプロトコルのおかげで、gRPCのAPIがREST APIのようなエンドポイントを持ち、JSON形式のリクエスト・レスポンスでやり取りができるようになっています。
Unary RPCs use the application/proto and application/json Content-Types and look similar to a stripped-down REST dialect. Most requests are POSTs, paths are derived from the Protobuf schema, request and response bodies are valid Protobuf or JSON (without gRPC-style binary framing), and responses have meaningful HTTP status codes. For example:
> POST /connectrpc.greet.v1.GreetService/Greet HTTP/1.1 > Host: demo.connectrpc.com > Content-Type: application/json > > {"name": "Buf"} < HTTP/1.1 200 OK < Content-Type: application/json < < {"greeting": "Hello, Buf!"}
まとめ
なんとなく使っていたConnectですが、時間を取って調べることで、その強みや便利さを理解することができました。
gRPC・Connectを実務で使ってみたい方は、ぜひ弊社をご検討ください!
Discussion