Working with Non-Compliant OWIN Middleware

Microsoft.Owin, a.k.a. Katana, provides a number of very useful abstractions for working with OWIN. These types are optional but greatly ease the construction of applications and middleware, especially security middleware. The Katana team did a great job of ensuring their implementations work well with Microsoft.Owin as well as the standard OWIN MidFunc described below. However, not all third-party middleware implementations followed the conventions set forth in the Katana team’s implementations. To be fair, OWIN only standardized the middleware signature earlier this year, and the spec is still a work in progress.

In C#, that’s:

At some point in the last year, I discovered the HttpMessageHandlerAdapter was not, in fact, OWIN compliant. I learned from the Web API team they would not be able to fix the problem without introducing breaking changes, so I came up with an adapter that should work with most implementations based on OwinMiddleware that didn’t expose the OWIN MidFunc.

The solution is rather simple, and the Katana source code provides one of the necessary pieces in its AppFuncTransition class. The adapter wraps the OwinMiddleware-based implementation and exposes the OWIN MidFunc signature. After creating the adapter specifically for HttpMessageHandlerAdapter, I created a generic version I think should work for any OwinMiddleware. See below:

Here’s the solution in C#, as well:

I hope that helps someone else. If there’s interest, I can package this up and place it on NuGet, though it seems a lot of effort for something so small. The source code above is released under the Apache 2 license, in keeping with the use of AppFuncTransition used above from the Katana source.

Texas UIL Computer Science Competition Should Use JavaScript

As a former competitor in Texas’ UIL Computer Science competition, I thought I would check in and see how it had evolved. I have a desire to, at some point, try to spend some volunteer time at a local high school working with Computer Science students, and I thought this might give me a view into what I might expect to find.

I admit I was quite disappointed to find Java the introductory language of choice. This is, after all, the state where Dijkstra presided, in Austin no less. How could Texas have gone so wrong? I knew Texas adopted C++ right after I graduated (from Pascal). I had no idea it had switched to Java.

What’s wrong with Java? Well, let’s start with complexity. Java is supposedly an OOP language. Alan Kay’s message passing and atoms definition of OOP makes sense. It’s the same argument Joe Armstrong uses to describe the Actor model used in Erlang and based on physics. Java, and its kind that includes C++ and C#, follows a very different form I tend to call “Class-Oriented.” Class-oriented programming uses things like inheritance and design patterns to solve problems that are created by using class-oriented programming. An outside observer should be able to see this clearly in the number of books published on the topic, especially when one takes the time to investigate the contents and learn that most contradict others.

For years, Rice and MIT taught their first-year computer science students LISP. They’ve now, sadly, departed from that tradition. However, I strongly believe teaching at such a raw, powerful level would both provide immediate job candidacy and a firmer grip on the actual mechanics of computing, rather than an understanding of OOP, which is much less useful than advertised. Those who understand LISP tend to understand algorithms and abstractions better and have a much closer appreciation for what languages do once they’ve been parsed. Isn’t this what our education system should be encouraging?

Okay, let’s say LISP is out. What about Python? It’s pretty popular and has supplanted LISP in both Rice and MIT (I think). I would actually suggest JavaScript, myself. Sure, it has warts, but 1) it’s the most ubiquitous language in the world, 2) can be written and run in any browser, 3) provides immediate feedback, and 4) would offer every student the possibility of getting a part- or even full-time job during summer months or upon graduation.

If the selection of Java is related to industry use, which I can only suppose is the case, then JavaScript should be the top choice. It has so many interesting facets and can be used to teach most if not all styles of programming. It even has roots in Scheme and Self, one the LISP and the other the OOP.

Please, at least consider it.

P.S. If a dynamic language, or JavaScript specifically, doesn’t satisfy, what about a typed, multi-paradigm language like F# or OCaml?

Bundling and Minification with Web Essentials

