Last night Ben Hall blogged about how he managed to get Nancy running on Heroku. It’s still an early experiment, and totally unsupported by Heroku itself, but it is very interesting to say the least.

In essence this means that it might be possible to run any Mono compliant (really guys, you need to pay attention to making this the case for your apps, it’s not much work at all) application on Heroku.

Neat!

-

Nancy is a lightweight HTTP framework for building web services and sites. The framework runs on both the .net framework and Mono.

Nancy is a lightweight HTTP framework for building web services and sites. The framework runs on both the .net framework and Mono.

Out of the box, Nancy supports GET, POST, PUT, PATCH, DELETE, OPTIONS and HEAD (although these are a special case of GET requests and handled differently by the framework) requests.

These are the subset of the RFC-2116 that we’ve found useful to support in Nancy. We do understand that your application might have the need to handler different kinds of requests and there are ways around this.

It’s not something we’ve specifically built Nancy to support, but because of the design we use, you can add additional handlers for other types of requests with very little effort.

In the above code I created a custom Nancy module that added a method with the name of the request verb that we want to add support for. The return type of the method is a RouteBuilder, a helper class that is used to provide the syntax Nancy uses for defining route handlers.

Once the module is created, all you have to do to start handling requests of the new method is to inherit your modules from the new base class and add your handlers.

That’s all there is to adding support for additional request methods in Nancy!

”To sum up, I would just kindly advice Andreas to invest his time and enthusiasm into something better, cause this Nancy was definitely born dead."

368 days ago I first announced Nancy on Elegant Code and that was a piece of advice that I received among the many comments that followed.

You know what? Back them he might have been right. Nancy was a personal project that I spiked out in a couple of nights and let loose into the wild with no real expectations.

However, taking a step back an looking at the year that has passed, the complete opposite has unfolded . Since the first commit was made by me, on the 20th of November 2010, quite a lot have changed for Nancy. More than I could have possibly have imagined to be honest.

They grow up so fast

In the announcement post I wrapped up with a list of things I knew I wanted to get into Nancy at that time. Some of them were pretty big tasks, some quite small.

• A much richer request object
• The ability to inject dependencies into Nancy modules
• Conditions on actions
• View engine integration
• Ship with a nice bunch of response formatters
• Self-composed framework
• Request and Response interception
• NuGet presence
• Command line (powershell?) support for spawning up a Nancy application project
• Provide self-hosting somehow

Not only did we complete all of the above, but those are just the tip of the ice berg of things that’s happened during the last year. Today Nancy’s matured into an awesome framework for building web sites and services on both .net and Mono.

The list of features that are now supported is too long to list here, but a couple of highlights are support for all the major view engines, inversion of control containers, authentication, request pipelines (both on application and module level), model binding and so much more stuff that it blows my mind.

One thing that pleases me though, is that even with all the added features, Nancy is still a light weight framework because of the way it’s architecture. It’s built with a small core that has some nice extension points built into it. Extensions are built in the form of Nugets and to add a feature you simple grab the Nuget for it and of you go. Right now we have 20 official nugets and a couple of ones that’s been created by the community

Standing on a thousand shoulders

This is not the result of the labor of a single individual, quite the opposite.

Nancy a result of the amazing community that’s evolved around it and the incredible list of 57 people that have contributed over 100 pull requests and of course everybody that’s ever provided feedback, suggestion and that’s blogged, created screencast or talked about Nancy at a conference or other gatherings.

The project is a regular on the GitHub Languages page under the C# page, with 504 watchers and 132 forks at the time when I write this post. If you include the number of people that’s taken part in discussions on our user group and on Twitter.

Thank you so much!

A grumpy fella from the UK

Early one on guy from the UK took Nancy at heart and started contributing some pretty impressive stuff to the project. Right from the start he “got Nancy” and understood the vision I had for the project. It didn’t take long (too long if you ask him) before it was only fair to add him as a core developer and get his name on the mailbox.

