dotnet-service-communication

dotnet-service-communication

適切なサービス通信プロトコルを選択するための、上位レベルのルーティングスキルです。要件（レイテンシ、通信方向、クライアントの種類、ペイロード形式、ブラウザー対応）を、主要な 5 つの .NET 通信プロトコル（gRPC、SignalR、SSE、JSON-RPC 2.0、REST）に対応付ける判断表を提供します。実装の詳細については、専門スキルに案内します。

対象外： HTTP クライアントファクトリのパターンとレジリエンスパイプラインについては、[skill:dotnet-http-client] と [skill:dotnet-resilience] を参照してください。ネイティブ AOT のアーキテクチャとトリミング戦略については、AOT コンパイルに関する [skill:dotnet-native-aot]、AOT を前提とした設計パターンに関する [skill:dotnet-aot-architecture]、トリミングに安全な開発に関する [skill:dotnet-trimming] を参照してください。

相互参照：gRPC の実装については [skill:dotnet-grpc]、SignalR／SSE／JSON-RPC の詳細については [skill:dotnet-realtime-communication]、REST／HTTP クライアントのパターンについては [skill:dotnet-http-client] を参照してください。サービス通信パターンのテストについては、[skill:dotnet-integration-testing] を参照してください。

---

判断表

要件に基づいて適切なプロトコルを選択するには、この表を使用してください。

要件	gRPC	SignalR	SSE	JSON-RPC 2.0	REST
通信方向	4 種類すべてのパターン	全二重	サーバーからクライアント	リクエスト／レスポンス	リクエスト／レスポンス
通信形式	Protobuf（バイナリ）	JSON または MessagePack	テキスト（JSON 行）	JSON	JSON／XML
ブラウザー対応	gRPC-Web（プロキシが必要）	はい（JS クライアント）	はい（ネイティブの EventSource）	WebSocket 経由	はい（fetch／XHR）
コントラクト	.proto スキーマ	Hub インターフェイス	慣例	JSON-RPC 仕様	OpenAPI／Swagger
レイテンシ	最低	低	低	中	中
スループット	最高	高	中程度	中程度	中程度
ストリーミング	4 種類すべてのパターン	サーバー側とクライアント側のストリーミング	サーバープッシュのみ	なし	なし（チャンク転送）
接続	HTTP/2 の持続接続	WebSocket（フォールバックあり）	HTTP/1.1 以降の持続接続	トランスポートに依存	リクエストごと
サービス間通信	最適	良好	限定的	特定用途向け	良好
AOT 対応	はい（Protobuf）	はい	はい	はい	はい（STJ ソース生成を使用）

---

判断フローチャート

Is this service-to-service (no browser)?
├── Yes → Do you need streaming?
│   ├── Yes → gRPC streaming [skill:dotnet-grpc]
│   └── No → Is it request-response?
│       ├── High throughput / binary → gRPC (unary) [skill:dotnet-grpc]
│       └── Standard CRUD / public API → REST [skill:dotnet-http-client]
└── No (browser client) → Do you need real-time?
    ├── Yes → Do you need bidirectional?
    │   ├── Yes → SignalR [skill:dotnet-realtime-communication]
    │   └── No (server push only) → SSE [skill:dotnet-realtime-communication]
    └── No → REST [skill:dotnet-http-client]

Special cases:
- LSP / tooling protocol → JSON-RPC 2.0 [skill:dotnet-realtime-communication]
- Mixed (browser + service-to-service) → REST for browser, gRPC for internal

---

プロトコルの概要

gRPC

最適な用途： サービス間通信、高スループットのストリーミング、厳密に型付けされたコントラクト。

• .proto ファイルを使ったスキーマファースト開発
• 4 種類すべてのストリーミングパターン：単項、サーバーストリーミング、クライアントストリーミング、双方向
• ペイロードを最小化し、スループットを最大化するバイナリシリアル化（Protobuf）
• クライアントとサーバーのスタブを自動生成する機能を内蔵
• ネイティブのロードバランシングとヘルスチェックプロトコルに対応

