Tuesday, April 7, 2015

Packaging OWIN Middleware

Following on from the last post about building OWIN middleware directly as functions this post shows how to package such middleware up in an easy to consume package. Doing so is quite easy, so this post is quite short.

The request logging middleware developed in the last post looks like this:

To use this application developers will have to add that function to their OWIN pipeline. Doing so in pure OWIN, without resorting to APIs specific to a given server implementation, is a matter of calling the build function with the middleware function. The server implementation is responsible for providing the build function.

Using the ASP.NET 5 API for obtaining an OWIN build function and assuming the requestLoggingMiddleware is in scope adding middleware through the build function looks like this:

Nice and simple. What we might add on top of this is a simple extension method to the build function:

turning the code for adding the middleware to the pipeline into this:

The advantage of this is that
  • the requestLoggingMiddleware variable need not be in scope in the application code
  • the extension method provides a convenient place for application startup code to pass in parameters to the middleware - like say logging configuration parameters or whatever else might be relevant
  • the extension method returns the build function allowing application code a convenient way of chaining pipeline setup

Now sharing the middleware a across a number of services (and teams) is a matter of sharing the class above through e.g. NuGet.

Thursday, March 26, 2015

Handle Cross Cutting Concerns with an OWIN MidFunc

This post picks up where my post Why Write (OWIN) 'Middleware' in Web Applications? left off, and starts digging into writting OWIN middleware.

OWIN Middleware is a Function

OWIN middleware is a function, which makes perfect sense considering this Pipes and Filters like diagram from the last OWIN port:

The pieces of middleware are functions that request and response data flow through.

Middleware is a Curried Function

The traditional way of looking a the function signature of OWIN middleware a bit daunting1. I find it easier to think of middleware as curried functions that takes two arguments - one at a time - the first argument being the next piece of middleware in the pipeline and the second a dictionary containing the request and the response data:

The middleware function can do whatever it wants to the request and response data before and after calling the next part of the pipeline - which is the function passed into the 'next' argument.

Handling a Simple Cross Cutting Concern

A simple thing that most people building an SOA system want to do across all services is request logging. A simple piece of OWIN middleware can handle this quite niicely like this:

Put this middleware at the beginning of the OWIN pipeline and all requests and all request execution times will be logged.

Summing up

OWIN middleware is most easily (I find) understood as simple curried function taking two parameters: The next step in the pipeline and an environment dictionary containing all request and response data.
Next time we will look a packaging this up nicely in a library that makes it easy to drop this middleware into your pipeline.

1. The middleware function is usually presented as

or this shorthand version

Saturday, February 28, 2015

Nancy 1.0 and the Book

In light of Nancy recently reaching 1.0 (and quickly thereafter 1.1), I thought it was appropriate to revisit my Nancy book, and the running code sample in it on Nancy 1.1. This post looks at what's changed and what I might have coded differently now.

But first,

Is the Book still Relevant?

Yes, I think the book is still relevant. Almost all the code works unchanged with Nancy 1.1, and Nancy still follows the same principals and philosophy. I still think the book is a quick way to get introduced to Nancys way of doing things, the DSLs it provides and it awesome extensibility.
(But then again, I may be slightly biased)

What Broke Between Then and Now?

After updating the Nancy packages in my copy of the code for the 12th and final chapter of the book only one thing did not compile. One method on the IBodyDeserializer interface has changes, namely CanDeserialize which now receives a BindingContext as an argument. I added this argument, compiled and all tests passed and AFAICT everything worked.
That's it. And that says a lot about Nancy. There may not be a lot of promises of backward compatibility, but still the effort needed to update from 0.17 to 1.1 was minimal.

I have had comments that the MongoDB driver used is out of date and that the code in the book uses methods from it that are now obsolete. Since MongoDB is not the subject of the book and the code still works, I'm going to continue punting on that one, and just say no big deal.

What Would I Have Done Differently?


The book covers ASP.NET hosting and self hosting and how to setup a solution where the site is in a class library which can be re-used across hosts. Today I might still start out with the ASP.NET host because it is familiar to many ASP.NET developers, but self hosting as well as the cross host scenario would be OWIN based. In general I'd recommend OWIN hosting now, so that would have some space in the book, if written today.

The Cloud Chapter

Hmmm. Deploying Nancy to the cloud. That chapter seemed like a good idea up front. But wasn't. It ended up being more about some esotric xUnit setup stuff than about deployment. Why? Because deploying Nancy to the cloud is no big deal. It's just like deploying any ASP.NET (or OWIN) application to the cloud. In other words nothing special.
I didn't see that while writing, though, but I hope I would have left this chapter out if I'd written the book today. Maybe a chapter on OWIN would have been a better idea.


The book describes adding Tiwtter login using the Worlddomination NuGet packages. Unfortunately that package changed it's name to SimpleAuthentication between my final draft and the publication of the book. Grrrrrrrrrrrrrrrrrrrr.
In any case, if writing the book today I think I would have pushed the Twitter authentication down to the OWIN level. On the other hand that would mean less focus on Nancy and more on OWIN. But I think that is what I'd do, because using OWIN middleware for authentication would be my (general) recommendation today.

Test Defaults

I worte the book in a test first fashion - showing tests first and then implementation. I'm still happy with that decision, because it emphasizes the awesome Nancy.Testing library and just how testable Nancy is. -And for me testability is a major feature of a framework.
There is a feature that has been introduced in Nancy since the book was written that would have allowed me to cut down on a lot of duplication in the test code, namely defaults for the Browser object. I would have used that all over the book if writing it now, and highly recommend using the Browser defaults.


This is minor, but if writing the book today I would not have used NLog but SeriLog instead.