I am of course talking about Steven Robbins, a.k.a @grumpydev. Not only has he put a lot of awesome stuff into the project, but he’s also become a good friend over the year that’s passed.

Thanks for all your work on Nancy buddy!

Are we there yet?

Not by a long shot! We’ve got so much stuff planned for the project and there are so many suggestions and contributions coming in every week. However it is important that we pace out self and make sure things does not grown in an uncontrolled rate or direction. Every thing that is added into Nancy is still measured on the same scale as before. Controlled chaos as it’s best!

So here’s hoping for another awesome year!

A quick heads up. In Nancy 0.6.0 we introduced a change that made the application scan, for all available views, and cache them upfront. While this is good for performance, because it reduces view loading time and limits I/O operations, it does pose a slight nuance then you are creating you view.

Because of the cache, each time you made changes to the view template you had to restart the webserver so that the Nancy startup code ran again. A bit of a pain in the sitting area, I agree.

This update is not in the 0.6.0 release it self, not in the NuGet packages. So in order to get a hold of a copy that uses this you will have to either download the latest source code and built it yourself, or grab the latest artifacts from our TeamCity server. 

Nancy recently reached version 0.6.0 and was the result of 220 changed files, divided into 126 commits by a total of 12 different authors. That alone is pretty damn awesome if you ask me, but of course we didn’t just make random changes to the code, we did try to add some new cool stuff as well!

The major parts that got some attention in this release were performance, there bootstrapper, the view engines and lots of internal changes that you will only notice if you work with the code.

So let’s dig in an see what we we’ve concocted

Bootstrapper

We are quite proud of the bootstrapping approach we have taken in Nancy. It’s right in the center of everything and helps us implement new functionality with minimal effort but it also helps Nancy users get dependencies into their modules absolutely minimal effort. In the 0.6.0 release we put quite a lot of effort into the bootstrapper code.

Un essence it can be summed up with:

• A lot cleaner public facing API
• Makes it easier to implement a custom boostrapper for a different container
• Reduces friction when adding Nancy functionality moving forwards

View conventions

Prior to 0.6.0 you were pretty limited to where Nancy would look to resolve views to render. In fact you were limited to a folder called views, that had to be in the root of your application. Well that’s now changed into being convention driven instead, with the possibility to modify the conventions yourself.

The default conventions that is shipped with Nancy are

Providing your own is equally as simple. You create a custom boostrapper (that Nancy will find automatically and use) and modify the list (yes, conventions are stored in an IList<Func<string, dynamic, NancyContext>> instance) in what ever way it please you

View caching

Let’s be blunt. View engine were slow in Nancy before we pushed out 0.6.0. Why? Well, for different reasons for different engines, but it all boils down to the fact that views were located and compiled on each and every request. Ya, I know.. slow. But no more! The first thing we did was to have Nancy identify all views that could be rendered (based on the available view engines in your application) and cache them at application startup. This means the file system (or what ever means of storing your views you use) only gets hit once, removing an expensive traversal from the request/response cycle.

The second thing we implemented was a cross-engine view cache. This means that we now cache the compiled, but not initialized, version of a view. Not having to compile the view on each request was huge performance boost. How big you ask? I’ll let you view it with your own eyes.

I know! Pretty impressive, isn’t it. Let me give you some help to understand what you are seeing. The (M) means master branch and (E) means experimental branch. While we were working on this we used a different branch so these benchmarks were taken right before we merged experimental back into master. There’s some fantastic performance improvements across the board, but the one I would like to highlight is the one for string.

This means a route that just returns a simple string. Technically this is not a view, but we used it as a reference point because it’s the simplest form of response. A 28% increase in performance is pure optimization in the request/response life cycle and even then it all came down to some small, clever, changes.

What? You mean the green bar? Oh! That green bar. Well, turn’s out that hitting csc.exe on each request can really kill performance really horrible.

