ServiceStack does not support asynchronous server-side support

Question

A friend of mine told me that in the past he looked at ServiceStack. He said that it looks good, but it does not have async support, so in his book there is no way to use this framework (nothing good if there is no async), and I need to figure it out.

If ServiceStack didn't add async, I'm not sure if this is a good choice for me.

This makes me wonder: a) is stackoverflow really using this if there is no async? b) if so, then obviously it should be a highly customizable version that may have asynchronous mode?

I'm sure someone from stackoverflow can answer this post.

Answer 1

Server-side assistant has been added in ServiceStack v4

the most requested feature , server-side asynchronous support was added, where the HttpHandlers in the ServiceStack now inherit from the common base class HttpAsyncTaskHandler , which implements IHttpAsyncHandler . This allows you to return an asynchronous task from your service in any number of ways, as shown in http://bit.ly/1cOJ3hR

eg. Services can now have either an object, or a task, or asynchronous task return types, which can return an initial or non-running task (which we will start ourselves). This transition went as smoothly as possible, when all existing services continue to work as before and all tests pass.

Asynchronous work with tasks in ServiceStack service clients

When comparing a new asynchronous history on the server side and now that all projects have been upgraded to .NET 4.0, all service clients have been modified to return a .NET 4.0 task for all async operations so that they can be used in C # async / wait methods. Some examples of Async in action: http://bit.ly/17ps94C

The Async API also provides an OnDownloadProgress callback, which you can use to display a progress indicator in the user interface, for example: http://bit.ly/19ALXUW

Asynchronous API in Http Utils

Asynchronous overloads have also been added to HTTP utilities , which provide a good API for calling external third-party HTTP services (i.e., non-servers).

---

Caching delivers better performance than Async

Not sure which real-world measurements led to the conclusion that Async is a must to maintain a high-performance system, given that a good caching strategy will provide better performance than Async. There are a number of high-performance services and websites that do not use async, for example. YouTube is built with 1M Python lock lines to handle 4 billion pageviews per day , recently Disqus reports how they got Django (Python's heavy web infrastructure) to scale to 8 billion pageviews using HTTP caching . For most multi-threaded sites / services (e.g. .NET / Ruby / Python), I / O blocking is the norm, not asynchronous, which, like all premature optimizations, needs to be measured in order to calculate whether this really benefits the end user / use .

StackOverflow uses ASP.NET Sync MVC controllers

StackOverflow is an ASP.NET MVC website that uses standard Synchronous MVC Controllers and uses a good caching strategy that uses both local and distributed caching and uses the ServiceStack JSON serializer. Thus, even with the use of synchronous MVC controllers, StackOverflow has an extremely good use of the server for processing views / month on page 95M. StackOverflow Career 2.0 is what ServiceStack and its RedisMQ support use for all of its BackOffice operations.