MVC Controllers, Minimal APIs or gRPC?

With .NET 7 release just around the corner we have been looking at significant new features and deciding whether to implement them.

A lot of excitement has been circulating recently about Minimal APIs and gRPCs.

We needed to decide whether to re-implement the MVC Controllers that we currently use in our existing trellsipark OpenAPI interface as part of our .NET 7 adoption.

First – MVC Controllers are a mature component of the .NET eco-structure, and it doesn’t look like they are going away anytime soon. They perform well and come with a bunch of useful features which we do use in our APIs.

Switch to gRPC?

This is the most radical alternative implementation. The idea is to represent the interface with a .proto file and use the Visual Studio tooling to create Client and Server-side code that will handle the communication.

For trellispark, this option requires extensive modification to the communication between the Services in our WASM Clients and the OpenAPI endpoints.

The strict contract definition in gRPC would not have helped us as our JSON API payloads contain a number of string elements holding XML fragments. In fact, it is likely that this would have caused us significant issues in implementation that would have made this gRPC feature an issue and not a benefit.

The fact that gRPC messages in transit are not human readable was determined to be an advantage from a security perspective.

A key advantage is that the gRPC payloads are serialised to protobuf for transport resulting in smaller payloads. trellsipark payloads can sometimes contain large XML elements (in the KB range) but in practice they don’t seem to be impacting performance in our current implementation. A take away from this research was an action to consider compressing XML strings and base64 encoding if this changes in the future.

It was noted that HTTP/2 is not exclusive to the gRPC and that HTTP APIs with JSON payloads can also benefit from using HTTP/2 where available.

A key weakness of gRPC is limited browser support and we were not convinced it would work well in all possible trellispark deployment scenarios (WASM and MAUI Hybrids).

On balance, we ruled out a migration to gRPC. Too much work, too much risk, and lacked clear benefits.

Switch to Minimal API?

This is a fairly straight forward re-implementation at first sight.

Best URL to learn about Minimal APIs in .NET 7: Minimal APIs overview | Microsoft Learn

Minimal APIs are a relatively recent (compared to MVC) lightweight implementation of JSON Web API endpoints that come with minimal functionality out of box. The current excitement surrounding Minimal APIs and the available Microsoft documentation suggests that this will be a significant focus for future development and performance enhancements.

The documentation and a range of YouTube videos suggest that the performance of a bare bones Minimal API is significantly faster than using the standard out-of-box MVC Controller. However, the performance demonstrations we researched were unrealistic as they only made simple calls to return string payloads without any complex workloads or reliance on back-end database servers.

The basic idea is that you only configure your Minimal APIs with just the features that your API requires. You can add the same types of middleware to your Minimal API that are also used in MVC Controller APIs. The question we wanted to answer was: after we added back in all of the required features in our MVC Controllers, would the Minimal APIs actually be any faster?

Our thought process was that if Microsoft was focusing development on improving the performance of Minimal APIs, then wouldn’t that be mostly in the middleware? The Microsoft documentation implies that the available middleware is shared with the MVC Controllers, so wouldn’t the performance improvements be felt there as well?

In the end, we concluded that the question comes down to raw performance on the request/response pipeline. They are both using the same JSON payloads, both going through IIS (in our implementation), and need a range of standard MVC Controller middleware. We could probably configure a slightly faster pipeline using Minimal APIs, but who would actually notice?

When we reviewed the last 30 days API performance for our APIs on Application Insights, the elapsed time to process a complete API request is around 5 +/- 2ms. All our APIs are complex endpoints that make use of an Azure SQL database for multiple calls to distinct T-SQL Stored Procedures. Optimally configuring the API request/response pipeline using Minimal APIs might shave off a few hundredths of a millisecond at best – but at this scale, the benefit would be “lost in the noise”.

Our conclusion was that the benefits seem to be minimal at this time and that the Minimal API framework is still in early development. Future performance enhancements are likely to be reflected in MVC Controllers, so at least for now, we will stay with MVC Controllers. This is a technology to watch in the future especially if MVC Controllers are eventually deprecated.