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.
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 here 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
Request and Response interception
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!
Right after we released 0.8 about a week ago, we unfortunately found a couple of bugs. We decided that they were annoying enough to warrant an interim release, hence today we released 0.8.1. All repositories and nugets have been updated to the new version.
In total we fixed four bugs and introduced a breaking change in the JSON serializer while also adding support for TimeSpan in the serializer. For a complete list of changes, have a look at the 0.8.1 milestone at GitHub.
This release shall be known as the grumpy-release as he was the one that did all the heavy lifting. Kudos to his awesomeness!
Looking back at the past 11 months (that’s more or less how old Nancy is right now, time sure flies!), the hardest part of it all haven’t been to code any of the features in Nancy. The hardest part, without any doubts, has been to translate the essence of the framework into a logo.
I will be the first to admit that the main reason it’s taken so long is because I have been extremely picky about the logo we would end up choosing.
The technical aspects of the logo have never been an issue to me, the problem’s been translating my passion for Nancy into a design. I am a big fan of graphics design so I’ve done my fair share of reading on the subject, enough to know that the logo would need to follow a couple of guidelines to make it well balanced.
I’ve known from the start that I wanted it to scale well (both up and down), consist of both a text and a symbol, that the symbol should be strong enough to stand on it’s own while still contributing to brand recognition, just to mention a few of the technical aspects of the logo.
Early on we knew that the essence of the logo should capture the two words simple and elegant. We also knew that I wanted it to have a slight feminine touch to it because of the name.
We’ve had the opportunity to work with a couple of designers and also had community contributed suggestions. However, no of them have really managed to make me fall in love with their work.
Out of the blue, Nicolas Garfinkiel submitted a draft of a logo concept he had been working on the day before. We immediately fell in love with it. The logo was pretty much spot on right from the start and it only took us about a week of me and Steven nitpicking over minor details (several e-mails where exchanged on the look of the nose in the logo!) to get it done.
Not only had we fallen in love with Nicolas concept, but we were also amazed with way he conducted his work and the professionalism the brought to the process. Huge kudos to him for that!
So after nearly 11 months of struggling to get a worthy logo for Nancy, all it took was a random submission on our user group and a week worth of polish to get it done. Frankly it was worth the wait.
We are so pleased with the end result that it doesn’t matter that so much time have passed. I would have hated if we had picked a logo early on, even though we weren’t in love with it.
I wanted to highlight a couple of the compositions of the logo
This the vertical composition of the logo, that I absolutely love. The balance between the size of the silhouette and the size of the text is awesome. The use of the negative space to create the bangs really pops out.
This is one of the two horizontal compositions of the logo. The silhouette is presented as a negative to the text and has been places on a square background to create a nice balance between the two elements. The negative silhouette, on a square background, also works great on it’s own for things like avatars.
Here the silhouette is on it’s own. Again the use of the negative space, to create the bangs, really pops out. The silhouette is such a strong graphical element that it will be easy to create brand recognition with the help of it.
The work on the logo isn’t quite done yet. The actual logo is set, but we have set up a new repository, that we call Nancy.Portfolio, where we are working on committing all the material for the logo. This will include a graphical profile guideline for the use of the logo, as well as various file formats and resolutions of the various compositions of the logo. So keep an eye out for when we start pushing it out!
The say time flies when you are having fun and nothing could be more true when working on Nancy. Two months have already passed since we started work on 0.8.0, a release that was suppose to roughly take around 4-5 weeks to complete and consist mostly of diagnostics related changes. Boy were we wrong.
A community release
What did happen was that the awesome community around Nancy kept providing use with feedback, requests and, most of all, code! The 0.8.0 release was not created by me and Steven, but by the community at large.
A quick look at the comparison of 0.7.1 and 0.8.0 shows that a total of 19 authors and 186 different commits contributed code to this release and made the 44 work items happen. If you add all the people that provided feedback on the user group and on twitter then the number is, a lot, greater.
So thank you to everyone that helped make this release possible!
How much awesome can you stuff in a release?
Apparently quite a lot! The list of changes are too great to list in this one single blog post, but fortunately we make good use of the GitHub milestone systems and you can view the full change log at our repository.
However, here are some of the highlights of this release
Static content conventions – Yes! We finally have a good user story for static content so you no longer need to jump though hoops to serve static contents. These conventions are, of course, configurable and comes with a default one that looks for stuff in /content.
Testing improvements – Added a new configurable bootstrapper in the Nancy.Testing project that helps you control the fine grain of your test environment with the help of a nice API. We also added a bunch of new extension methods and updates.
Forms authentication improvements – You can now login/logout without having to performe a redirect, this is really useful in ajax scenarios.
Error handling hook and error pages – A pipeline where you can handle errors in your application and also support for rendering custom error pages.
Access to captured parameters on the context – Enables you to gain access to captured values from inside filters.
ProtoBuf support – A new Nuget that enables you to support ProtoBuf (de)serialization in your routes and model binding.
And sooooo much more – Go check it out!
All of this and we’re still on the super-duper-happy-path!
Sporting new swag!
With this release we also introduced the new Nancy logo and website! The awesome Nicolas Garfinkiel stepped up to the plate and awed us with his logo suggestion. He has been great to work with and managed to cope with the swarm of tweaks me and Steven threw at him! Not only that but he’s been working blazing fast and it only took us a week-ish to iron out the rough spots in the draft and get a polished version done!
We are really pleased with it and soon you will be able to get your hands on all the logo goodness, you’ve been wanting to (right?!), at our new Nancy.Portfolio repository. The repository will contain the logo in various formats and resolutions and well as a usage guideline. We just need a bit more time to put the finishing touches on it.
In case you’ve not seen it yet, this is one of the compositions of the logo
Beautiful, isn’t it?!
I plan on dedicating an entire blog post about the logo in the next day or so, so keep an eye out for more information!
Don’t worry, we’re not running out of things to do, in fact we’ve already staked out part of 0.9.0 (there’s even some planning on 0.10.0 up on GitHub). We’re going to try really hard on making the release cycle shorter this time because we really want to get the new, awesome, stuff into your hands as quickly as possible!
By the community, for the community
I would like to thank everybody that supports Nancy, no matter how you do it. People are building commercial produces, going to conferences and talk about Nancy, blog about it, contribute ideas, code and feedback. Nancy is truly a product by the community, for the community and for that we thank you all!
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.
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
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
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
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.
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.
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.