The .NET Stacks #5: gRPC-Web, play with C# 9, .NET Foundation, community roundup!

A rundown on gRPC-web and how to play with the C# 9 bits today!

Dave Brock
Dave Brock

This is an archive of my weekly (free!) newsletter, The .NET Stacks. Consider subscribing today to get this content right away! Subscribers don’t have to wait a week to receive the content.

On tap this week:

  • gRPC-Web for .NET
  • Try out C# 9 in LinqPad
  • Checking in on the .NET Foundation
  • Community roundup

gRPC-Web for .NET officially released this week

Microsoft announced this week that gRPC-Web for .NET is officially available, after offering it in preview in January. Before discussing what problem it solves, let’s step back with a quick primer on gRPC for the uninitiated.

gRPC is a high-performance Remote Procedure Call (RPC) framework, that is language-agnostic to boot (see the gRPC site.) If this concept is new to you, you are probably wondering one of two things (or both): (1) how does this compare to HTTP APIs, and (2) how is this different than WCF, which I have previously associated with RPC calls?

How is gRPC different than HTTP APIs?

Your typical workflow of retrieving data over the wire likely involves HTTP APIs, such as REST, with either JSON or XML. Here’s a rundown of some key differences:

  • REST APIs offer optional schema/contract support using OpenAPI/Swagger, while it is required in gRPC using a .proto definition. This file defines the contact of your gRPC services and messages. You’ve likely noticed that REST is open to a lot of … interpretation, and a contract model is a huge benefit.
  • While existing API models use regular HTTP, gRPC is designed for HTTP/2 and the performance benefits it provides, such as compression and multiplexing. While HTTP APIs can use HTTP/2, it is not designed for it by default like gRPC is.
  • gRPC offers bi-directional streaming, while HTTP APIs only offer client or server streaming.
  • gRPC offers first-class code generation support, by sharing the .proto file between client and server implementations, while HTTP APIs require additional tooling and OpenAPI support.

How is gRPC different than WCF?

So, to answer the second question, how is this different than your experience with WCF? The main use case for RPC is coding with coordination between the client and the server with the idea of a single platform without a networking dependency.

With these benefits, you can see gRPC coming in handy for microservices in need of efficiency gains and/or point-to-point real-time requirements. Where gRPC shines over WCF - in addition to what I outlined above - is not requiring the dated SOAP protocol, no .NET language dependency, and the Protobuf serialization model (an extremely efficient binary message format).

gRPC-Web for .NET: resolving browser support issue

Of course, gRPC doesn’t come without weaknesses. Human readability is an issue, as gRPC messages are encoded by default. But the real limitation is the limited browser support, if at all. The HTTP/2 support is awesome, but there isn’t a browser today that can control requests over the Web for gRPC clients. Browsers do not require HTTP/2 and aren’t mature enough to support it yet. This opens up a need to tooling that provides some gRPC browser support.

This is the need that gRPC-Web for .NET fills. gRPC-Web provides a JavaScript client that all modern browsers support, and a server proxy. The client, in turn, calls the proxy and the proxy forwards on the gRPC requests - allowing you to prevent hacking some nginx magic.

Your browser needs are likely high these days, with SPAs and Blazor, so this provides a lot of benefits. Try it out by checking out the announcement and going through the documentation, and a sample app.

Play with C# 9 today

I played around with C# 9 a little bit this week. C# 9 is slated for release with .NET 5 in November 2020. Lucky for the community, it’s a lot easier to play with the preview bits. You can now use the LinqPad tool! Just enable a checkbox in your settings, and you’re good to go. You don’t even need to install anything. Give it a shot and let me know what you think.

My main takeaway is: things are getting a lot more functional and immutable.

Checking in with the .NET Foundation

I don’t think I’m going out on a limb by saying Microsoft is going through a rough patch with the OSS community right now. The progress in Microsoft embracing OSS in the last decade, and their reputation, took a hard hit with the issues surrounding AppGet - even the biggest Microsoft fans would probably admit the communication and openness was severely lacking, and a weekend blog post skirting around things didn’t seem to help. It’s triggered several community responses like this. For those of us in the community who have backed Microsoft’s efforts, it’s a little sad.

This seems to have placed renewed focus on the .NET Foundation, showcased as an independent, non-profit organization established to support an innovative, commercially friendly, open-source ecosystem around the .NET platform. A big benefit here is community outreach, and, as Microsoft being a corporation due to shareholders, they obviously have some interest there. With board elections coming up, it’s definitely high time to make an impact (with the caveats/analysis written here).

While community folks are encouraged to participate, I’m also hoping this is Microsoft’s opportunity to become more open, honest, and communicative with the developer community.

Community roundup

We had a light week this week, but still have some good stuff below from the community.

From Microsoft

Blog posts

Podcasts/videos

New subscribers and feedback

Has this email been forwarded to you? Welcome! I’d love for you to subscribe and join the community. I promise to guard your email address with my life.

I would love to hear any feedback you have for The .NET Stacks! My goal is to make this the one-stop shop for weekly updates on developing in the .NET ecosystem, so I look forward to any feedback you can provide. You can directly reply to this email, or talk to me on Twitter as well. See you next week!

.NET Stacks