The .NET Stacks #48: ⚡ Sockets. Sockets everywhere.

#dotnet #csharp #azure

NOTE: This is the web version of my weekly newsletter, which was released on May 03, 2021. To get the issues right away, subscribe at dotnetstacks.com or at the bottom of this post.

Happy Monday! Here’s what we’re talking about this week:

One big thing : Microsoft announces Azure Web PubSub
The little thing : Logging middleware coming, new try-convert release, and EF perf improvements
Last week in the .NET world

Microsoft announces Azure Web PubSub

Last week, Microsoft rolled out a public preview of Azure Web PubSub, a managed service for building real-time web applications using web sockets. According to Microsoft, Azure Web PubSub enables you to use WebSockets and the publish-subscribe pattern to build real-time web applications easily. This service helps you manage a lot of concurrent WebSocket connections for data-intensive apps. In these scenarios, implementing at scale is a challenge. It lowers the barrier to entry: all you need is a WebSocket client and an HTTP client. Think about simple messaging patterns with a lot of connections. What’s nice here is that you can use any addressable endpoint with Azure Web PubSub. Azure Web PubSub integrates with Azure Functions natively, with the capability to build serverless apps with WebSockets and C#, Python, Java, or JavaScript. You use anything that can connect from a web socket, even desktop apps.

Here’s what’s on our minds: how is this different than the SignalR service? While both services are internally built from similar tech, the most significant difference is that there’s no client or protocol requirement with Azure Web PubSub. You can bring your WebSocket library if you wish. And also, unlike SignalR, you’re just working with WebSockets here—you won’t see automatic reconnect scenarios, long polling, and whatnot.

What does this mean for SignalR? Nothing. As a matter of fact, according to David Fowler, here’s when you’d want to stick with SignalR:

You’re a .NET-specialized dev shop and have SignalR client libraries and expertise
You need fallbacks other than WebSockets, like long polling or server-sent events
The existing SignalR client platforms work for you
You don’t want to manage a custom protocol and need more complex patterns (and want SignalR to manage it for you)
You don’t want to manage the reconnect logic yourself

Anthony Chu sums it up pretty well when he says:

Personally, I would use SignalR unless you need to support clients that don’t have a supported SignalR library. You could write the code connect/reconnect/messaging code yourself but SignalR does it all for you with a nice API.

Speaking of WebSockets, WebSocket compression is coming to .NET 6 thanks to a community contribution from Ivan Zlatanov. It’s an opt-in feature, and it looks like Blazor won’t be using it for now. Security problems can arise when server messages contain payloads from users and, as a result, shouldn’t be compressed.

The little things: Logging middleware coming, new try-convert release, and EF perf improvements

As we discussed last week, .NET 6 Preview 4 will be a big release with lightweight APIs and AOT on the list (if not more). For Preview 5, ASP.NET Core will be introducing logging middleware. Logging request and response information isn’t the most fun, so middleware will do a lot of the heavy lifting for you (and you can extend it if needed). By default, the logging middleware won’t log response bodies, but that should be a configuration detail. This is a problem every ASP.NET developer has to deal with, so it’s nice to see it being generalized.

A new try-convert release was shipped last week. This release includes enhancements for VB.NET Windows Forms conversions. The new, snazzy .NET Upgrade Assistant relies on this try-convert tool, which means VB.NET WinForms support has arrived with the Upgrade Assistant. That’s all I’m going to say about that because the more you talk about VB.NET, the more someone calls you an expert.

I missed this last week, but the Entity Framework team announced the results from new TechEmpower benchmarks. It looks like EF Core 6 is 33% faster than EF Core 5, and EF Core is also almost 94% of the Dapper performance.