😎

Connectを構成する技術について理解する

2025/02/05に公開

弊社のサーバーサイド/フロントエンドの開発には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としての互換性を持たせていたから。

https://connectrpc.com/docs/protocol#summary

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