4 ms·

As a fan of .NET Web API and having not worked with ServiceStack may I ask what I am losing by not embracing ServiceStack?

by tucaz 10y ago

jmkni 10y ago
I'll do my best to explain! I feel as though ServiceStack was built from the ground up to be a framework for building a Restful API, whereas Web API feels like more of an afterthought to MVC. If you follow the best practices, you end up with a well structured API from a programming perspective. - http://stackoverflow.com/a/15235822/969613 http://stackoverflow.com/a/15235822/969613 It's opinionated, and a result you have a clearly defined place for your services, your request/response DTO's, your logic etc. It's all very loosely coupled and testable which I like. In contrast, Web API doesn't make it clear how to split up your MVC controllers and your API controllers. You are kind of left to your own devices, and I find that every developer comes up with their own system, and every Web API project is structured differently. With Web API, you also tend to keep all of your API controllers, models etc in the same project, which I think can become more difficult to maintain over time, and is also harder to write tests for. For dependency injection, it comes out of the box with Funq, which I find to be really capable, but you can use any other DI framework, and it's simple to swap out Funq for your preffered DI framework. For ORM, ServiceStack provides OrmLite.net, which I find to be fit for purpose most of the time. If you need the more powerful Entity Framework, that's easy to swap out too, but I find OrmLite to be fast, and easy to work with. For caching, you can easily pull in Redis, and use it instead of ram for storing user sessions. There's a bunch of authentication providers, you can add authentication for Google/Facebook/Linkedin/Github etc etc with one line of code, then just the configuration with the third party. - https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization https://github.com/ServiceStack/ServiceStack/wiki/Authentica... One thing I really like is validators. I know in Web API you have attribute validation on models, but validators in ServiceStack give you a lot more control. They allow you to intercept an API request before you even hit the service, and apply any logic/rules you need to. Swagger is easy to configure too, basically one line of code and then drag and drop the Swagger HTML/CSS/JS, and it works. You can also document swagger using attributes on your DTO's in C#. It has a built in Mapping library, a built in JSON parsing library (which is faster than Json.net), and logging is easy to do as well. The developers are really good too. Literally any problem you come across, you will find a well thought out StackOverflow answer by one of the main developers, usually Demis (mythz). I'm probably not explaining this very well! Maybe somebody more articulate than myself will come along and provide a better answer, but I recommend checking it out. It's massive (they call it ServiceStack because it is literally a stack of services) and when I need to use Web API, I just find it extremely lacking in comparison. Hope this helped!
- pbz 10y ago
  A lot of what you described is in the new MVC Core. It would be interesting to see a comparison with Core.
  - jmkni 10y ago
    I'd be keen to see that too. The last time I looked at Core, I couldn't even add authentication to endpoints on a pure Web API project, that was a couple of beta's back though, hopefully it's gotten better.
- ct520 10y ago
  Awesome response! Thanks, Think I'll take a look at it more in depth tonight!