使用しない方がよい場合： ブラウザーとの直接通信（gRPC-Web プロキシが必要）、外部クライアントが利用するシンプルな CRUD API、人間が読みやすいペイロードが必要なシナリオ。

実装の詳細については、[skill:dotnet-grpc] を参照してください。

SignalR

最適な用途： ブラウザー向けのリアルタイムアプリケーション、対話型ダッシュボード、チャット、共同作業機能。

• トランスポートを自動でネゴシエーション（WebSocket → SSE → Long Polling）
• グループ管理とユーザー指定機能を内蔵
• 厳密に型付けされたインターフェイスを備える Hub 抽象化
• Redis バックプレーンまたは Azure SignalR Service によるスケーリング
• JSON と MessagePack のシリアル化に対応

使用しない方がよい場合： サーバーからクライアントへの一方向プッシュ（代わりに SSE を使用）、サービス間通信（代わりに gRPC を使用）、SignalR クライアントライブラリを組み込めないシナリオ。

SignalR のパターンと Hub の実装については、[skill:dotnet-realtime-communication] を参照してください。

Server-Sent Events（SSE）

最適な用途： シンプルなサーバーからクライアントへのプッシュ通知、ライブフィード、ステータス更新。

• .NET 10 の ASP.NET Core に TypedResults.ServerSentEvents として組み込まれています
• ブラウザー標準の EventSource API を使用するため、クライアントライブラリは不要です
• Last-Event-ID による自動再接続に対応しています
• WebSocket アップグレードをブロックする HTTP/1.1 プロキシ経由でも動作します
• リアルタイム通信の選択肢の中で最も軽量です

使用すべきでない場合： 双方向通信が必要な場合（SignalR を使用）、高スループットのバイナリストリーミングが必要な場合（gRPC を使用）、クライアントからサーバーへのメッセージが必要な場合。

SSE の実装の詳細については、[skill:dotnet-realtime-communication] を参照してください。

JSON-RPC 2.0

最適な用途： ツール用プロトコル（Language Server Protocol）、シンプルなトランスポートを介した構造化 RPC。

• トランスポートに依存しません（HTTP、WebSocket、stdio、名前付きパイプ）
• リクエスト、レスポンス、通知のセマンティクスが明確に定義されています
• StreamJsonRpc を介して Visual Studio、VS Code、.NET のツールで使用されています
• スキーマ管理を必要としない場合に、gRPC に代わる軽量な選択肢です

使用すべきでない場合： リアルタイムストリーミングが必要な場合（SignalR または gRPC を使用）、サービス間で高スループットが必要な場合（gRPC を使用）、標準的な Web API が必要な場合（REST を使用）。

JSON-RPC 2.0 のパターンについては、[skill:dotnet-realtime-communication] を参照してください。

REST（HTTP API）

最適な用途： 公開 API、標準的な CRUD 操作、幅広いクライアントとの互換性。

• あらゆる HTTP クライアントで利用できる、普遍的なクライアントサポート
• 人間が読みやすいペイロード（JSON）
• 豊富なエコシステム（OpenAPI、Swagger UI、API バージョニング）
• ステートレスなリクエスト／レスポンスモデル
• ASP.NET Core Minimal API または MVC コントローラー

使用すべきでない場合： リアルタイムのプッシュが必要な場合（SSE または SignalR を使用）、サービス間で高スループットが必要な場合（gRPC を使用）、双方向ストリーミングが必要な場合（SignalR または gRPC を使用）。

HTTP クライアントのパターン、回復性、IHttpClientFactory については、[skill:dotnet-http-client] を参照してください。

---

一般的なアーキテクチャパターン

複数のプロトコルを組み合わせた API ゲートウェイ

Browser ─── REST/SignalR ──→ API Gateway ──→ gRPC ──→ Internal Services
                                          ──→ gRPC ──→ Order Service
                                          ──→ gRPC ──→ Inventory Service

