OWIN - why you should care?
Open Web Interface for .NET aims to define a standard interface between web servers and web applications. Adhering to this interface will allow decoupling of server implementations from web frameworks. The idea isn’t something novel and other platforms benefited from it immensely. In Ruby we have pretty mature Rack which allows hosting Rails, Sinatra or any other rack compatible application on a web server of your choice. In Node.js world there is Connect middleware with frameworks like Express and Zappa built on top of it. To be fair Connect is not exactly the same thing as Rack but the analogy serves well to understand underlying ideas.
Having a common middleware and frameworks built on top of it not only allows you to swap your web server at whim. It also means that you’re now able to combine many application into one easily even if they are implemented in different frameworks. It took me some time to realize how powerful concept it is until I built a demo for a conference presentation. I wanted to have single web server running in background so that I can easily switch between pages built with Angular, Backbone and Knockout. I also didn’t want to throw out separate templates scaffolded with Yeoman and have a shared REST-like api built with Express. How surprised I was when the only thing I needed to do was to call equivalent of:
connect.use(angularApp); connect.use(knockoutApp); connect.use(backboneApp);
OWIN opens a new world for .NET web stacksThis all may sound blurry for a .NET newbie or maybe even to experienced developer so I’ll give some examples of what is or will be possible to do in a near future.
- IIS as option not requirement – having a way to add a full fledged web interface for a windows service was not an easy thing to do. If only you could you use Asp.Net MVC things would be so much easier. Guess what, when Asp.Net MVC will support OWIN and I’m positive it someday will, this will be a no brainer.
- Combine Nancy, FubuMVC, pick a name – maybe you would like to use some existing component and not have to rewrite it to match you stack. Or maybe you work on a really big project and some teams prefer one framework over the other. You are right, this already is possible.
- Integration tests – say you would like to execute end to end tests over your web application. Right know you’ll either have to deploy your asp.net mvc app to IIS or IIS Express. This means spinning up separate processes even if you would like to run a single test on you development machine. You may be lucky and be using asp.net web api and be able to use HttpSelfHostServer but then again you’re limited only to this stack. With OWIN it already is possible to use a lightweight Nowin or Katana to run any compatible application inside your tests.
- Faster Tests – is hosting a http server inside you tests too expensive? With OWIN you might actually be able to run tests entirely in memory with no network involved whatsoever.
- Cross cutting concerns – maybe you need to apply the same authentication mechanism to couple of separate applications. Yes you’re right implementing it as HttpModule might work, but what about this one that you have to support which is based on Nancy. Nancy already supports OWIN so you’re good to go.
- Combining Express.js and Asp.Net Web Api – so you’re building a web app using Express.js but you’ve found that it would be nice to reuse some part of the existing code that is built in .NET. With the excellent edge.js and OWIN enabled middleware built on top of it called connect-owin you’re now allowed to this.
One app using both Express.js and ASP.NET Web ApiThe last example of OWIN usage seemed like the coolest to me so I wanted to try if it’s really doable at the moment. This wasn’t as easy as one could wish but bare in mind that the OWIN initiative is just starting getting momentum and we’re really on a bleeding edge. The connect-webapi-samples repo contains a sample of single web app where some requests are served by express.js while others using ASP.NET Web Api. You can start the server with:
msbuild .\Connect.WebApi.sln node .\index.jsNavigating to http://localhost:3000/hello will give you response from Express:
When you go to http://localhost:3000/webapi/values you’ll get a standard ValuesController response:
Note that both requests are logged in console using connect.logger middleware:
I was thinking about a case where this combination could become handy. In a project I’m currently involved in we’re using Highcharts to present beautiful charts to clients. Unfortunately some of them still use ancient browsers like IE7 which does not handle many Highcharts displayed on one page – or rather dies trying to render them. For those browsers we actually produce similar chart images on server. This however requires a lot of boring code to convert from Higchart chart configuration to the 3rd party library format we use for rasterizing.
What we could do very easily with OWIN is to keep a .NET component that generates a complete Highchart configuration and add a very thin “middleware” layer that would take a real configuration pass it into Phantomjs and get back an image that would look exactly the same as real chart. I’m pretty sure it would be much more robust solution than our current approach.