Why use NancyFX?

If this seems interesting to you, I'd also highly recommend checking out ServiceStack (<a href="http://servicestack.net/" rel="nofollow">http://servicestack.net/</a>). I've been using it for all my .NET API and web work lately and it's been awesome. It definitely helps that mythz is incredibly responsive to questions, no matter how mundane.

I'm a .NET dev by day and do a lot of Ruby/Rails/Sinatra by night. I would seem a natural target audience for NancyFX since I've enjoyed exploring both ends of the Ruby web framework world.<p>But, I am resistant to invest much in NancyFX. I can't see where it fits in the enterprise world where most .NET devs live. With 4 choices already (WebForms, MVC, Web API, WCF) for developing sites/apps/services, I just don't have a good story for inserting Nancy into the mix.<p>My primary goal, in developing for enterprise, after meeting customer requirements, is to build things that are simple to maintain and can be picked up easily by any other .NET developer. I loathe custom/in-house frameworks for that reason and while NancyFX has a strong community as far as I can tell, there's no guarantee that community won't tire and move along.<p>I'll keep an eye on it, but for now, skipping over it.

Our company recently switched to Nancy and we've never been happier. So much easier to get up and running than ASP.NET MVC or Web API. Very testable, especially with a built-in IOC container. The ability to easily test the full request/response cycle is huge because it uncovers HTTP and serialisation bugs, instead of just testing logic in the class library.<p>The various hosting options also means that we can easily host Nancy from inside a console app or Windows services. Now anything can have a REST API. Who needs WCF?<p>Bonus point: We followed Nancy's example of using rake on Windows and now we're <i>doubly</i> happy. Rake and Albacore have revolutionised our Windows build process.

I'm using NancyFX for a decently sized project. We are using Razor as our view engine, it has nice IOC integration, the testing framework works better than I've found for anything with MVC. And for basic work all of the developers were able to pick it up rather quickly.<p>The bad: getting a consistent convention for setting up your response methods has been some work, as there are so many ways to make one. Routes are EXTREMELY extensible, so you end up trying to do things you probably shouldn't. Lots of dynamics (at least the way we use it), and the dynamic type has a lot of side effects.