公開 API には REST を使用し、ブラウザーのリアルタイム機能には SignalR を使用します。内部のサービス間通信には、パフォーマンス向上のため gRPC を使用します。API ゲートウェイがプロトコル間の変換を行います。

SSE を使用したイベント駆動型アーキテクチャ

Internal Services ──→ Message Broker ──→ SSE Endpoint ──→ Browser Dashboard
                                     ──→ gRPC Stream  ──→ Monitoring Service

内部イベントはメッセージブローカーを通じて流れます。ブラウザーのダッシュボードは SSE 経由でイベントを受信します。他のサービスは、より高いスループットを得るために gRPC ストリーミング経由でイベントを受信します。

複数プロトコル対応サービス

単一の ASP.NET Core ホストで、gRPC と REST の両方を提供できます。

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddGrpc();
builder.Services.AddControllers();

var app = builder.Build();

// gRPC for internal service-to-service
app.MapGrpcService<OrderGrpcService>();

// REST for external clients
app.MapControllers();

// SSE for real-time browser updates
app.MapGet("/events/orders", (OrderEventService svc, CancellationToken ct) =>
    TypedResults.ServerSentEvents(svc.GetEventsAsync(ct)));

---

重要な原則

• サービス間通信には gRPC を使用する -- 最高のスループット、強い型付けのコントラクト、あらゆるストリーミングパターンを提供します
• 公開 API には REST を使用する -- 普遍的なクライアントサポート、人間が読みやすい形式、豊富なツールエコシステムが利用できます
• ブラウザーのリアルタイム通信には SignalR を使用する -- トランスポートの自動ネゴシエーションと組み込みのグループ管理に対応しています
• シンプルなサーバープッシュには SSE を使用する -- 双方向通信が不要な場合に最も軽量な選択肢です
• 適切にプロトコルを組み合わせる -- 単一の ASP.NET Core ホストで、gRPC、REST、SignalR、SSE を同時に提供できます
• クライアントの種類に応じてルーティングする -- ブラウザークライアントには REST／SignalR／SSE を、内部サービスには gRPC を使用します

AOT コンパイルパイプラインについては、[skill:dotnet-native-aot] を参照してください。また、AOT 互換の通信パターンについては、[skill:dotnet-aot-architecture] を参照してください。

---

エージェントに関する注意点

1. ブラウザー向け API では、デフォルトで gRPC を選ばないでください -- ブラウザーは HTTP/2 トレーラーをネイティブに扱えません。プロキシと gRPC-Web を使用するか、REST／SignalR／SSE を選択してください。
2. サービス間通信に SignalR を使用しないでください -- gRPC はバックエンド通信において、より高いパフォーマンス、コード生成、ストリーミングを提供します。
3. SSE で十分な場合は SignalR を追加しないでください -- サーバーからクライアントへのプッシュだけが必要であれば、SSE のほうがシンプルで、クライアントライブラリが不要なうえ、ブラウザーに自動再接続機能が組み込まれています。
4. 高スループットの内部通信に REST を使用しないでください -- JSON テキストのシリアル化とリクエストごとの接続により、gRPC のバイナリ形式と永続的な HTTP/2 接続に比べてオーバーヘッドが増加します。
5. AOT に関する考慮事項を忘れないでください -- System.Text.Json を使用する REST エンドポイントでは、AOT のためにソース生成されたコンテキストが必要です。詳しくは [skill:dotnet-serialization] を参照してください。
6. gRPC-Web を使わずに、信頼できないクライアントへ gRPC サービスを公開しないでください -- 生の gRPC には HTTP/2 が必要ですが、一部のプロキシや古いブラウザーなど、すべての環境で利用できるとは限りません。

---

参考資料

• gRPC と REST の選択
• .NET 向け gRPC
• SignalR の概要
• .NET 10 の Server-Sent Events
• Minimal API
• IHttpClientFactory のパターン