All in all, we are very happy with the changes we made here.

Razor

As if the massive performance boost wasn’t enough we managed to squeeze in some very anticipated features. The two big ones are support for partial views and layouts. We managed to decipher the crypto that is layout support in the razor parser (poor Steve used reflector more than anyone should have to do in a single stretch) so the implementation we provide should be wired up like it is in ASP.NET MVC. There are also some other changes that we have documented on our wiki.

Super-simple view engine

The big changes here are added support for partial views and layouts. This little engine is starting to become quite rich on features but it is still extremely small and embedded into the Nancy dll, so it is accessible when ever you are working on a Nancy application.

Dotliquid

We added a new view engine, this time for the dotliquid markup syntax.

And Bob’s your uncle!

That’s it! It’s not all of it, but that’s the essence of it. We did fix bugs, improve code quality, create more NuGet packages and a lot of small changes as well. So, if you haven’t already, go check it out at nancyfx.org or at the official NuGet feed.

Until next time, happy coding!

Little more than a week ago, I sat down to add the possibility of using anonymous types as models for views in Nancy. Now, since not all view engines can handle anonymous types as their model I decided I would intercept them, along the way to the view engine, and convert them into an ExpandObject instead.

In order to do this I needed to detect them first, and after poking around the reflection API, and use Google + Twitter to confirm it, I came to the conclusion that there is nothing in there that will tell me if the instance I have is of an anonymous type or not.

Then I got a tweet from Joseph Gray, also known at @MrJosephGray on Twitter, sent me a link to a blog post by Jef Claes titled Checking for anonymous types and it contained just what I needed. It works beautifully, until I ran my code on Mono that is.

Even though the blog post is not clear on it, I was aware of that the detection method relies on undocumented naming conventions and no guarantee that any of the traits, that it checks, won’t be changed in the future by Microsoft. That is also why I was not surprised that there were issues while running it on Mono.

After taking the debugger out for a quick spin it was evident that it was the type name that was the culprit. On Mono (at least on 2.10 that I am running), the name of the generated type contains AnonType and not AnonymousType and it was a trivial task to patch the extension method to check for that as well.

The full implementation that I am using in Nancy is listed below

A week ago I was invited to participate in he Hanselminutes postcast by Scott Hanselman to talk about Nancy and Micro Web Framework. The recording for episode #270 can be found at Nancy, Sinatra and the Explosion of .NET Micro Web Frameworks with Andreas Håkansson

I had a great time talking to Scott, who is an excellent host, but one thing I did not get an opportunity to do was to extend my gratitude to the awesome people that are forming up a community around the project, everybody from the people that blog, tweet, screencast or in some other way help Nancy grow into an awesome framework – so thank you to all of you!

The following people have all contributed to the Nancy repository and have helped us get many of the awesome features and bug fixes (if your name should be on this list, but it not, please drop me a line and I will get sorted out!)

Andy Pike, Bjarte Djuvik Næss, Chris Nicola, David Hong, Graeme Foster, Guido Tapia, Hernan Garcia, Ian Davis, Jonas Cannehag, José F. Romaniello, Karl Seguin, Luke Smith, James Eggers, Jason Mead, Jeremy Skinner, João Bragança, Johan Danforth, John Downey, Maciej Kowalewski, Martijn Laarman, Mindaugas Mozûras, Patrik Hägne, Pedro Felix, Piotr Wlodek, Phil Haack, Robert Greyling, Simon Skov Boisen, Steven Robbins, Thomas Pedersen, Troels Thomsen, Vidar L. Sømme

I would like to extend a special thank you and shout out to my friend and co-conspirator Steven Robbins a.k.a @GrumpyDev on Twitter. He is a continuous source of awesome for Nancy and the project is better for having him onboard, that is one thing I am certain on. Thank you buddy!

