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 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