How to use base.SendAsync in F# DelegatingHandler

If you’ve ever tried to create an HttpMessageHandler in F#, you’ll have been bitten by the problem of not being able to call base.SendAsync from a callback. The solution is actually quite simple. Just wrap the HttpMessageHandler and expose the protected SendAsync method as a public or internal member:

Now, you can call CallableSendAsync in the correct sequence:

OWIN and IAppBuilder

OWIN v1.0 is now over a year old, and Microsoft is shipping its Katana implementation as part of its Visual Studio 2013 ASP.NET project templates. I think this a tremendous victory for both Microsoft and its community around open source efforts. Congratulations to all involved!

As with all such victories, however, there are a few items that could have gone a bit better. The one I’d like to focus on in this post is IAppBuilder. IAppBuilder is a simple interface meant to provide a common builder API similar to that found in Rack and Connect. Unfortunately, the IAppBuilder does not expose any members that relate to the OWIN application delegate signature. Worse, IAppBuilder is the only type contained in the owin.dll you can pull from NuGet, and several packages now reference and even require this dependency.

Why does this matter?

First, the big debate from the outset was to ensure no dependency was necessary. The original owin.dll had only the standard type aliases for the AppFunc and other delegate signatures of the pre-1.0 OWIN spec. Once we moved to the simpler AppFunc: Func<IDictionary<string, object>, Task> signature, the need for a common assembly disappeared, only it was replaced with the IAppBuilder. I don’t recall exactly when or why this happened. The major problem is that implementations like Simple.Owin, Fix, and Dyfrig, which don’t rely on IAppBuilder, are incompatible with a majority of the current “OWIN” middlewares available today. Here’s an example. You can read more of the discussion here.

Second, the lack of prescribed types in IAppBuilder members means that different implementations may not adhere to the Liskov Substitution Principal. In fact, this is currently the case in the Fix library referenced above. Further, unless you are willing to read the source for the IAppBuilder implementation you are using, you may have trouble writing a middleware adapter that works. (Note: It’s not hard to write a middleware using IAppBuilder, but the interface is insufficient to understand what is required.)

Third, the initial IAppBuilder defined in Katana presents an interesting but also undefined behavior of “falling through” to the next middleware when a 404 is returned. This is a fantastic invention that really helps achieve a terrific goal of hosting different application frameworks side-by-side in the same process. However, this isn’t part of the OWIN specification and not necessary for all applications. In addition, the choice of a 404 as a meaningful event seems a bit of a hack. In my opinion, a proper router middleware would better solve this problem.

Last, IAppBuilder blocked the (perceived or real) problem of not having defined a middleware signature for OWIN applications. For my F#-based OWIN applications, this wasn’t a problem, since F# supports easy function composition that works really well with the OWIN signature. However, many developers trying to use OWIN in C# expressed this as a problem, and a few options have appeared, most of which more or less mimic the function composition I use in F#. The current consensus appears to be that Func<AppFunc, AppFunc> is the right approach. However, that decision is awaiting a reboot of the OWIN governance model to sort out.


I want to make it clear that I think Katana is a terrific product. I’m thrilled that it has made it into the ASP.NET templates and will become the standard for writing ASP.NET applications in the not so distant future. I’m even more thrilled at how Microsoft picked up and adopted the effort and worked with the community. In fact, two Microsoft employees were responsible for writing the OWIN specification.

Nevertheless, I want to make sure Katana does not become OWIN. OWIN is meant to be an open specification with no default implementation. IAppBuilder is not specific to Katana, but Katana does possess the best example and most popular implementation. Others are free to incorporate IAppBuilder but should pay close attention to the Katana implementation to do it right.

Most importantly, know that you don’t need IAppBuilder at all to build an OWIN application or host. OWIN relates directly to the AppFunc signature and environment dictionary as defined in the specification. Build to your heart’s content.

Software Gardening, or The Fallacy of Software Architecture

