grpc

# gRPC for .NET ## Trigger On - building backend-to-backend RPC services or clients - adding protobuf contracts, streaming calls, or interceptors - deciding between gRPC, HTTP APIs, and SignalR - optimizing gRPC performance, deadlines, cancellation, or connection reuse - integrating service-to-service communication in microservices ## Do Not Use For - public browser-first APIs unless gRPC-Web limitations are explicitly acceptable - SignalR hub design, realtime UI fan-out, or websocket-style client collaboration - generic ASP.NET Core minimal APIs or REST controllers with no protobuf/RPC requirement - non-.NET gRPC work unless the user asks for cross-stack contract guidance ## Load References - [references/patterns.md](references/patterns.md) for proto design, streaming implementations, interceptors, health checks, load balancing, and client factory setup. - [references/anti-patterns.md](references/anti-patterns.md) for common channel, deadline, streaming, message-size, and exception-handling mistakes. ## Workflow 1. Validate the architecture fit before touching code. - prefer gRPC for backend RPC, strong contracts, low-latency calls, or streaming - prefer REST or minimal APIs for broad browser compatibility and loosely coupled public APIs - prefer SignalR for browser/client realtime fan-out and UI collaboration 2. Treat `.proto` files as the source of truth. - keep package names, `csharp_namespace`, service names, and versioning deliberate - reserve rem...