A buddy of mine told me in the past he had looked at ServiceStack. Said it looked good but that it had no async support so in his book, it\'s not an option to use this fram
The most requested feature, Server-side async support has been added where HttpHandlers in ServiceStack now inherit from a common HttpAsyncTaskHandler
base class that implements IHttpAsyncHandler
. This lets you return an async Task from your Service in any number of ways as shown in http://bit.ly/1cOJ3hR
E.g. Services can now have either an object, Task or async Task return types that can return a started or non-started task (which we'll start ourselves). This transition went as smooth as it could where all existing services continuing to work as before and all tests passing.
In matching the new server-side async story and now that all projects have been upgraded to .NET 4.0, all Service Clients have been changed to return .NET 4.0 Task's for all async operations so they can be used in C#'s async/await methods. Some examples of Async in action: http://bit.ly/17ps94C
The Async API's also provide a OnDownloadProgress callback which you can tap into to provide a progress indicator in your UI, E.g: http://bit.ly/19ALXUW
Async overloads have also been added to HTTP Utils which provides a nice API for calling external 3rd Party (i.e. non-ServiceStack) HTTP Services.
Not sure what real-world measurements has led to the conclusion that Async is mandatory for maintaining a high-performance system, given a good caching strategy will provide better performance than Async can. There are a number of high-performance services and websites that doesn't use async, e.g. YouTube is built with 1M lines of blocking Python to handle 4 Billion views a day, more recently Disqus posts how they got Django (a heavy Python Web framework) to scale to 8 billion page views by leveraging HTTP Caching. For most multi-threaded sites/services (e.g. .NET/Ruby/Python), blocking IO is the norm, not async - which like all premature optimizations should be measured to calculate if it actually yields any end-user/utilization benefits.
StackOverflow itself is a ASP.NET MVC Website which uses the standard Synchronous MVC Controllers and employs a good caching strategy that utilizes both local and distributed caching and makes use of ServiceStack's JSON serializer. So even using synchronous MVC controllers StackOverflow has extremely good server utilization for handling 95M page views/month. StackOverflow Careers 2.0 is what uses ServiceStack and its RedisMQ support for all its BackOffice operations.