It seem that every 3-5 month or so, the discussion on the state of the .NET open-source community flairs up. Some say it’s a dead horse being beaten, other that it’s a vibrant, thriving community. Sound familiar? Who cares?! Seriously, who cares? The right thing to do in either case is the exact same thing; keep injecting more value into it!

If the movement (if you can call it that) is truly dead, then what? Do we just roll over and play dead, or do we add more value to it and help breath new life in to it? If your answer is the former then you are simply not an open-source kind of guy. Now imagine that it’s is, in fact, a vibrant and thriving community, full of goodies to choose from. What should be do then? Stop adding value to it since it’s already doing well, or do we keep on pushing to add even more value into it? We keep adding value, of course, if it wasn’t already obvious that would be my answer.

Alright then, how do we inject move value into it? Contribute to an already active project or start a new one? It truly depends on your visions. First of all let me make it perfectly clear that I think diversity is not only a good thing, but a sign of a healthy community. There is no single “silver bullet” that will solve all problems or in a way that out domain requires them to. It’s very rare for a “all-in-one” solution is the best for your scenario and that’s why I believe opinionated solutions is required.

Everybody won’t agree to a single opinion, it’s just not ever going to happen, so how could a single framework or product be the solution to all problems we face in our industry? It can’t.

The first thing you should get out of your head is that your source code is where the gravy is. Sticking to that story won’t get your very fare. Any decent programmer can probably reproduce any functionality with their own implementation. It might not be as fancy as your solution, but I’ll bet you that it would work well enough to solve the problem they were facing – they’d see to that.

So if the value is not in the source code, that you’ve spent weeks, maybe months, perfecting and to work just the way you wanted it to, with all the fancy solutions and patterns in place, then were is it? It’s in the vision of the source code. The vision is the heart and soul of your project and it’s what will ensure that the project can live on even if you loose interest. It’s your opinions on how things should be done.

Now, of course, if you vision is nearly the same as the next guy and all you do is pinch his source code and call it your own thing, then you’re just being an ass hole. I’m sorry, but you are. If you have a clear idea on how you thing a certain set of problems should be solved, that’s when you have the foundation for a nice opinionated solution…that’s the vision of your project.

The vision of the project should be set in stone before you make the first public release. Be careful to be blinded by the massive amount of suggestions and contributions that you might be getting. If they will lead you down a path that is not true to your vision – ignore them. Send them a “thank you, but this is not for this project” and if they don’t like that then they should distil their visions into their own project. It’s impossible to say which would be the better solution – heck, why can’t both be just as good but suite different people? Diversity.

If you nurture the vision of your project well enough and attract equal minded people then you have started a community and they will make sure the project stays true to the original vision, trust me. Should you suddenly loose interest in the project, or for some other reason not be able to commit to the cause anymore, the community can simply fork and create a new authorities branch. This has happened time and time again in many of the big open-source projects.

I’m happy to say that I keep seeing the diversity in the .NET open-source community grow as we speak. I keep seeing more and more small, opinionated, projects pop up and that they are being embraced by a subset of our community as a whole. Sure, the .NET community has probably quite a bit more to invest in open-source, but it’s getting there and the only way to get there faster is to be part of the ride! 

For the past couple of months the number of contributions and modifications to Nancy have really grown in a nice and organic way. During that time it’s started to be a real task to take care of all outstanding work, maintain the community presence, work on documentation and all other things that comes with an open-source project.

For that reason I have decided that the Nancy team needed to expand and there was one candidate that stood out in the crowed. He has contributes more awesome features to Nancy than I can recall, he’s the one person I have an ongoing dialogue with about the progression and vision of the project and I see no better person to gain commit access to the main repository.

I am, of course, talking about the lean mean British “I-code-better-on-beer-and-wine” machine, Steven Robbins a.k.a @grumpydev, author of TinyIoC among things. He also coined the term “super-duper-happy-path” that we use as a guiding star on each new feature we design for Nancy.

Over the next couple of weeks are going to start ironing out all the details for turning the Nancy repository into an organization and moving things out of the core repository, such as the 3rd party dependencies (they will still be around, but not in the main solution).

