Nancy, the little community-powered framework that could

Two months ago, on the day, I first announced Nancy here on Elegant Code as my new open-source project. I could never have anticipated the chain of events that would take place during the following two months. My tweet about the blog post got re-tweeted more times than I can remember and the post filled up with, mostly, awesome feedback.

It took about and week and then Nancy got the first pull request on her github account and from there it started to build up momentum quite fast. At the time of this writing there’s been 53 pull requests, by about 20 different people, for all kinds of features, bug fixes, custom hosts… you name it. Not bad, eh?

Not only that, but Nancy has managed to pull together a nice little community, over at Google Groups, where the future of Nancy is being discussed every day. She’s also getting some attention on Twitter and we’re trying to gather it all under the #NancyFx hashtag and seems like every day there is a new face popping up.

In the initial commit there were a couple of abstractions and light extension points in place for things like custom hosts, view engines and response formatters. These turned out to be a very smart move, because the community really embraced and ran with them. Let me recap some of the things that has happened since day zero

  • View engines; there are currently support for Spark, Razor, NDjango and Static templates. We did have support for NHaml for a while, but that community seems to have gone into hibernation, so the decision was made to pull it and not waste dev cycles on it until there was a demand
  • Inversion of Control integration; this has been one of the big one. Right from the very first beginning I wanted Nancy to be a self composing framework, that is have a small internal container that glued the framework together at runtime. I also wanted the possibility to register module level dependencies. It took a while and a couple of iterations, but we finally settled on a design and made TinyIoC the internal container. It was very important that it was a transparent experience to the end user and unless you have a need for it, you never know it’s there. Not only that, but thanks to community contributions we’ve managed to create hooks (known as bootstrappers in Nancy) for all of the major players such as StructureMap, Autofac, Unity, Ninject and Windsor. Using one of these container with Nancy is a very easy thing to do and only adds one more file to your project
  • Response formatters; one of the powerful features in Nancy is the response model and how it lets you return different kinds of things and leverages implicit cast operators to hide the complexity behind it. Thanks to the awesome Nancy community we now have the capability to return JSON, XML, images and perform redirect responses. It’s super easy to write a response extension and hook it into Nancy, so if you have any ideas….
  • Bug fixes; yeah I know, it’s shocking, but it’s still true. Every now and then someone finds a bug but, more importantly, most of the time the same person is part of contributing a patch to resolve it!
  • Hosts; Nancy has been designed with the idea of being able to run in multiple environments and shipped with a host to run on top of ASP.NET. Right now we have additional hosts for running Nancy on a WCF host and on a stand alone host. There are more of them on the way
  • HEAD requests; the first release of Nancy supported GET, POST, PUT and DELETE requests, but thanks to a clever little contributions she now also serves up HEAD requests
  • Cookies; not he ones you can eat….
  • Cookie based sessions; I think this is also self describing.. oh… yeah they are encrypted in case you were wondering!
  • Mono; we’ve started to seriously look at getting Nancy to run on top of the up coming mono 2.10 release (we need the improvements they’ve made to the dynamic keyword) and have already managed to run the sample application on both Linux and Mac OSX. Moving forward mono is going to be a supported and equally priorities platform to support
  • Visual Studio templates; these are still work in progress but right now I have the ability to new up a new Nancy project, based on the html5boilerplate … and we have a bare bone template in the making
  • Buildscript; a couple of days a go we added what every self respecting open-source project needs; a build script. We choose to use Rake (that’s a ruby powered format, for those of you that’s never seen it before) and make use of the excellent Albacore gem, but the awesome Derick Bailey

I’ve probably forgotten a bunch of things, there’s been so much going on that I can’t remember it all without looking at the commit history! That said, there are still things we want to put in place and there are already extensive discussions on the user group about them

  • Security
  • Content negotiation
  • OWIN hosting (we’re keeping track of the OWIN 1.0 specification)
  • Self-hosting (Benjamin van der Veen, if you are reading this – maybe Kayak can be a candidate!)

The one thing that we can’t seem to pull of

Is to find a designer to design a proper logo for the framework! We are in desperate need to get an awesome logo that we can put everywhere and start creating a website. So if you know any good designers that wouldn’t mind putting in some time in designing an awesome logo for an open-source project (read pro bono) and please tell them about us and about Nancy! A while back I created a post about the Nancy logo on our user group. It contains some information on the philosophy and goals for a logo for Nancy. I can’t stress enough how much I would appreciate if you took this and shared it with your designer friends!

As always, if you want to ping me either drop me a comment right here on the blog or find me on on Twitter account @TheCodeJunkie

… I can’t help to wonder what Nancy will be like in another two months!

4 thoughts on “Nancy, the little community-powered framework that could”

  1. Thx for creating such a great framework. I am already using it to build a nice frontend for the deployment pipeline I am creating.

    It’ would be interesting to have it hosted by Kayak, but I’m guessing there might be some challenges when it comes to Kayaks async nature.

    How would you e.g. read the views async. If Benjamin takes the challenge it will be interesting to check out the result 🙂

    Good stuff.

  2. I think you should use a Rosie the Riveter-esque logo… with the obvious implications that the framework is tough, packs a punch, but is wrapped up tightly in a nice shell.

  3. It’s really nice to see the .NET community working, I really like this going on and on. Also the project seems really promising, as I said in your first post about this. Keep up the good work, I’ll be helping whenever I find the time.

    For a new era of the .NET community developers.

  4. Looking at the new .Net “http” Frameworks I have to say, the beauty of http is simplicity and so far I think it’s
    Nancy 1 : WCF Http 0

    🙂

Comments are closed.