🌟

ConnectRPCは「持て余している」のか？ - 実は戦略的な使い分けをしている話

に公開
gRPC
Connect RPC
tech

はじめに

「ConnectRPCはgRPC互換だけど、うちはHTTP/1.1としてしか使ってないから持て余してるんじゃない？」

そんな疑問を持ったことありませんか？しかし実際にConnectRPCの使われ方を詳しく見てみると、全然持て余していないことが分かります。
むしろ、非常に戦略的で効果的な使い分けがされているのです。

ConnectRPCの3つの使い分けパターン

1. HTTP/2もちゃんとサポートしている 

// 実際にはHTTP/1.1とHTTP/2の両方をサポート
server := http.Server{
    Addr:    ":8080",
    Handler: h2c.NewHandler(mux, &http2.Server{}), // HTTP/2対応
}

「HTTP/1.1しか使ってない」わけではなく、クライアントの対応状況に応じて自動的に最適なプロトコルを選択しています。

2. 用途別の戦略的使い分け

パターンA: ブラウザ → サーバー

// 管理画面やアプリからの呼び出し
mux.Handle(corsWrapper( // CORS対応
    adminapi.NewUserServiceHandler(...)  // HTTP/1.1 + JSON
))

特徴:

  • HTTP/1.1 + JSON
  • CORS対応でブラウザから直接呼び出し可能
  • 開発者ツールで簡単にデバッグ可能

パターンB: サーバー → サーバー（内部API）

// マイクロサービス間の通信
client := internalapi.NewServiceClient(
    httpClient,
    "http://internal-service:8080"  // HTTP/2 + Binary可能
)

特徴:

  • HTTP/2 + バイナリProtobuf（可能な場合）
  • 高性能・低レイテンシ
  • ロードバランサーやプロキシを通過しやすい

パターンC: 外部サービス → 自社API

// パートナー企業からの呼び出し
mux.Handle(
    publicapi.NewWebhookHandler(...)  // HTTP/1.1 + JSON
)

特徴:

  • HTTP/1.1 + JSON（互換性重視）
  • 外部からアクセスしやすい
  • 既存のHTTPツールチェーンで管理可能

なぜこの使い分けが優秀なのか

1. プロトコルの統一 

従来のアプローチ           ConnectRPCアプローチ
├─ REST API（ブラウザ）    ├─ Connect（ブラウザ）
├─ gRPC（内部）           ├─ Connect（内部）
└─ GraphQL（モバイル）     └─ Connect（モバイル）

= 3つの異なる技術スタック  = 1つの統一された技術スタック

2. 開発効率の向上

  • 1つのproto定義から全ての用途のコードを生成
  • 1つのハンドラー実装で複数のプロトコルに対応
  • 1つの型システムで型安全性を保証

3. 運用面でのメリット 

// 同じログ形式、同じメトリクス、同じエラーハンドリング
func (h *Handler) GetUser(ctx context.Context, req *pb.GetUserRequest) (*pb.User, error) {
    // ブラウザからでもサーバーからでも同じ処理
    logger.Info("GetUser called", "user_id", req.UserId)
    
    // 共通のビジネスロジック
    return h.userService.GetUser(ctx, req.UserId)
}

ConnectRPCの真の価値

「持て余し」ではなく「Future-Proof」

  1. 段階的移行が可能

    • 既存REST → Connect（HTTP/1.1 + JSON）
    • 徐々にHTTP/2 + Binaryに最適化

  2. チーム学習コストの最小化

    • フロントエンド：「HTTP APIを叩くだけ」
    • バックエンド：「Goの関数を書くだけ」
    • インフラ：「既存のHTTPツールが使える」

  3. 技術負債の削減

    • RESTとgRPCの2本立てを維持する必要がない
    • API仕様の二重管理が不要

まとめ

「HTTP/1.1しか使ってないから持て余している」は完全な誤解でした。

実際には：

  • ✅ HTTP/2もサポートしている
  • ✅ 用途に応じて最適なプロトコルを自動選択
  • ✅ 開発・運用効率を大幅に向上
  • ✅ 将来の技術進化に対応可能

ConnectRPCは「gRPCの代替」ではなく、「プロトコルに依存しない、統一されたRPCフレームワーク」として機能しています。これこそが、モダンなマイクロサービスアーキテクチャに求められる柔軟性なのです。

Discussion