Roundup #30: ProxyKit, BeeHive, Nullable Ref Types, Close Loops & Opening Minds

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

ProxyKit

A toolkit to create HTTP proxies hosted in ASP.NET Core as middleware. This allows focused code-first proxies that can be embedded in existing ASP.NET Core applications or deployed as a standalone server. Deployable anywhere ASP.NET Core is deployable such as Windows, Linux, Containers, and Serverless (with caveats).

Link: https://github.com/damianh/ProxyKit

BeeHive

Zero Friction mini-Framework for cloud Actors – currently for Windows Azure only. Implementation is very simple – if you need a complex implementation of the Actor Model, you are probably doing it wrong. It supports .NET Framework 4.5.2+ and .NET Standard 2.0+.

Link: https://github.com/aliostad/BeeHive

C# 8 Nullable Reference Types

C# 8.0 will introduce a new groundbreaking feature called Nullable reference types, this feature will change the way we currently develop our software in C# by making, you guessed it, reference types nullable.

Link: https://www.marcbruins.nl/C-8-Nullable-reference-types

Close Loops & Opening Minds: How to Take Control of Systems, Big & Small

Whether it’s distributing configurations and customer settings, launching instances, or responding to surges in load, having a great control plane is key to the success of any system or service. Come hear about the techniques we use to build stable and scalable control planes at Amazon. We dive deep into the designs that power the most reliable systems at AWS. We share hard-earned operational lessons and explain academic control theory in easy-to-apply patterns and principles that are immediately useful in your own designs.

Link: https://www.youtube.com/watch?v=O8xLxNje30M

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Practical ASP.NET Core SignalR: Server Hubs

Practical ASP.NET Core SignalR

In this section, I’m going to extend my existing ASP.NET Core application to explore more of what SignalR Server Hubs have to offer.

This blog post is apart of a course that is a complete step-by-setup guide on how to build real-time web applications using ASP.NET Core SignalR. By the end of this course, you’ll be able to build real-world, scalable, production applications using the tools and techniques provided in this course.

If you haven’t already, check out the prior sections of this course.

  1. Course Overview
  2. ASP.NET Core SignalR Overview
  3. Basics

SignalR Server Hubs

A SignalR Server Hub is a primary point at which all communication between client and server occur.  You define methods in a hub that can be called by the client. And in the client code, we can define methods that our hub can call.

We can define methods on our hub that can communicate directly with the specific client (caller) who is making the call to our hub. I’m going to add a new method to our existing MessageHub called SendMessageToCaller

Clients

We can also send data to specific clients. To do so, we simply need to know the ConnectionId of the client we want to send data to.

I’ll add a new method called SendMessageToUser which will accept a connectionId as the first parameter which we will use.

In order for our clients to know about each other, I’m going to override two methods on our Hub. OnConnectedAsync and OnDisconnectedAsync. I’ll use these methods to let all connected clients know when a new client as connected or disconnected. This way the clients/browser can keep track of the ConnectionID’s available, in order to send to specific clients.

Groups

Lastly, we can also define Groups of connections. This giving us the ability to send data to specific groups. This is often useful for multi-tenant applications.

I’ll create two new methods, one method JoinGroup which will be used for our clients to join a specific group. SendMessageToGroup will be used to send data to the specific clients that have already called JoinGroup.

Client

First, I’ll update my Razor Page to contain a new select list to specify who we want to send the message to, All, Myself or PrivateGroup. I’ll also add a button that we will wire-up to call our JoinGroup on our Hub.

Now we will wire up our new UI by adding in SignalR client handlers for UserConnected, UserDisconnected events. I’ll also add UI for the Join button click as well as using the select list to determine which methodto invoke on our Hub.

Get The Course!

You’ve got several options:

  1. Check out my Practical ASP.NET Core SignalR playlist on my CodeOpinion YouTube channel.
  2. Access the full course now by enrolling for free on Teachable.
  3. Follow along with the blog post series here on CodeOpinion.com
    1. Course Overview
    2. ASP.NET Core SignalR Overview
    3. Basics
    4. Server Hubs
    5. HubContext
    6. Authorization
    7. Scaling with Redis
    8. Scaling with Azure SignalR Service

Source Code

All of the source code for this blog post and this course is available the Practical.AspNetCore.SignalR repo on GitHub.

Upgrading Nancy to Version 2

Upgrading NancyAlthough there isn’t an “official” of Nancy v2 release yet, there’ is 2.0.0-clinteastwood that’s been in NuGet since Dec 12th, 2106 and as of this post has almost 200k downloads.  The primary reason for upgrading Nancy to v2 is because of its support for NETStandard 1.6 which means you can move to .NET Core. In this demo, I’m going to be using ASP.NET Core with Owin and Nancy 2.0.0-clinteastwood to add back in the existing routing functionality that is a breaking change in v2.

Breaking Changes

There’s an upgrade notes page on the Nancy Wiki, which lists some of the breaking changes.  Although there aren’t many, and I suspect most of the work for the 2.0 release was for targeting NETStandard. The most glaring breaking change is with routing.

Routing

Routing syntax has changed to Get("/", args => "Hello World");, these can be made async by adding the async/await keywords. For more info see the PR where it all changed https://github.com/NancyFx/Nancy/pull/2441
This is really significant.   In Nancy V1, you specified routes using the following:
If you have a large web app with many routes and modules, although a trivial change, this could take some significant time.

NancyV1Module

I decided to try to create a new module that would add back the existing routing behavior by calling the new underlying methods in the NancyModule.  This would allow me to simply change all my existing modules to extend this new class rather than the new Module in Nancy v2.

Usage

This then adds back in all the existing routing.  Just simply extend NancyV1Module instead of NancyModule.

Upgrading Nancy

I’ve created a console application with the source available on GitHub. Have you ran into any significant issues when upgrading Nancy to v2?  Please let me know on Twitter or in the comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.