WCF to gRPC: What Should You Keep in Mind?
Are you considering moving from WCF to gRPC? There are many reasons to do so. Whether you just want the performance benefits or need a WCF stand-in for .NET Core and .NET 5, gRPC will provide a faster, less taxing framework than WCF.
But that doesn’t mean migrating is an easy choice. Outside of the effort required to rewrite the application, a few details may complicate the transition process or force you to reconsider how/when you migrate. Below, we’ll briefly discuss three different aspects of gRPC you should consider when moving from WCF to gRPC.
1. With gRPC, HTTP 2 is Your Only “Transport”
While there are ways gRPC has more flexibility than WCF, it lacks options when it comes to “transports.” With WCF, you create bindings to configure your endpoints. Bindings allow you to pick a transport mechanism such as HTTP, named pipes, and NetTCP. With gRPC, you get one equivalent to a transport: HTTP 2.
-
HTTP 2 is a large part of why gRPC performs so well. HTTP 2 uses binary to transmit messages instead of relying on a human-readable format like SOAP in HTTP 1.1. This allows for less time processing requests and therefore increases the speed per request. In WCF terms, HTTP 2 has equal or better performance to WCF’s NetTCP binding, but with cross-platform support. If you’re going to only have one transport, at least it’s a fast one.
-
There is a potential financial advantage you get due to HTTP 2. The improved performance HTTP 2 provides means in many cases, you can run the same service with the same performance but on less expensive hardware. If you own the hardware you host the application on, that means a reduced cost for future upgrades. If you rent server space to host your application, that may mean you can go down a performance tier and still have your application perform with similar efficiency. For those who are happy with their application’s current performance, gRPC may still be worth the migration for the savings.
Even if gRPC has fewer options for the transport mechanism, it has one excellent option in HTTP 2. But if you use other technologies that do not support HTTP 2, moving to gRPC may not be possible. You will need to look into finding a replacement.
2. gRPC Does Not Support Integrated Windows Authentication
Integrated Windows Authentication is a supported authentication mode for IIS and NetTCP services on Windows. But, the protocol does not work with HTTP 2. To switch to gRPC, you would need to switch to a different authentication, such as one of the referenced authentication modes in this portion of the Microsoft documentation. This change will be more difficult to justify for some organizations than others. Honestly, it’s a potential reason you may want to stick with WCF.
That’s not to say gRPC isn’t secure. gRPC supports encryption with SSL/TLS (required for communication with a browser-based service). It also has its own set of Call-level or Channel-level authentications you can use throughout .NET. But for those that have an internal WCF application, it is worth checking if you use Integrated Windows Authentication and deciding whether this is a sticking point for your organization or not.
3. gRPC Can Enable a Microservices Architecture
WCF was not designed to support a microservices architecture, and it doesn’t. True microservices are not possible with WCF because of the Windows requirement. A microservices architecture’s whole point is to allow individual teams to use the best platform and framework viable for a hyper-specific service. An OS requirement does not fit that mold.
But gRPC was designed to enable microservices as one of its primary goals. That’s part of why the cross-platform support and performance are so good; they have to be. A sluggish framework that only worked on Windows or Linux wouldn’t give teams creating microservices much wiggle room to decide how the service is actually made.
Despite the design differences, it doesn’t make gRPC a lousy fit. WCF didn’t need the flexibility of gRPC, but it doesn’t mean the applications making the switch can’t benefit from it. Your application may benefit by enabling it to communicate across additional platforms. And down the road, you can consider adopting a microservices architecture for yourself.
What About the Time Spent Rewriting?
Rewriting any application is a huge undertaking, and the time that requires is an obvious factor to consider when discussing the move from WCF to gRPC. That’s where our tool Visual ReCode can become helpful. Visual ReCode is a Visual Studio extension that rewrites your WCF services to gRPC for .NET Core and .NET 5. You can learn more about Visual ReCode in the links below.
