gRPC ASP.NET Core — Silent Leak from Missing Deadline

Microservices are eating the enterprise, and with that comes a brutal problem: how do dozens of services talk to each other efficiently, reliably, and without turning into a web of hand-rolled HTTP clients? REST and JSON got us far, but they carry hidden costs — verbose payloads, no enforced contracts, no built-in streaming, and type information that evaporates at the boundary. At scale, these costs compound. A single inter-service call that serializes a 50-field object as JSON a million times a day quietly burns CPU, bandwidth, and developer sanity.

gRPC was built by Google to solve exactly this. It puts a strongly-typed contract — the .proto file — at the center of every conversation, uses Protocol Buffers for binary serialization that's 3–10x smaller than equivalent JSON, and rides HTTP/2 so you get multiplexing, header compression, and real bidirectional streaming for free. ASP.NET Core embraced gRPC as a first-class citizen starting with .NET 3.0, meaning you get Kestrel's raw performance, the full DI ecosystem, middleware, and health checks all wired up without ceremony.

By the end of this article you'll know how Protobuf encodes data on the wire, how to build all four gRPC communication patterns in ASP.NET Core (unary, server-streaming, client-streaming, and bidirectional), how to write interceptors that behave like middleware, and exactly which production traps — deadlines, load balancing, browser compatibility — will catch you off-guard if you don't know they're there.

What is gRPC and Why ASP.NET Core?

gRPC is a high-performance RPC framework by Google that uses Protocol Buffers for serialization and HTTP/2 for transport. ASP.NET Core provides built-in support via the Grpc.AspNetCore package, which integrates with Kestrel's HTTP/2 pipeline. Unlike REST, where you craft endpoints manually, gRPC generates client and server stubs from a shared .proto contract. This means both sides speak the same typed language — no guessing field names, no parsing JSON strings for every call. ASP.NET Core adds dependency injection, logging, and middleware (interceptors) out of the box, making it a natural home for gRPC in the .NET ecosystem.

syntax = "proto3";

option csharp_namespace = "io.thecodeforge.Greet";

package greet;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

Protobuf Wire Format and Code Generation

Protocol Buffers (Protobuf) are the serialization engine of gRPC. Messages are defined in .proto files, then compiled into C# classes by the protoc compiler or the Grpc.Tools NuGet package. The on-the-wire format is a compact binary representation: field tags, wire types, and values. Varint encoding keeps small integers small, and fields can be omitted entirely if not set. This results in payloads often 3–10x smaller than equivalent JSON.

The code generator produces both the message classes (with Equals/GetHashCode overrides, ToString, and Clone) and the service stubs (client proxy and server base). In ASP.NET Core, you reference the generated files from your .csproj and implement the server base class. The generated client handles serialization, HTTP/2 framing, and connection pooling.

using Grpc.Core;
using io.thecodeforge.Greet;

namespace io.thecodeforge.Services;

public class GreeterService : Greeter.GreeterBase
{
    private readonly ILogger<GreeterService> _logger;
    public GreeterService(ILogger<GreeterService> logger) => _logger = logger;

