In our application at work we make use of various middleware and as we are making everything run on .Net Core the time has come to port said middleware to .Net Core. If you don’t already know ASP.Net Core has a bridge that allows you to use OWIN components in an ASP.Net Core application. This will convert the HttpContext into a OWIN environment dictionary on input and then back again on output.
Lets take an example of some middleware
public class MyMiddleware
private readonly Func<IDictionary<string, object>, Task> nextFunc;
private readonly OwinUserMiddlewareOptions options;
public OwinUserMiddleware(Func<IDictionary<string, object>, Task> nextFunc, MyMiddlewareOptions options)
this.options = options;
this.nextFunc = nextFunc;
public Task Invoke(IDictionary<string, object> environment)
//Everything is awesome
public static class MyMiddlewareExtensions
public static IAppBuilder UseMyMiddleware(this IAppBuilder app, MyMiddlewareOptions options = null)
return app.Use(typeof(MyMiddleware), options);
I’ve been interested in Hypermedia for quite a while. I bugged Darrel Miller and Glenn Block (Glenn Miller) so much so they created a YouTube show called “In The Mood for HTTP”. I bought their book “Designing Evolvable Web APIs with ASP.NET”, I am waiting for “RESTful Web Clients Enabling Reuse Through Hypermedia” by Mike Amundsen, I have written about how to return different media types with NancyFX and I am looking at going to restfest.org in Edinburgh this year, a REST conference.
Nearly 2 years ago I was employed by VQ Communications primarily because of my open source contributions to NancyFX. They had started work on a v2 of their flagship product and had begun work with Nancy and needed someone to help drive a HTTP API and architect a scaling solution as their v2 product was addressing a requirement they had for it cope with large volumes of traffic. Also of interest to me was their aim to deliver all of this as a black box appliance to customers on a VM running a custom embedded version of Linux using Postgres as the database. I would work four days a week remotely and go into the office one day a week. They already had completely remote employees and since I have been there they have taken on more. There are lots more juicy technical examples in the stack I could go into however, this is not the point of this post.
I had ported an application over to CoreCLR (that’s a whole other blog post), along with my colleague James Humphries put it in a docker image and sat back and watched it do its thing. After 6 hours of running the docker container had crashed. Ah nuts we thought, so pulled up the logs from docker and the last line looked like this
2016-02-10T20:18:31.728783069Z Killed. I’m pretty sure when you have a log entry with
Killed in it, things can’t be good. To the interweb…
I opened up the CoreFX repository on Github to search for the term
Killed and there were 2 comments but nothing that was logged out anywhere. I then Googled for docker and killed and there was an entry that someone else had spotted on their container and the feedback was essentially it was probably out of memory.
In my continued experience learning GoLang I started looking at how to best use it when dealing with HTTP. The idiomatic way to use GoLang and HTTP is to use the standard library which keeps things minimal but there are a few features missing. The first thing is a router. OOTB GoLang doesn’t have a router and the majority seem to suggest using a package called Mux from Gorilla Toolkit, a set of libraries that aims to improve the standard library from Go. After having a play with it I didn’t really warm to it so spent some time looking into the alternatives (and there are plenty!) and eventually decided upon Goji
Once I had started using Goji I then wanted to handle content negotiation in my HTTP handler. As I said earlier GoLang is minimal in its offerings OOTB and this is a good thing. Just for the record there are a few frameworks out there if you want/need and all encompassing framework such as Martini, Revel and Echo. These tend to bend the idioms of GoLang a bit and even the author of Martini blogged on this fact due to feedback from the community that although its capabilities are great they aren’t idiomatic Go.
I’ve always kept myself up to date with the latest languages arriving on the scene and I’ve spent time in the past learning Node and last year I learnt Python by doing the Omnisharp plugin for Sublime. I have recently been looking for a static language that I can transfer my C# skills too and I had narrowed it down to 3; Swift, Kotlin and GoLang. I started out with Kotlin and setting up a dev environment with IntelliJ and running the koans that Jetbrains advise you step through to pick up the language. Whilst it seemed relatively straightforward I got “noob confused” when I saw examples of Java calling into Kotlin with get/set prefixes somehow magically added to Kotlin properties. It turns out the Kotlin compiler does this for Java libraries so it can communicate with it, to me it seemed strange that I code a library in one language and the compiler then exposes these methods and properties slightly differently. Superficial as this sounds I also didn’t really like the mammoth that appears to be IntelliJ. Coming from a predominantly Visual Studio background but working with Omnisharp I wanted a lightweight editor with some refactoring, intellisense and error highlighting.