Adding gRPC to Existing ASP.NET Core MVC APIs Without Rewriting Controllers

An existing ASP.NET Core MVC API already contains business logic, authorization rules, filters, and DTOs. Adding gRPC raises a practical question: how much of that application can we reuse, and where do the two protocols require different contracts?
In this session, we’ll explore how to expose compatible ASP.NET Core MVC controller actions as native unary gRPC methods while keeping their REST endpoints available. Starting with a small MVC API, we’ll follow an action from discovery through a protobuf contract to a call from a standard gRPC client.
The focus is on the engineering decisions behind that bridge: invoking controllers through dependency injection, checking how MVC authorization and filters behave, and keeping protobuf field numbers stable as DTOs evolve. We’ll also examine contract manifests and use a deliberate contract change to explain what can break for existing clients.
Finally, we’ll identify the boundaries of the approach, including streaming, custom model binders, and responses that depend on MVC formatters. We’ll compare this starting point with contract-first gRPC and JSON transcoding so you can decide which approach fits an existing application.
You’ll leave with a concrete integration pattern and a checklist for evaluating reuse, compatibility, and testing before exposing an MVC API over gRPC.