- Scarbutt 10y ago
  For building a HTTP API why would you tie yourself to a closed source non-free framework when there are so many good alternatives out there? besides dealing with the servicestack licensing you now have to deal with all the windows licensing too. I mean, I doubt it has some secret sauce that makes it better over everything else for building a REST API.
  - layoric 10y ago
    ServiceStack isn't closed source, framework, IDE integrations, client libraries all on GitHub. https://github.com/ServiceStack https://github.com/ServiceStack Licensing means there are dedicate developer resources working on regular improvements all the time. Disclaimer, I am one of those resources :). Regarding 'secret sauce', it's not a secret at all, as others have said it has a big focus on simple message based approach. Recent SO question was asked sums it up. http://stackoverflow.com/questions/36962263/can-i-use-servicestack-routes-with-method-parameters-instead-of-a-dto-class-for/36962502#36962502 http://stackoverflow.com/questions/36962263/can-i-use-servic... Edit: grammar
  - mythz 10y ago
    Whilst ServiceStack is a commercially supported product, it's not closed source. It's available under a dual commercial and AGPL/FOSS Exception (i.e. Free for OSS) licensing model and all its source code is available on GitHub. Whilst Windows is our Customers most popular platform, ServiceStack has been running cross-platform on Linux/Mono for over 5 years and we have several customers that host on Mono, e.g: http://blog.geni.us/2016/02/25/the-geniuslink-technology-stack/ http://blog.geni.us/2016/02/25/the-geniuslink-technology-sta... It requires paid full-time developers to further develop and support all of ServiceStack's 60 NuGet packages and multiple IDE tooling support. Unfortunately we don't benefit from Windows Server Licenses or Azure Hosting that's paying for development of all past and future MS frameworks which are clearly benefiting from a superior business model. A commercial license is the only way we can sustain full-time development on ServiceStack, without it it'd just end up as another Framework destined for the abandoned .NET Graveyard heap as have nearly every other .NET Web Framework before it. I believe Nancy is the only non-MS alternative Web Framework that's still actively developed with decent market share. As far as licensing models go, we aimed for the least friction option with a perpetual, royalty-free per-developer licensing model where any licensed developer can deploy anything they create with ServiceStack to unlimited Servers at no additional cost. Also all our client libraries are also free to use to consume ServiceStack's HTTP, MQ or SOAP Services giving ServiceStack Services maximum utility possible. Obviously the bar is much higher for a commercial product and we need to deliver more value and productivity to justify the cost of the License. We're fortunate that enough Customers see value in ServiceStack that lets us continue making the most productive Framework and surrounding library ecosystem we can, we're even more fortunate that we're able to be 100% focused on development, we've never paid for any marketing, never paid evangelists, never paid for referrals, never called a Customer, never attended a Tech Conference or given a talk since transitioning to a commercially supported product ~3 years ago, etc. Yet we've been bootstrapped and profitable since Day 1 - all the success we've had has been through word of mouth from Happy Customers. Whilst we realize this isn't optimal for a Commercial Company and may change in future after we've completed the development tasks we've set out to do - it means for several years we've solely been product focused and have poured all our efforts and energy on further developing ServiceStack to make it the best development platform it can be - of which we've seen nothing else like it with a lot of its key features are a natural extension possible due to its message-based Services architecture that we believe already offers compelling value and advantage over MS frameworks that you might be used to. In short, we believe ServiceStack offers productivity and value over and above its licensing cost and is the reason why our Customers see value in it.
mythz 10y ago
There's just too many features in https://servicestack.net https://servicestack.net to be able to cover cohesively in a single comment. If you're interested, I'd start with the Projects Home Page https://github.com/ServiceStack/ServiceStack https://github.com/ServiceStack/ServiceStack which tries its best to summarize its features in a short description as best it can (with links to further details). Essentially ServiceStack is built with a completely different messaging methodology and simplicity-focused mindset, a lot the benefits of its approach is covered from the docs links on the wiki: https://github.com/ServiceStack/ServiceStack/wiki#documentation https://github.com/ServiceStack/ServiceStack/wiki#documentat... Or if you prefer to see what ServiceStack looks like in code instead, checkout the small, focused and documented examples listed at: https://github.com/ServiceStackApps/LiveDemos https://github.com/ServiceStackApps/LiveDemos Disclaimer: I work full-time on ServiceStack.
pauldbau 10y ago
You get to replace the over-engineered P&P crap that is WCF, Entity Framework and WebAPI with an extremely practical, elegant, fast and no-nonsense set of libraries focused on doing their specific job extremely well. If you hate the current MS direction of having to reference a million DLLs into your project (i.e. ala NPM), then you will love ServiceStack's cleaner, less cluttered approach.
junto 10y ago
Or team have been using ServiceStack for 4 years. We are still locked into the pre-licenced version, but it delivered what we need. It is a pleasure to use. We still use Web API on occasion, but every time I have to use it in left frustrated and longing for ServiceStack instead! Big thumbs up. It is one of the best . net external libraries out there.
- partisan 10y ago
  That answers the question not at all. The question is "why would you use servicestack instead of the incumbent options?".
  - junto 10y ago
    True but I could see that various others had already explained the architectural benefits of it, do I was simply voicing our satisfaction. I suggest you give it a try. V3 is still free as in beer as far as I am aware. V4 has a commercial licence cost attached. I think it pays for @mythz to work on it full time.