Pta.Build.WebEssentialsBundleTask A few months ago, the Tachyus web application used a C# + F# web application approach to separate the front-end HTML, CSS, and JavaScript from the back-end F# ASP.NET Web API application. With this configuration, we introduced Web Essentials to bundle and minify our CSS and JavaScript at build time within Visual Studio. To simplify deployments and better group related and shared code, we decided to merge the back-end with another Web API application, which used the F# MVC 5 project template. We originally tried using CORS, which worked great in almost every environment. Unfortunately, the one environment in which we ran into trouble was our staging/production environment. Since we are building an internal-only API, we haven’t spent the extra effort to make our APIs evolvable; therefore, we decided to just merge all three projects together into the F# web project. This worked rather well, except for Web Essentials. We abandoned Web Essentials, as well as any form of bundling or minification at that time.

Fast forward to last week: we again split the front-end application out into a separate, C# project. We did this for several reasons:

  • We ran into trouble trying to remote debug the F# web project
  • The project had grown to the point that it was quite large, and it made sense to separate the two for maintenance
  • It’s common even in other languages to separate the front-end into a separate folder or project as different teams are often responsible for the different apps, which is not quite our case but close
  • We wanted to clean up our Angular code so that we had less Angular spread throughout and more standard JavaScript; for this we wanted to use bundling again

I was able to add Web Essentials back into the solution since we were again using a C# project. However, this had its own challenges, specifically in the form of communication to the rest of the team that they would need to install Web Essentials in order for their updates to take effect.

Fortunately, my colleague Anton Tayanovskyy recently found and pointed me toward the WebEssentialsBundleTask, which is a MSBuild task that will run the Web Essentials transformations at runtime depending on the build configuration, i.e. Debug or Release. This tool provides explicit script references for Debug builds and a bundled (and minified, if desired) version for Release builds. It seems to only require the presence of a Web Essentials-style .bundle file to work, so I would expect this to work equally well with a F#-only solution, though I have yet to try that. The WebEssentialsBundleTask has its own issues, though. It will modify your index.html file whenever it runs, so you must make sure to revert changes you don’t want to keep. We rarely change our index.html file since nearly everything is built in the form of Angular directives or templates. Nevertheless, you should consider the cost to your own project.

You may wonder why we didn’t just build a simple FAKE task. After all, whitespace¬†in JavaScript is relatively meaningless, so a very simple concat + remove could probably get the job done, especially since we use ; where applicable. I definitely considered this option, as well as creating new FAKE tasks built around a node.exe using tools like grunt.js or gulp.js. In the end, these all seemed like overkill with the availability of Web Essentials, at least until we had evaluated whether WE would work for our purposes. We are still evaluating. What are you using? Did you find this helpful?

F# Web Stack Group

I’ve recently seen an increase in the number of those interested in F# programming for web development. I don’t think this is a recent phenomenon; I just haven’t had the privilege of running into many of them previously. Nevertheless, we have decided to band together to provide a set of useful, well-designed libraries for web development in F#.

If you are interested in learning more, please join us in the F# Web Stack Google Group. I’ve added a list of current projects and efforts in the welcome message so that you can gain your bearings quickly. Current topics include merging various projects into a cohesive stack and planning one or more type providers to build out server and client boilerplate from API documentation.

WebSharper UI Improvements

The WebSharper project has been making significant strides of late in the realm of building composable and reactive user interfaces, especially for the purpose of building SPA-style applications. You can find documentation and demos for WebSharper.UI.Next on its new site hosted on GitHub. Team members have also been blogging about how to build UIs with the new tools on the WebSharper blog.

Anton Tayanovskyy also joined Community for F# a month or so ago to describe the concepts behind the design of WebSharper.UI.Next and how it is different from some other popular approaches, including the virtual DOM approach used in Facebook’s React library. You can find the recording on YouTube.

F# on the Web

I recently presented to the Houston Functional Programmers meetup on the topic of using F# for web development. This is an update to my talks with a similar title based on my experience building a real application for Tachyus. I cover data access using the FSharp.Data.SqlClient and building web APIs using ASP.NET Web API with Frank. You can find the video on YouTube.

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.