Talk video: "Consolidating Services with middleware" from NDC London 2017

Back in January I did a talk called at NDC London called "Consolidating Services with middleware", and the video of the talk has come out. Enjoy!



Consolidating Services with middleware - Christian Horsdal from NDC Conferences on Vimeo.

In case you are wondering what the talk is about, here is the abstract:

"Have many services? Writing new ones often? If so middleware can help you cut down on the ceremony for writting new services and at same time consolidate the handling of cross cutting concerns. But what is middleware? OWIN and ASP.NET Core both have a concept of middleware. What are they? How do they help? In this talk we will dive into the code, write some middleware and show how middleware helps you handle cross-cutting concerns in an isolated and re-usable way across your services. I'll compare and contrast the OWIN and ASP.NET Core middleware concepts and talk about where each is appropriate."

"Microservices in .NET Core" has landed

My new book "Microservices in .NET Core  - with examples in Nancy" has been published. It's been available as an early access ebook for a long time, but now the final paper book and the final ebook is available.

This book is very much based on experience from working of real microservices systems. While the examples in the book are not lifted directly from any particular system they are inspired by real world systems. My rule has been that all the examples demonstrate something that could have been in one or more of the systems I have experience with.

With this book I have tried to show two things:

    1. How to design a microservices system.
    2. How to build such a system using a lightweight .NET based tech stack.

All but one chapter reflect these two levels, in that they start off explaining an aspect of designing a microservice system, and then go on to show how to implement it using my .NET tech stack of choice. This should help make clear which parts make sense regardless of tech stack and which are tech specific. At the end of the book  you should have the tools to both design a microservice system and implement it, as we have covered subjects like how to decide what belongs in which microservice, where data resides, how microservices collaborate, how to test such a system, how to make it robust and how gain insights into how it is doing in production.

The tech stack I use in the book is based on .NET Core, Microsoft's new cross platform version of .NET. On top of .NET Core I use the Nancy web framework and OWIN middleware, which forms a powerful yet simple stack. To compliment this I use various other OSS libraries where appropriate, like Polly and Dapper. The guiding principle in all the tech choices is that they should be simple to use - make the simple stuff simple, while also allowing to do more complex stuff without unwarranted hassle.

You can find the table of contents and a couple of sample chapter on the books page at Manning. 

Also, if you are interested in these things, I have a 3 day course around these things available.

Short Circuiting Requests in OWIN Middleware

In earlier posts I've looked at writting and packaging OWIN middleware that does something to requests on thier way in and to the response on its way out. This time around I will show how middleware can choose to short circuit the pipeline and just return a response immediately.

TL;DR

Do not call next, and fill in the "owin.ResponseBody" environment key.

Why

Usually one middleware calls the next and that is how the pipeline is executed and how different pieces of middleware gets to each do their thing. At the end of the pipeline is the application where you do whatever application logic to handle the request. There are situations, though, where it makes sense for requests to not even reaching the application logic:

• Requests from unpaying customers could be throttled to some low rate
• Requests from certain IPs could be blocked
• Requests without valid authentication tokens could be turned away with a 401 status
• Some endpoint are not for application use - like monitoring endpoints

Build a Monitor Middleware

Lets take a look at building a middleware that provides a monitoring endpoint. It will listen on the path "/_monitor" and will respond with a small json object containing the version of the deployed software.

Once again I implement the middleware using the OWIN Midfunc - which we can think of as a curried function taking first the next piece of middleware in the pipeline and then the OWIN environment dictionary.
To implement the monitoring endpoint I look up the request path in the environment dictionary and decide if it is a monitoring path. If it is I write a simple json string to the response body, set the content type header and return. On the other hand if it is not a monitoring endpoint I just pass the environment into the next middleware in the pipeline.
Here is the code:

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.

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 daunting¹. 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

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?

Hosting

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.

Authentication

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.

Logging

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

Why Write (OWIN) 'Middleware' in Web Applications?

TL;DR

Middleware - in the OWIN sense - can help you modularize your web application code, and maybe even enable you to reuse the plumbing code needed to deal with cross cutting concerns.

What is Middleware?

The context of this post is web applications, and in that context middlewares are pieces of code between the web server and the application code:

When a request comes in it is first handled by the web server, which hands it off to the first piece of middleware, which hands it to the next and so on until the request reaches the application code - i.e. the Nancy Modules or MVC/WebAPI controllers. The response takes the opposite route from the application, through the middlewares and the web server. You can think of that as a pipeline. The pipeline starts and ends with the web server, has the middlewares along the way and the application in the middle:

The trick here is that the middlewares all conform to the same interface; meaning that the pipeline be composed in many different ways - we may omit middleware 3, insert a 4th between 1 and 2 or swap 2 and 3.

Put Cross Cutting Concerns In Middleware

When we look at the handling of an HTTP request as a pipeline there are some things that we can immediately see that we could stick into that pipeline and thereby have applied to all requests. The obvious examples are request and response logging, perfomance logging and authentication. Indeed these are things that there are OSS OWIN middleware implementations for.
Slightly less obvious maybe are the more application specific things like request throttling, caching, redirects of obsoleted URLs, or even things like integration to a payment gateway.
The common theme of these candidates for middleware is they are moving concerns that should otheriwse have been handled by the application code out into the pipeline. This not only cleans up application code but also lends you the flexibility of the pipeline to re-configure the cross cutting stuff in one pipeline across all end points.

Middleware in a Service Oriented Architecture

I'm usually wary of the promise of reuse, but it does depend on where the reuse happens. There is usually not a whole lot of reuse of business logic between applications. But the frameworks they are built on are hugely reused. Middleware sits (well) in the middle.
In the case of service oriented architecture (where HTTP is use for inter-service communication) serving one or more applications there is a potential for reuse across services of the types of plumbing that are specific to this particular architecture but not to each individual service. Things like

• adding monitoring endpoints to each service (middleware can short circuit the pipeline such that requests never reach the application)
• collecting usage data
• opening and closing database sessions
• keeping track of correlation tokens
• caching rules
• ...

These are all examples of things that you don't want to write for every single service, but that you might want every service to have. The more services there are and the smaller each one is the more important the reuse of plumbing becomes. Wrapping each of these cross cutting pieces of functionality into middleware which plugs right into the pipeline makes them readily reusable across services.

OWIN and ASP.NET 5

Both OWIN and ASP.NET 5 supports the idea of middleware. In OWIN it's one the central features. In ASP.NET 5 the same feature is available 1) because ASP.NET 5 supports OWIN and 2) because it also brings it's own notion of middleware to the table.

In future post I'll dig more into both OWIN middleware and the 'proprietary' ASP.NET 5 middleware.

Slides from "OWIN and Composable Web Apps" at Campus Days Cph

Here are the OWIN slides from the talk I did at Campus Days Cph today. Enjoy :)