WCF Alternatives (Part 4) – Summary

In the last blog post of the series on alternatives for the Windows Communication Foundation (WCF), we are going to recapitulate and compare them once again. 

Decision matrix 

CharacteristicWeb APIgRPC
Bidirectional communication Possible with restrictions 
Has to be realized with SignalR. 
Possible with restrictions 
Only stream response is supported. 
Scope of changes to existing codeSmall 
Due to the adoption of the service methods into the controllers and the generation of the client, few adjustments are required. 
Mapping is required because specific data types are prescribed in some instances: An input parameter and a return value are required.
Necessary prior knowledge Technology-specific 
Web API knowledge about the use of controllers and actions, HTTP verbs 
Particularities of gRPC, creation of the *.proto file 
Platform independence Yes 
When you use .NET Core, client and server can run on different platforms. 
When you use .NET Core, client and server can run on different platforms. 
Client and server can be created using different programming languages. 
Client and server can be created using different programming languages. 
Browser support YesOptional 
Currently possible only with third-party libraries 
Self-describing interfaces Optional 
OpenAPI is possible by integrating third-party libraries. 
You have to create the *.proto file for the description of the interface yourself. 
Payload sizeHigher 
JSON, human-readable 
Binary format 
Microsoft currently recommends Web API as a sustainable alternative. 
Microsoft currently recommends gRPC as a sustainable alternative. 
DebuggingEasily possible Possible with restrictions 
The transferred data cannot be examined due to the compression. 

Advantages and disadvantages 




  • Transmission data are readable 
  • Fewer code adjustments required for the migration 
  • More flexible design of the endpoints and calls with respect to input parameters and return values 
  • Faster transmission 
  • Typed by means of Protocol Buffers interface description 
  • Simple generation of client classes 


  • Slower transmission compared to gRPC 
  • Generation of client classes only by means of third-party libraries 
  • Typing of the interface not possible 
  • Transmission data not readable 
  • Mapping code required because no standard .NET types are used 
  • Greater effort involved in the migration due to more necessary code adjustments 


In our blog post series on WCF, we have presented both ASP.NET Core Web API and gRPC. We have seen that both options have advantages and disadvantages. 

With Web API, the interfaces can easily be used by anybody due to the content-first approach and the use of HTTP. The transmitted data are accessible and can be read at any time. 

gRPC abstracts the interface calls using the contract-first approach, making them faster and very easy to address by developers. However, the transmitted data cannot be accessed. 

In principle, migration to both options is possible, and both are recommended by Microsoft. Still, we cannot definitively recommend one of the alternatives. The decision should always be project-specific and based on various criteria such as the project scope, experience with the respective technology or the existing architecture. 

This post was written by: