David Fowler is the ASP.NET Core Architect (and an amazing highly technical public speaker) and I’ve learned a lot from watching him code. However, what’s the best way for YOU to learn from folks like David if you can’t sit on their shoulder? Why, look at their GitHub!
Since .NET Core (and most of Microsoft) is not only open source but also developed in the open now on GitHub, we can actually watch folks in their day to day work as they commit code to projects like the C# compiler, .NET Core, and ASP.NET Core.
You can have Private repositories on GitHub, as I do, and as I’m sure David does. But GitHub is a social network for code and it’s more fun and a better learning experience when we can see each others code and read it. Read with a critical eye, but without judgment as you may not have all the context that the author does. If you went to my GitHub, https://github.com/shanselman you might be disappointed but you also may be missing the big picture. Just consider that as you Follow people and explore their code.
David is an advanced .NET developer, while, for example, I am comparatively intermediate. So I realize that not all of David’s code is FOR me. It’s a scratchpad, it’s not educational how-to workshops. However, I can get pick up cool idioms, interesting directions the tech may be going, and more importantly – prototypes and spikes. Spikes are folks testing out technical ideas. They may not be complete. In fact, they may never be complete. But some my be harbingers of things to come.
Here’s a few things I learned today.
gRPC for .NET Core
For example, at https://github.com/davidfowl/grpc-dotnet I can see David has forked (copied) gRPC for dotnet and his game is working with the gRPC folks to make a fully supported version of gRPC for production workloads with .NET Core! Here are the stated goals:
- We plan to implement a fully-managed version of gRPC for .NET that will be built on top of ASP.NET Core HTTP/2 server.
- Good integration with the rest of ASP.NET Core ecosystem
- High-performance (we plan to utilize some of the cutting edge performance features from ASP.NET Core and in .NET plaform itself)
That sounds cool! I can go learn that gRPC is a modern (google sponsored) Remote Procedure Call framework that can run anywhere. It’s used by Netflix and Square and supports basically any languaige and any environment. Nice for this microservice world we are entering and hopefully has learned from the sins of DCOM and CORBA and RMI, because I was there and it sucked.
Nothing to see here but moving to a new JSON serializer
This Web.Framework sounds fun, and I’ll be sure to take the description to heart.
You can see David and James Newton-King kicking ideas around as you explore the commit log. However, the most interesting commit IMHO is when David moves this little spike from using JSON.NET (the ubiquitous 3rd party JSON serializer) to the new emerging official System.Text.Json. Here is the commit with unified differences.
It’s a small change but it also makes me feel good about the API underneath this new JSON API that’s coming. My takeway is that it’s not as scary as I’d assumed. Looks like a Good Thing(tm).
Multi-Protocol ASP.NET Core
This looks interesting.
“The following sample shows how you can host a TCP server and HTTP server in the same ASP.NET Core application. Under the covers, it’s the same server (Kestrel) running different protocols on different ports. The ConnectionHandler is a new primitive introduced in ASP.NET Core 2.1 to support non-HTTP protocols.”
I didn’t know you could do that! Looks like this sample hasn’t changed much since it was conceived of in 2018, but then in the last month it’s been updated twice and it appears to be part of a larger, slow-moving architectural issue called Bedrock that’s moving forward.
I learned that Kestral (the ASP.NET Core web server) has a “ListenLocalhost” option on its options object!
// This shows how a custom framework could plug in an experience without using Kestrel APIs directly
services.AddFramework(new IPEndPoint(IPAddress.Loopback, 8009));
// TCP 8007
options.ListenLocalhost(8007, builder =>
// HTTP 5000
// HTTPS 5001
options.ListenLocalhost(5001, builder =>
I can see here that TCP port 8007 is customer and uses a custom ConnectionHandler which I also didn’t know existed! I can then look at the implementation of that handler and it’s cool how clean the API is. You can get the result cleanly off the Transport buffer. You’re doing low-level TCP but it doesn’t feel low level.
public class MyEchoConnectionHandler : ConnectionHandler
private readonly ILogger<MyEchoConnectionHandler> _logger;
public MyEchoConnectionHandler(ILogger<MyEchoConnectionHandler> logger)
_logger = logger;
public override async Task OnConnectedAsync(ConnectionContext connection)
_logger.LogInformation(connection.ConnectionId + " connected");
var result = await connection.Transport.Input.ReadAsync();
var buffer = result.Buffer;
foreach (var segment in buffer)
_logger.LogInformation(connection.ConnectionId + " disconnected");
Pretty slick. This just echos what is sent to that port but not only has it educated me about a thing I didn’t know about, it’s something I can mentally file away until I need it!
All of these things I learned in just 30 minutes of exploring someone’s public repository.
What kinds of code do you like to read and what have you learned from just poking around?
Sponsor: Get the latest JetBrains Rider for remote debugging via SSH, SQL injections, a new Search Everywhere popup, and improved Unity support.