Why am I not Using NancyFx Instead of ASP.NET MVC / Web API

Why am I not using NancyFx instead of ASP.NET MVC / Web API? Because of a very important and vital missing part with NancyFx: asynchrony!
2012-12-18 19:50
Tugberk Ugurlu


Note: If you don't understand asynchrony and its benefits, you are better off without this blog post. If you are willing to learn the importance of asynchrony for server applications, here are two videos for you to start:

Update 2013-10-08:

Great news! NancyFx now has asyncronous processing ability. See Jonathan Channon's post for more details: Async Route Handling with Nancy 

Server side .NET ecosystem is not just about the frameworks that Microsoft builds and ships such as ASP.NET MVC, ASP.NET Web API, etc. There are other open source frameworks out there such as NancyFx which has been embraced by the community. I haven’t played with NancyFx that much but I really wanted to understand how it is more special than its equivalent frameworks. As far as I can tell, it’s not but I am nowhere near to make that judgment because I only spared 10 minutes to figure that out, which is obviously not enough to judge a framework. Why and where did I stop? Let’s get to that later.

You may have also noticed that I have been kind of opinionated about ASP.NET Web API lately. It’s not because I am writing a book on ASP.NET Web API. The reason of my passion is related to fact that I know how it works internally and I can see that none of the other equivalent frameworks hasn’t been able to get asynchrony right as this framework did (SignalR also gets asynchrony right but it’s kind of a different area)! Please do inform me and make me happy if you think that there is any other framework which we can put under this category. I didn’t put ASP.NET MVC under this category either because it’s not possible to go fully asynchronous throughout the pipeline with ASP.NET MVC. However, it’s has a really nice asynchronous support for most of the cases.

I’m not going to get into the details of how asynchrony is important for a server application because I have tried to do that several times. Let’s stick with the topic: why am I not using NancyFx instead of ASP.NET MVC / Web API? Don’t get me wrong here. NancyFx is a great framework as far as I can see and I’m all supportive for any .NET open source project which makes it easy to get our job done. @TheCodeJunkie and the other NancyFx members have been doing a great job on maintaining this awesome open source framework. However, there is a very important missing part with this framework and it’s vital to any server application: asynchrony! We are now about to see why this is important.

I have created two applications which do the same thing in a different way: downloading the data over HTTP and return it back as a text. I used NancyFx to create one of these applications and this application will make the HTTP call synchronously because there is no way to do it asynchronously with NancyFx. The other application has been implemented using ASP.NET Web API and the only difference will be that it will make the HTTP call asynchronously.

It’s fairly straight forward to get started with NancyFx. I jumped to one of the framework’s documentation page and I was good to go by installing the NuGet package and adding the following module. It was a nice and quick start.

public class HelloModule : NancyModule {

    public HelloModule() {

        Get["/"] = (p) => {

            using (var client = new WebClient()) {
                var textData = client.DownloadString("http://localhost:52907/api/cars");
                return textData;
            }
        };
    }
}

I used WebClient on both applications here because HttpClient has no synchronous methods and making blocking calls with HttpClient has some overheads. I also created an ASP.NET Web API application which does the same thing but asynchronously.

public class DefaultController : ApiController {

    public async Task<string> Get() {

        using (var client = new WebClient()) {

            var textData = await client.DownloadStringTaskAsync(
                "http://localhost:52907/api/cars");

            return textData;
        }
    }
}

As you can see, it’s extremely easy to write asynchronous code with the ".NET 4.5 + C# 5.0 + ASP.NET Web API" combination. You probably noticed that I am making a call against http://localhost:52907/api/cars. This is a simple HTTP API which takes minimum 500 milliseconds to return. This wait is is on purpose to simulate a a-bit-long-running call. Let me also be clear on why I’ve chosen to make a comparison by making an HTTP call. This really doesn’t matter here. Any type of I/O operation could have been a perfect case here but an HTTP call scenario is simple to demonstrate.

Finally, I now have an endpoint on http://localhost:47835 for NancyFx application and another on http://localhost:49167 for ASP.NET Web API application. I have opened up a command line console and get the ab.exe (Apache HTTP Server Benchmarking Tool) under my path. When I generate a request for each one (only one request), I will have a result which is similar to the below screenshot (NancyFx is the lest side, ASP.NET Web API is the right side).

image

Notice that both have taken approx. the same amount of time to complete the request but this’s not the place where asynchrony shines. Let’s now generate totally 200 request (30 concurrent requests at a time) to each endpoint and see the result (NancyFx is the lest side, ASP.NET Web API is the right side).

image

15.31 requests per second with NancyFx + synchronous processing and 49.35 requests per second with ASP.NET Web API + asynchronous processing. Besides the fact that this’s totally an on-the-fly benchmarking (I’m not even sure whether we can call this a benchmark) on my Windows 8 machine, the result is pretty compelling.

Let’s now have a look at the reason why I stopped discovering NancyFx further. Go to NancyFx GitHub repository and navigate to Nancy.Hosting.Aspnet.NancyHttpRequestHandler class file. This is located under the ASP.NET host project for NancyFx and actually the HTTP handler the framework uses to process requests. Earlier today I tweeted after I had a look at this class:

image