As a fan of .NET Web API and having not worked with ServiceStack may I ask what I am losing by not embracing ServiceStack?

by tucaz 10y ago

As a fan of .NET Web API and having not worked with ServiceStack may I ask what I am losing by not embracing ServiceStack?

jmkni 10y ago

I'll do my best to explain! I feel as though ServiceStack was built from the ground up to be a framework for building a Restful API, whereas Web API feels like more of an afterthought to MVC. If you follow the best practices, you end up with a well structured API from a programming perspective. - http://stackoverflow.com/a/15235822/969613 http://stackoverflow.com/a/15235822/969613 It's opinionated, and a result you have a clearly defined place for your services, your request/response DTO's, your logic etc. It's all very loosely coupled and testable which I like. In contrast, Web API doesn't make it clear how to split up your MVC controllers and your API controllers. You are kind of left to your own devices, and I find that every developer comes up with their own system, and every Web API project is structured differently. With Web API, you also tend to keep all of your API controllers, models etc in the same project, which I think can become more difficult to maintain over time, and is also harder to write tests for. For dependency injection, it comes out of the box with Funq, which I find to be really capable, but you can use any other DI framework, and it's simple to swap out Funq for your preffered DI framework. For ORM, ServiceStack provides OrmLite.net, which I find to be fit for purpose most of the time. If you need the more powerful Entity Framework, that's easy to swap out too, but I find OrmLite to be fast, and easy to work with. For caching, you can easily pull in Redis, and use it instead of ram for storing user sessions. There's a bunch of authentication providers, you can add authentication for Google/Facebook/Linkedin/Github etc etc with one line of code, then just the configuration with the third party. - https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization https://github.com/ServiceStack/ServiceStack/wiki/Authentica... One thing I really like is validators. I know in Web API you have attribute validation on models, but validators in ServiceStack give you a lot more control. They allow you to intercept an API request before you even hit the service, and apply any logic/rules you need to. Swagger is easy to configure too, basically one line of code and then drag and drop the Swagger HTML/CSS/JS, and it works. You can also document swagger using attributes on your DTO's in C#. It has a built in Mapping library, a built in JSON parsing library (which is faster than Json.net), and logging is easy to do as well. The developers are really good too. Literally any problem you come across, you will find a well thought out StackOverflow answer by one of the main developers, usually Demis (mythz). I'm probably not explaining this very well! Maybe somebody more articulate than myself will come along and provide a better answer, but I recommend checking it out. It's massive (they call it ServiceStack because it is literally a stack of services) and when I need to use Web API, I just find it extremely lacking in comparison. Hope this helped!

pbz 10y ago
A lot of what you described is in the new MVC Core. It would be interesting to see a comparison with Core.
- jmkni 10y ago
  I'd be keen to see that too. The last time I looked at Core, I couldn't even add authentication to endpoints on a pure Web API project, that was a couple of beta's back though, hopefully it's gotten better.
ct520 10y ago
Awesome response! Thanks, Think I'll take a look at it more in depth tonight!
Scarbutt 10y ago
For building a HTTP API why would you tie yourself to a closed source non-free framework when there are so many good alternatives out there? besides dealing with the servicestack licensing you now have to deal with all the windows licensing too. I mean, I doubt it has some secret sauce that makes it better over everything else for building a REST API.
- layoric 10y ago
  ServiceStack isn't closed source, framework, IDE integrations, client libraries all on GitHub. https://github.com/ServiceStack https://github.com/ServiceStack Licensing means there are dedicate developer resources working on regular improvements all the time. Disclaimer, I am one of those resources :). Regarding 'secret sauce', it's not a secret at all, as others have said it has a big focus on simple message based approach. Recent SO question was asked sums it up. http://stackoverflow.com/questions/36962263/can-i-use-servicestack-routes-with-method-parameters-instead-of-a-dto-class-for/36962502#36962502 http://stackoverflow.com/questions/36962263/can-i-use-servic... Edit: grammar