I just bought and began reading Brooks’ The Mythical Man Month. I’ve only made it into the original preface, and I’ve already made what is to me a startling discovery (at least to me). When I combine the nuggets I’ve gathered from Kay with those I’ve collected from Joe Armstrong, notably that from the first Lambda Jam, I find the software analogy to architecture to be yet another myth.

Rather than architecture, which may be more accurately applied to hardware, I would rather analogize software to gardening or agriculture. Consider the recent film Man of Steel, in which Kryptonians essentially grew their weapons, buildings, etc. rather than built it in our sense of the term. Now consider the analogies to biology (Kay) and physics (Armstrong) and imagine how your projects might have turned out differently if you thought of “growing” your software. If you combine this with concepts from biology, you may think of *nix-style single-purpose programs or libraries that can be composed into more complex structures via message passing. Each is easy to test, to reason about, to compose.

This isn’t just about the programmer either. Consider the business perspective. Businesses need the agility, when possible, to respond to events as quickly as possible. Business does not need the most beautifully designed solution. Business needs a solution that will work, adapt, deliver when called upon. Consider a tree that bends in a storm is shaped by the winds and forces that beat upon it. No tree looks alike, and none looks architecturally beautiful, but they all have their own rugged beauty. Not even every piece of fruit is exactly alike another from the same tree, yet they share common properties. Isn’t this the way we see software develop and evolve?

Why do we strive so hard for architecture, when gardening will serve better?

I’ve just had this thought tonight. I’ve no idea of its validity or shortcomings. Perhaps this will open a discussion. Perhaps that discussion will begin with a link that describes this in much greater detail. Perhaps someone will point out that Agile/NOOO/Reactive Manifestos address these very points. Perhaps. I still think that perhaps we need an alternative to “architecture.”

Why F#?

I’ve often been asked to answer the questions, “Why F#? Why is it important?” I struggle to answer this question. I don’t really understand it. Part of the problem is that I try to provide an answer. These questions cannot be answered without first understanding why the questioner likes or enjoys his or her current tool chain. So, if you are curious about why someone might want to use F# and don’t want a stream of unique language features, please comment and tell me why you like what you use today. I would really like to know. I really want to be able to help you find an answer because I think F# has a lot of great benefits for everyone.

I also realized that this question is hard because I don’t have another story. I came to .NET from writing a lot of VBA, PHP, Ruby, and JavaScript. I lucked out in coming to C# when .NET 3.5 was just released. While I find C# (and VB.NET for that matter) very useful languages for building applications, I never had a love for them. I did love LINQ, so I naturally fell in love with F# because of its similarities to LINQ and terse, Python-like syntax. However, these are not reasons for choosing a language.

Ultimately, I use F# because I think about problems in such a way that F# is a natural expression of my thoughts. I have rarely released any production software written in F#, but I nearly always prototype ideas in F# before translating to C# in my projects. I find the translation to C# takes additional thought processes that get in my way when trying to solve the original problem, so this works for me. I could easily push the F# into my apps; I don’t simply because most of my clients want to maintain C# codebases. As I mentioned above, C# is a great language and very useful for building applications.

I know many people who think F# is interesting but don’t write it. I think the hurdle is simply a paradigm shift. Much like paradigm puzzles, you typically have to have someone show you or walk you through the paradigms. Once you understand it, you have a hard time trying to remember how you didn’t understand it before. For that reason, I recommend you find a local F# user group or join the Community for F# for an online meet up. Visual F# MVP Mathias Brandewinder spent his summer traveling around hosting machine learning dojos, and those really help people through the necessary paradigms. If he comes through your area, definitely join in, even if you don’t think you care about F#.

Visual C# MVP Bryan Hunter has often commented that just knowing multiple languages helps you write better code and understand how to best and most simply solve problems. He’s right. Don’t stop at F#. Try other languages outside of .NET such as Erlang, Clojure, JavaScript, and other languages and platforms unlike your own. You will never regret the lessons you learn and will usually find new, simpler ways to solve problems.

Production vs. Consumption

I recently started listening to The Limits of Power and found a striking revelation regarding the Open Source community. In an early part of the book, Bacevich recounts President Jimmy Carter’s comments on a crisis facing the nation that was ignored and culminated, at least to some degree, in our present debt crisis. He highlighted the shift from the production-oriented culture of the years before Vietnam to the consumption-oriented culture we have today.

