I had never heard of ServiceStack before I started evaluating frameworks. I cannot remember exactly how I bumped into it, but seem to recall that it was while reading about performance. Service claims to be the most performant of the frameworks due to its serialization library ServiceStack.Text. Since I am no performance monkey and I have not run nor reproduced any perf tests, I won’t say it is not the fastest. But I can say it is fast enough.
ServiceStack is more than a web framework. It is a complete ecosystem for an end-to-end development experience of server applications: including a micro-ORM for dealing with relational databases, a Redis client for the noSQL world, logging, caching and probably some more stuff I am not aware of. In my case it was enough to install the ServiceStack.Host.AspNet package to bring everything I needed and a little more.
Once installed the package, deleted a bunch of
junk “unneeded guidance” artifacts and remove unrequired library references one has everything one needs to start.
The documentation page is pretty extensive. As well as the number of sample projects. Likewise, there is a separate documentation page for the auxiliary projects. It is no-nonsense documentation, straight to the point with a pretty complete walk-through and plenty of examples.
Besides, the community seems to have quite a few users and they seem to get their questions answered.
My impression is one of a healthy community
And for once, services are called services. Yay!
Creating a working service is, once again a two-step process:
- Create the application host and configure it when the application starts. If this step is skipped, an exception is raised, but it tells exactly what the problem is, and points out a possible solution for the problem. One thing to point out is that hosting ServiceStack in ASP.NET takes a dependency on WebActivator, so instead of touching the
global.asaxcode-behind one can create classes in the ~/app_start subfolder and they will be invoked at the specified moment of the life cycle of the application.
- Create a service, which is a class that implements
TRequestDtois the type that represents the resource (a Data Transfer Object) we want to make available through our service. Routing options are defined using the
RestServiceAttributeattribute in the
TRequestDtoclass, as well as the verbs that the service will respond to. And if the response data transfer object is named after the
TRequestDtowith the Response appended, good things will happen by default in terms of documenting your service (more on this later). One thing to mention is that ServiceStack makes merging the information from the route and the body of the request completely transparent: if the information can be shaped into a property of the request object, it will end up there, regardless of the source. The
IRequiresRequestContextis not required, but giving access to the populated request object is a very good idea if we need anything else than the
TRequestDtoinstance (headers, query string, …)
ServiceStack shines in many aspects (active development, simple, powerful, fast,…). But sometimes, little details are what makes you stand above the rest. In my case I was completely sold by the out-of-the-box support for multiple formats, including SOAP (which make some API consumers happy, let’s pray for their souls) and the auto-documentation of the contracts. Those features and the simplicity in which I could plug in custom basic authentication was the reason why I chose this framework for my customer’s service, regardless of its less than sub-par HTTP fidelity (to them their own, OpenRasta is really the best I have seen so far in that respect)
And I have to say I have not regretted the choice… yet