- mythz 10y ago
  Whilst ServiceStack is a commercially supported product, it's not closed source. It's available under a dual commercial and AGPL/FOSS Exception (i.e. Free for OSS) licensing model and all its source code is available on GitHub. Whilst Windows is our Customers most popular platform, ServiceStack has been running cross-platform on Linux/Mono for over 5 years and we have several customers that host on Mono, e.g: http://blog.geni.us/2016/02/25/the-geniuslink-technology-stack/ http://blog.geni.us/2016/02/25/the-geniuslink-technology-sta... It requires paid full-time developers to further develop and support all of ServiceStack's 60 NuGet packages and multiple IDE tooling support. Unfortunately we don't benefit from Windows Server Licenses or Azure Hosting that's paying for development of all past and future MS frameworks which are clearly benefiting from a superior business model. A commercial license is the only way we can sustain full-time development on ServiceStack, without it it'd just end up as another Framework destined for the abandoned .NET Graveyard heap as have nearly every other .NET Web Framework before it. I believe Nancy is the only non-MS alternative Web Framework that's still actively developed with decent market share. As far as licensing models go, we aimed for the least friction option with a perpetual, royalty-free per-developer licensing model where any licensed developer can deploy anything they create with ServiceStack to unlimited Servers at no additional cost. Also all our client libraries are also free to use to consume ServiceStack's HTTP, MQ or SOAP Services giving ServiceStack Services maximum utility possible. Obviously the bar is much higher for a commercial product and we need to deliver more value and productivity to justify the cost of the License. We're fortunate that enough Customers see value in ServiceStack that lets us continue making the most productive Framework and surrounding library ecosystem we can, we're even more fortunate that we're able to be 100% focused on development, we've never paid for any marketing, never paid evangelists, never paid for referrals, never called a Customer, never attended a Tech Conference or given a talk since transitioning to a commercially supported product ~3 years ago, etc. Yet we've been bootstrapped and profitable since Day 1 - all the success we've had has been through word of mouth from Happy Customers. Whilst we realize this isn't optimal for a Commercial Company and may change in future after we've completed the development tasks we've set out to do - it means for several years we've solely been product focused and have poured all our efforts and energy on further developing ServiceStack to make it the best development platform it can be - of which we've seen nothing else like it with a lot of its key features are a natural extension possible due to its message-based Services architecture that we believe already offers compelling value and advantage over MS frameworks that you might be used to. In short, we believe ServiceStack offers productivity and value over and above its licensing cost and is the reason why our Customers see value in it.

mythz 10y ago

There's just too many features in https://servicestack.net https://servicestack.net to be able to cover cohesively in a single comment. If you're interested, I'd start with the Projects Home Page https://github.com/ServiceStack/ServiceStack https://github.com/ServiceStack/ServiceStack which tries its best to summarize its features in a short description as best it can (with links to further details). Essentially ServiceStack is built with a completely different messaging methodology and simplicity-focused mindset, a lot the benefits of its approach is covered from the docs links on the wiki: https://github.com/ServiceStack/ServiceStack/wiki#documentation https://github.com/ServiceStack/ServiceStack/wiki#documentat... Or if you prefer to see what ServiceStack looks like in code instead, checkout the small, focused and documented examples listed at: https://github.com/ServiceStackApps/LiveDemos https://github.com/ServiceStackApps/LiveDemos Disclaimer: I work full-time on ServiceStack.

pauldbau 10y ago

You get to replace the over-engineered P&P crap that is WCF, Entity Framework and WebAPI with an extremely practical, elegant, fast and no-nonsense set of libraries focused on doing their specific job extremely well. If you hate the current MS direction of having to reference a million DLLs into your project (i.e. ala NPM), then you will love ServiceStack's cleaner, less cluttered approach.

junto 10y ago

Or team have been using ServiceStack for 4 years. We are still locked into the pre-licenced version, but it delivered what we need. It is a pleasure to use. We still use Web API on occasion, but every time I have to use it in left frustrated and longing for ServiceStack instead! Big thumbs up. It is one of the best . net external libraries out there.

partisan 10y ago
That answers the question not at all. The question is "why would you use servicestack instead of the incumbent options?".
- junto 10y ago
  True but I could see that various others had already explained the architectural benefits of it, do I was simply voicing our satisfaction. I suggest you give it a try. V3 is still free as in beer as far as I am aware. V4 has a commercial licence cost attached. I think it pays for @mythz to work on it full time.