An exception I see lies within the Open Source community. In OSS, we create, share, help, and produce quality, assisting one another in our efforts. Those in OSS spend a lot of their free time producing. I’m sure many of us consume quite a lot, as well, but we all share a spirit of productivity that at least some part of the US culture has lost.

Why? Is the IT industry so different? Is it just so new that so much opportunity abounds? I don’t think so, but I have not engaged heavily in other industries outside of plying my trade to help them. Perhaps we hold the keys to the realms of innovation?

Regardless, I celebrate OSS and its community for their ability to rise above mere consumption and produce. Well done!

I finally finished manually migrating all my blog…

I finally finished manually migrating all my blog posts back to WordPress from Octopress for pretty much the same reasons described in this excellent post. I don’t dislike static site generators, but they take quite a bit of time to configure, set up, etc., especially oft-required upgrades. I just want to get back to writing.

Apologies to those of you whose comments may get lost in the transition. I’m trying to decide whether to self-host or use If the former, your comments may magically re-appear.

Windows Azure Dev Camps

Catapult Systems, my employer, is hosting several of the upcoming Windows Azure Dev Camps. I’ll be helping out with two in Denver (April 25) and Houston (April 29). The Dev Camps will provide you with an overview of Windows Azure and an opportunity to complete several Hands-on Labs, including topics such as IaaS and Azure Mobile Services.

If you plan to attend one of these events, or if you are just curious to see what Azure can offer, sign up for a free 90-day Azure trial. If you are a student, you should also sign up for Dreamspark, which includes a free Windows Store developer license. (You need the Windows Store developer license to send push notifications to a Windows 8 client.)


'Pluralsight - Hardcore Developer Training'

Pluralsight was kind enough to provide an Annual subscription to their online developer training library of over 450 video courses, a $299 value, as a raffle prize.

'Telerik - deliver more than expected'

Telerik also provided a DevCraft Complete license for the raffle!

Please note that you must be present to receive one of the above prizes during the raffle at the end of the camp.

Web API and Dynamic Data Access

In .NET Rocks episode 855, Jeff Fritz commented on ASP.NET Web API being somewhat confusing in terms of its intended use. I don’t tend to agree, but I thought I would address one point he made in particular: that Web API is perhaps just another form of repository.

Web API is much more than a repository. And yes, it is indeed a protocol mapping layer. As Uncle Bob once noted, a web or api front end is just a mapping layer and is not really your application.

In many cases, however, one could argue that a web-api-as-repository is a fairly solid use case. OData is a great example. However, I was thinking of yet another argument I’ve heard for dynamic languages: when you are just going from web to database and back, you are not really working with types.

In that spirit, I set out to write a simple Web API using SQL and JSON with no explicit class definitions. You can see the results in this gist:

I used Dapper to simplify the data access, though I just as well could have used Massive, PetaPoco, or Simple.Data. Mostly I wanted to use SQL, so I went with Dapper.

I also model bind to a JObject, which I immediately cast to dynamic. I use an anonymous object to supply the values for the parameters in the SQL statements, casting the fields from the dynamic object to satisfy Dapper.

All in all, I kinda like this. Everything is tiny, and I can work directly with SQL, which doesn’t bother me one bit. I have a single class to manage my data access and API translation, but the ultimate goal of each method is still small: retrieve data and present it over HTTP. That violates SRP, but I don’t mind in this case. The code above is not very testable, but with an API like this I’d be more inclined to do top level testing anyway. It’s just not deep enough to require a lot of very specific, low-level testing, IMHO.

Also, note again that this is just retrieving data and pushing it up through an API. This is not rocket science. An F# type provider over SQL would give a good enough sanity check. Why bother generating a bunch of types?

Which brings up another point for another post: what would I do if I needed to add some logic to process or transform the data I retrieved?

As a future exercise, I want to see what it would take to cap this with the Web API OData extensions. That could be fun.