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();

Frequently Asked Questions