Benefits of using NancyFx? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

There is yet another framework for making HTTP calls called NancyFx. My question is what are the benefits of using it. I had quick look at the documentation:

https://github.com/NancyFx/Nancy/wiki/Documentation

and it looks like there is no outstanding feature due to which I would like to use this. What are the benefits of using it over WebHttp?

P.S: I keep reading about some strange phrase that keep repeating again and again "super-duper-happy-path". Is there anything apart from this "super-duper-happy-path"? Any real features implemented?

Answer 1

It appears that it offers a different approach to defining "routes" (in the MVC sense) using lambdas to identify relative paths, arguments, and the implementation of the response.

Ultimately, the framework's key benefit is its expressiveness. In ASP.NET MVC the RouteTable is in the global.asax and the implementation is in the Control. It appears that in NancyFx, this is the pattern that prevails:

Action["/path"] = args => { return your_implementation_here; }

Example implementation:

Get["/products"] = id => { return GetRepository().Products.Single( q => q.Id == id); };

Explanation: An HTTP Get to the relative endpoint '/products' with an argument of 'Id' will return a single product from the repository where the Id argument matches the product's Id.

Expressive and Concise.

Answer 2

Disclaimer: I'm not a supporter of NancyFx :)
I'm in the process of evaluating if I should go with NancyFx or with ASP.NET Web API for the REST part of a project.

Apart from simplicity and expressiveness (which do have a value on their own, I think) already mentioned by GlennFerrieLive, I think I've grasped another couple of nice bits:

1. It's easy to perform operations before and after any API request processing, in a kind of an Aspect Oriented way, so to say.

2. By default the framework takes care of the accepted returned type, so it will appropriately convert output in JSON, XML, ...

3. Lambdas implementing requests do not return actual filled data, but still in the form of a query. After that it's still possible to easily add filtering, sorting, and other operations before actually executing the query, hitting the DB, and returning the actual data.

4. They have somehow wrapped the HttpRequest and made available to the developer an equivalent of that, with the difference that this new object is injected and you can of course substitute it with a mock ... So easier and cleaner testing.

Maybe some of those (all?) are already available in ASP.NET Web API and with the same ease, I don't know for sure.
HTH