    public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
    {\n        _logger.LogInformation(\"Saying hello to {Name}\", request.Name);\n        return Task.FromResult(new HelloReply\n        {\n            Message = $\"Hello {request.Name}\"\n        });\n    }\n}"
      }

Building All Four gRPC Streaming Patterns in ASP.NET Core

gRPC defines four RPC types: unary (one request, one response), server-streaming (one request, multiple responses), client-streaming (multiple requests, one response), and bidirectional streaming (multiple requests, multiple responses). ASP.NET Core supports all four with simple async method signatures.

Unary is the most common; streaming is where gRPC shines for real-time data. Server-streaming is ideal for watch operations (e.g., monitoring stream). Client-streaming is useful for uploads or batch processing. Bidirectional streaming enables chat, live collaboration, or game state sync.

Here's a server-streaming example: a service that returns stock price updates.

using Grpc.Core;
using io.thecodeforge.Stock;

namespace io.thecodeforge.Services;

public class StockService : Stock.StockBase
{
    public override async Task StreamStockPrices(
        StockRequest request,
        IServerStreamWriter<StockPrice> responseStream,
        ServerCallContext context)
    {\n        while (!context.CancellationToken.IsCancellationRequested)\n        {\n            var price = await GetCurrentPriceAsync(request.Symbol);\n            await responseStream.WriteAsync(price);\n            await Task.Delay(1000, context.CancellationToken);\n        }
    }

    private async Task<StockPrice> GetCurrentPriceAsync(string symbol)
    {
        // Simulate price fetch
        await Task.Delay(100);
        return new StockPrice
        {
            Symbol = symbol,
            Price = Random.Shared.NextDouble() * 1000,
            Timestamp = Google.Protobuf.WellKnownTypes.Timestamp.FromDateTime(DateTime.UtcNow)
        };
    }
}

Interceptors — gRPC Middleware in ASP.NET Core

Interceptors are the gRPC analogue of ASP.NET Core middleware. They run before and after each RPC call on both the server and client side. Use them for cross-cutting concerns like logging, authentication, rate limiting, and metrics.

Server-side interceptors implement Interceptor and override UnaryServerHandler, ServerStreamingServerHandler, etc. Client-side interceptors work similarly. They are registered via DI and can be ordered.

A common pattern is a server interceptor that validates the JWT token from the metadata and sets a user identity for the handler.

using Grpc.Core;
using Grpc.Core.Interceptors;

namespace io.thecodeforge.Interceptors;

public class AuthInterceptor : Interceptor
{
    private readonly ILogger<AuthInterceptor> _logger;

    public AuthInterceptor(ILogger<AuthInterceptor> logger) => _logger = logger;

    public override async Task<TResponse> UnaryServerHandler<TRequest, TResponse>(\n        TRequest request,\n        ServerCallContext context,\n        UnaryServerMethod<TRequest, TResponse> continuation)
    {
        var authHeader = context.RequestHeaders.GetValue("authorization");
        if (string.IsNullOrEmpty(authHeader))
        {
            _logger.LogWarning("Missing authorization header");
            throw new RpcException(new Status(StatusCode.Unauthenticated, "Missing auth token"));
        }

        // Validate token — omitted for brevity
        // var user = await ValidateTokenAsync(authHeader);
        // context.UserState["User"] = user;

        return await continuation(request, context);
    }
}

Production Gotchas: Deadlines, Load Balancing, and Browser Compatibility

gRPC relies on HTTP/2, which brings several production pitfalls.

1. Deadlines: gRPC calls can hang forever if no deadline is set. Always set a client-side deadline (Deadline) and respect CancellationToken on the server.
2. Load Balancing: L7 load balancers need to support HTTP/2 connection multiplexing. Many legacy balancers (e.g., AWS Classic LB) don't — they break gRPC. Use Envoy, Nginx with HTTP/2, or a gRPC-aware balancer. Also, gRPC connections are typically long-lived; round-robin load balancing across connections may not evenly distribute requests. Use client-side load balancing or a service mesh.
3. Browser Compatibility: gRPC-Web or gRPC JSON transcoding needed for browser clients. ASP.NET Core supports gRPC-Web via app.UseGrpcWeb().
4. Health Checks: Built-in gRPC health check protocol (grpc.health.v1.Health) enables liveness and readiness probes without custom endpoints.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddGrpc();
builder.Services.AddGrpcHealthChecks();

var app = builder.Build();

app.MapGrpcHealthChecksService();

// Enable gRPC-Web for browser clients
app.UseGrpcWeb(new GrpcWebOptions { DefaultEnabled = true });

app.MapGrpcService<io.thecodeforge.Services.GreeterService>();

app.Run();

gRPC Client Setup: Don't Let NuGet Eat Your Weekend

You've built the server. Now the client needs to talk to it without dying at 2 AM. The official templates hide the wiring, but production doesn't forgive magic. You need the right packages, the right proto reference, and zero assumptions about network topology. The client is where most timeouts and serialization bugs surface. Here's the blueprint for a console client that won't betray you. Start with Grpc.Net.Client for the core, Google.Protobuf for message deserialization, and Grpc.Tools for code generation. Never use the full framework unless you need gRPC-Web or special auth. The proto file must be copied and linked — not just referenced — or your builds will fail silently when the contract changes. Set the channel address from configuration, not a string literal. In production, that address changes faster than your sprint goals.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Grpc.Net.Client" Version="2.62.0" />
    <PackageReference Include="Google.Protobuf" Version="3.27.0" />
    <PackageReference Include="Grpc.Tools" Version="2.62.0">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>

  <ItemGroup>
    <Protobuf Include="Protos\greet.proto" GrpcServices="Client" />
  </ItemGroup>

</Project>

The Greeter Client: One Call, One Shot, No Second Chances

Now you have the packages. Now you write the code that actually calls the service. This is where theory meets the debugger. The Greeter service expects a HelloRequest with a name. Your client sends it and expects a HelloReply. Straightforward? Yes, until the channel is dead or the deadline expired. Create a GrpcChannel pointing at your server's HTTPS endpoint. Use insecure only in dev, and never on a shared network. Build the GreeterClient from that channel. Wrap the call in a try-catch for RpcException. gRPC throws on network failures, not nulls. The async call awaits the response. A successful reply returns the Message field. Anything else is a failure you log, then fix. Never swallow exceptions in production — your on-call phone will ring.

// io.thecodeforge
using Grpc.Net.Client;
using GrpcGreeterClient;

var channel = GrpcChannel.ForAddress("https://localhost:7042");
var client = new Greeter.GreeterClient(channel);

try
{
    var reply = await client.SayHelloAsync(
        new HelloRequest { Name = "Production" });
    Console.WriteLine($"Greeting: {reply.Message}");
}
catch (RpcException ex)
{
    Console.Error.WriteLine($"gRPC error {ex.StatusCode}: {ex.Message}");
    // Alert: PagerDuty goes here in real life
}

Console.WriteLine("Press any key to exit...");
Console.ReadKey();