OWIN compatible ServiceStack
With the OWIN specification being final, it seems like support is bound to happen sooner rather than later.
I believe some effort was made a couple of year https://github.com/ServiceStack/ServiceStack.Owin).
Whilst this feature requested OWIN support, it really wanted better integration with the external ecosystem outside of ASP.NET Handlers.
This is now resolved with .NET Core which has become the future Web Platform for .NET which as part of its design supports the integrations that OWIN was created to enable.
We’re happy to announce that ServiceStack now supports running on .NET Core where it now can happily co-exist with external frameworks, e.g. you can host ServiceStack + MVC together in the same default route space without being forced to mount ServiceStack at a custom `/api` route.
For more details on ServiceStack’s support and integration with .NET Core please checkout the full release notes: http://docs.servicestack.net/releases/v4.5.2.html
As this feature request was quite contentious I want to leave my closing thoughts on our hesitance to support OWIN:
With .NET Core it’s clear OWIN was the wrong HTTP abstraction to adopt, after going through a lot of churn over several years it was still left with an unproductive dev model that now suffers an abstraction penalty under .NET Core which requires an additional dependency to emulate on top of .NET Core’s native HTTP Abstractions.
In contrast ServiceStack’s .NET Core support doesn’t require any additional dependencies and binds directly to .NET Core’s native HttpContext / HttpRequest / HttpResponse Types adopting the same approach with how support for ASP.NET and HttpListener was implemented.
It also allows us to seamlessly integrate directly with .NET Core where ServiceStack’s HttpHandlers can be reused and registered as .NET Core modules directly, e.g:
-
My only concern is to provide the most productive services framework that effortlessly caters for the most common use-cases. ServiceStack already provides a highly configurable flexible and configurable stack with 14 stage customization pipeline as listed in: https://github.com/ServiceStack/ServiceStack/wiki/Order-of-Operations
There is no swiss knife solution with SS/IIS, it's just a 1-line configuration to tell ASP.NET to route all requests to ServiceStack, from there you use ServiceStack's pipeline which is already highly-customizable, fine-grained, consistent, composable and logical.
Every single feature has a complexity cost, and OWIN/Katana is no different, having looked at OWIN, I find it hard to believe simplicity was even a goal. I try very hard to contain the complexity of building services under a simple and consistent conceptual model - the primary benefits and overwhelming feedback is that ServiceStack is simple and effortless to use - that is no accident, I consider each feature very carefully to make sure it makes sense for ServiceStack, strengthen's the mental model, and doesn't cause any un-necessary confusion or introduce any un-necessary complexity.
I'm in no hurry to release the confusion of a competing/contradicting way of customizing ServiceStack. I personally have little interest in adding technology for technology-sake, which is why I require every feature to backed by end-user benefits and real-world use-cases so we know exactly what we're optimizing for and can then evaluate whether there are better ways to achieve it. When I have all the information and potential benefits, I'll decide whether the feature is worth the complexity cost or not.
-
Dimitar commented
Hey Demis,
Let me help out Serge by saying the following:
We all would like to be able to do REST development in a fast and efficient way. In other words what I am saying is that despite all the goodies and the easiness of work, you need to improve sorts of speak the "Low Ceremony" index or Service Stack. What I would like to see is to be able to use a middleware implementation like Katana, instead of a 'swiss knife' solution like IIS. Please consider the fact that writing the code is a descent part of the game, but deployment, testing, configuration and change management and support (of the application) later add significantly to the total cost of ownership (TCO). That being said, the option to use middleware and all that comes with it looks like improvement of the TCO to me. Let me know if you think different. -
Can you also provide the end-user benefits you'd like to see available in ServiceStack and not just the technology, thx.