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!
