ServiceStack no server-side async support

Question

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 framework (no good if no async) and I have to sorta agree.

Unless ServiceStack has added async, not sure if this is a good choice for me.

It makes me wonder a) is stackoverflow truly using this if there is no async? b) if yes to a, then it obviously must be a highly customized version of it that probably DOES have async?

I am sure someone from stackoverflow can answer this post.

Answer 1

Server-side async was added in ServiceStack v4

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.

Task based Async in ServiceStack Service Clients

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 API's in Http Utils

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.

---

Caching provides better performance than Async

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 uses ASP.NET's Sync MVC Controllers

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.