So, welcome aboard Grumpy and thank you for all your hard and amazing work on Nancy!

Right from very first day that I announced Nancy to the world, the pace that things have moved forward has been nothing short of amazing. Nancy was always meant to be developed right out there with the community and let me tell you that I have not been disappointed, the community answered the call. Pull request nr. 116 was sent in the other day and over 26 people (with a couple of more having pending requests) have contributed code to Nancy – some of them on multiple occasions.

Since then Nancy has gained an impressive feature lists such as bootstrapping capabilities for all the major Inversion of Control containers, view engine support (spark, razor, ndjango and a Nancy specific engine), hosts for asp.net, WCF, self-hosting and even one of the (if not THE) first OWIN compatible host, cookies, sessions, embedded views, pre- and post-request pipeline, security (authentication and authorization) and many many more. The list keeps on growing.

There have also been several individual and companies that have started writing applications on Nancy, ranging from simple proof of concept applications to actually taking Nancy into a production environment is software that’s sold to customers. We’ve also gotten to see Nancy run on mac and Linux thanks to mono support and we think that’s just awesome!

So what’s the fuzz all about?!

The goal of Nancy is to provide a no fuzz, low ceremony framework for building web applications. One of the key concepts that’s applied when working on Nancy is that everything should have a “super-duper-happy-path” implementation, you shouldn’t have to jump though hops to write your websites there should be a sensible default for everything. Simplicity is key, but not at the expense of power.

At first glance you wouldn’t know it, but pretty much everything in Nancy is customizable. It’s intentionally been designed to stay out of your way, but should you find yourself in need to change a specific behavior Nancy will make it as frictionless as could be.

Right from the get go, Nancy was built to not rely on a specific environment to be able to run. We built the concept of host adapters and they site right in between Nancy and what ever environment she might run on. Out of the box we currently supply hosts for running on top of ASP.NET, WCF, OWIN and a self-host (built on httplistner), but the list is sure to expand and writing adapters is easy.

There is no dependency, what so ever, on System.Web from the Nancy core assembly so you can, without any problem, embed Nancy in your applications and so on. ReST-based end-point in your application? Sure why not?!

Bla, bla, bla – show me the codez!

Alrighty then. To give you an idea of how it is to work with Nancy, we will be building a simple Hello World (surprise!) Nancy web application. The application will be built to run on ASP.NET, but it could just as easily have been running on any of the others hosts (just swap it out, no code changes needed).

To get started create a new ASP.NET Empty Web Application project (don’t worry, we have our own project template but let’s skip those and get right to the fun stuff). Once you’ve created the application it’s time to grab Nancy. You could visit out repository to download the source and build the binaries, or you could choose the easy way; use NuGet to grab the bits we need.

We are going to go with the NuGet packages, so grab the Nancy.Hosting.Aspnet nuget. Not only will this install the adapter required to run Nancy on ASP.NET, but it will also register the adapter in your web.config and grab the Nancy core nuget.

That’s it. You have the foundation of a Nancy application running on top of ASP.NET. Now you need contents. So let’s add a module to our project (modules can be added anywhere in your project, Nancy will find them for you).

What you are looking at is a module that responds to a GET request to the root path of your application. When an incoming requests matches those criterion, Nancy will respond with the text “Hello World”. Run the application and verify that I’m not kidding you – it really is as simple as that!

That’s all will show you in this post. In following posts I will be sure to take you on a journey in the world of Nancy and show you things like POST, PUT, DELETE and HEAD requests, injecting dependencies into modules, using response formatters, grabbing parameters from the requested route, complex route syntax, view engines, model binding, before/after request handling (both on request and module level) and much, much more.

Nancy on the web.

If you want to talk about Nancy you can find us on Google Groups or on Twitter using the #NancyFx hashtag. You can also reach me on twitter @thecodejunkie