Yes, it’s sitting right there. By exposing the framework with a normal handler implementation instead of the IHttpAsyncHandler implementation, you are making your ASP.NET framework suffer. It’s possible for you to handle synchronous calls with an asynchronous handler but it’s impossible (or either not right and easy) to do this with a normal handler. On the other hand, we know that NancyFx doesn’t only have an ASP.NET host option. You can even host this framework under katana with its OWIN Host implementation but it’s not going to matter unless the framework itself has asynchronous processing capabilities and by looking at the above handler and this issue, I can see that it doesn’t have that.

This is not an I-hate-you-and-I-will-stay-that-way-forever-please-go-the-hell-away blog post. Again: NancyFx is a great project and it deserves a good amount of respect. However, this post explains my reason on why I am not using NancyFx instead of ASP.NET Web API or ASP.NET MVC. Will it going to change? Unless #148 is not fixed, it is certainly not. Even if it is fixed, I already have applications running on ASP.NET Web API and ASP.NET MVC. Why bother then? We will see that in the future.

SignalR - Real-time Web Applications Webcast Recording (In Turkish) is Available

SiganlR - Real-time Web Applications webcast recording (in Turkish) is available. The video is available on NedirTV and Vimeo.
2012-11-14 08:57
Tugberk Ugurlu


A week ago, we tried to organize a webcast on ASP.NET SignalR and the network connection was very poor again. So, the participation was low but I managed to record it successfully. The video is now available on NedirTV: SignalR - Gerçek Zamanlı Web Uygulamaları.

Source code is also available under my GitHub account: https://github.com/tugberkugurlu/SignalRWebcast201211

You can also watch it on Vimeo:

SignalR - Gerçek Zamanli Web Uygulamalari from Tugberk Ugurlu on Vimeo.

Enjoy Smile

Advanced ASP.NET Web API Webcast Offline Recording (In Turkish) is Available

Advanced ASP.NET Web API Webcast Offline Recording (In Turkish) is Available
2012-11-07 09:27
Tugberk Ugurlu


A week ago, we tried to organize a webcast on ASP.NET Web API but there were a few problems with the network connection. It didn’t go that smoothly as you can imagine but I have provided the slides and the full source code of the webcast content earlier. During the last weekend, I recorded an offline video for the same topic (In Turkish) and it’s now available on NedirTV: Ileri Düzey ASP.NET Web API

You can also watch it on Vimeo: https://vimeo.com/52841179

İleri Düzey ASP.NET Web API from Tugberk Ugurlu on Vimeo.

Enjoy Smile

Note:

Why am I writing this in English if the content of this recording is in Turkish? Well, I don’t have a Turkish blog yet and I really don’t want to mix languages inside the current one Confused smile I plan on opening up a Turkish blog, too. Not sure when, though. So, stay tuned Surprised smile

Advanced ASP.NET Web API Webcast Slide and Codes

The slide and the full source code of the Advanced ASP.NET Web API webcast (Turkish) is available.
2012-11-02 07:07
Tugberk Ugurlu


The full source code of the Advanced ASP.NET Web API webcast (Turkish) is now available on GitHub: https://github.com/tugberkugurlu/AdvancedWebAPI

The slide of the webcast is also available is also reachable from the following link: https://speakerdeck.com/tourismgeek/ileri-duzey-asp-dot-net-web-api-tr

ASP.NET SignalR Alpha 1.0.0 is Now Available!

Couple of hours ago, @DamianEdwards has announced that ASP.NET SignalR Alpha 1.0.0 release is now publicly available! Even better! SignalR has just shipped with ASP.NET Fall 2012 Update!
2012-10-31 23:31
Tugberk Ugurlu


Couple of hours ago, @DamianEdwards has announced that ASP.NET SignalR Alpha 1.0.0 release is now publicly available.

You can now get the SignalR into your web project through NuGet with the following command:

PM> Install-Package Microsoft.AspNet.SignalR -Pre

Even better! SignalR has just shipped right out of the box with ASP.NET Fall 2012 Update! I tried to have a quick view of what has added and changed. In this post, I will share just a few of them.

When you install the package, you will get the most of the usual stuff.

image

There is one more thing that I haven’t see before (not sure if this has been there with 0.5.3 release). The project is no more registering itself invisibly and RegisterHubs class accomplishes for us.

image

The one other thing that I fell in love with is to be able to return a Task or Task<T> from the hub method! This is a killer feature! Again, I am not sure if this was on 0.5.3 release but I am glad this is now there!

image

And here it is! We have been all waiting for this one Smile We now have an AuthorizeAttribute Smile

image

This attribute implements IAuthorizeHubConnection and IAuthorizeHubMethodInvocation interfaces to be recognized as an authorization attribute. So, this means that you can provide your own! If you are familiar with ASP.NET MVC or ASP.NET Web API, the concept here is the same. However, the interface methods return bool to signal the caller if the call is authorized or not. I would really love to be able to return Task<bool> here or have a similar filter model as ASP.NET Web API. Keep in mind that these are authorization points and they are not meant to be used to perform authantication. SignalR completely leaves the authantication to the underlying hosting layer.

I’m sure there are other features but it is 03:24 AM here and my eyes are closing Smile So, it is enough for now. Big thanks and kudos to @davidfowl and @DamianEdwards for the Alpha release and for bringing this such a great framework to life.

If I were you, I would go to SignalR Github repository and start exploring the samples. They are awesome and cover the new stuff. Also, @DamianEdwards and @davidfowl has a //Build talk tomorrow which will be streamed live: http://channel9.msdn.com/Events/Build/2012/3-034 Don’t miss that one!

More Information