ServiceStack vs NServiceBus [closed]

Question

I just began looking into ServiceStack and WOW, I might as well throw WCF out the window, but it can also send out messages using Redis.

I'm familiar with NServiceBus and it's also used for sending messages and having pub/subs. Since ServiceStack is a web service, you can open it up for external clients; I don't think NServiceBus can do that.

Other than that, what are the pros/cons of choosing one of these technologies over the other? What are some scenarios where one technology might be preferred.

Willywillynilly

I NServiceBus you can use the Gateway to expose an endpoint over HTTP, NServiceBus has the Saga feature and the Particular Platform (ServicePulse and ServiceInsight), using MSMQ as a transport you gain durability, scalability all in a transactional environment... DISCLAIMER: (I'm of course biased as I work for Particular and have been using NSB for the last 6 years) – Alluvial

Answer 1

Having no knowledge of how ServiceStack does pub/sub with Redis beyond what is in the docs, it appears that it is just providing a fairly thin wrapper around the Redis pub/sub API.

NServiceBus (of which I am the original author) has a deeper architectural philosophy around pub/sub, including requiring the declaration of proper message contracts, clearly delineating commands from events, not allowing the publishing of commands, stronger recommendations on deployment topology where each logical endpoint is mapped appropriately to physical hosts when scaling out, and more.

If I had to sum it up, it appears that the pub/sub in ServiceStack is more of a library whereas NServiceBus is more of a framework. Once you include the rest of the tooling that @sean-farmer mentioned in his comment, then the divide grows even larger. Of course, this being my inherently biased opinion based on minimal understanding of what's available in ServiceStack and would love to hear comments from its author.

I'd also suggest looking at this Stackoverflow answer about NServiceBus vs MassTransit.

One last comment, NServiceBus supports multiple transports like RabbitMQ, Azure Service Bus, and even SQL Tables - not just MSMQ. There do appear to be some community-level activities on a Redis transport for NServiceBus as well: https://github.com/mackie1001/NServicebus.Redis

Sheldonshelduck

Answer 2

I think you'll find it difficult to compare and contrast 2 fairly different Technology Stacks with different goals/focuses. Never having used NServiceBus I wont be able to comment on its Features/Strengths - I invite you to evaluate both to determine which is the most suitable for your use-case and which one you enjoy developing with more - given they have largely different feature-sets, another option to consider would be using both, complimentary together.

ServiceStack Core Goals and Features

As the project lead for ServiceStack I can only speak to ServiceStack's core goals/focus which aims to simplify development and maximize end-to-end productivity with a core focus on reducing artificial complexity:

Reduce Artificial Complexity and Maximize Utility

One of the ways it reduces cognitive load is by promoting a single flexible and versatile approach to developing Services, promoting remote services best-practices with a message-based design by simply designing your Services around accepting and returning clean POCO Data Transfer Objects (DTO's) (but can also return any custom media type or binary/image responses).

By using well-defined POCOs to define your Services Contracts, ServiceStack is able to infer a greater intelligence about your Services and automatically provide a range of Metadata features including built-in Metadata Pages with links to XSD's, WSDLs and Plugins like Postman and Swagger UI Support. ServiceStack's also able to enable RDBMS-driven Services with AutoQuery from just a Request DTO definition which is how Stack API's can provide all its Search functionality, using a single Request DTO.

End-to-End productivity

Having a clean separation of DTO's from your Service implementations is what allows you to be able to share your server DTO's on the client for an instant end-to-end typed API without code-gen. Alternatively if preferred, clients can, with just a url, Add a remote ServiceStack Reference to generate typed DTO's for C#, F#, VB.NET and TypeScript clients.

Maximize Re-use

ServiceStack is able to maximize the re-use and utility of your Services where ServiceStack Services are able to be consumed via an array of built-in fast data formats (inc. JSON, XML, CSV, JSV, ProtoBuf and MsgPack) as well as SOAP endpoints and MQ Hosts.

Your same Services also serve as the Controller in ServiceStack's Smart Razor Views reducing the effort to serve both Web and Single Page Apps as well as Rich Desktop and Mobile Clients.

Messaging Features

For Messaging Features, ServiceStack provides a clean Messaging API where your Services can be consumed via Rabbit MQ, Redis MQ and In Memory MQ hosts. Although as the Messaging API re-uses your existing Services it follows the same Request/Reply MQ pattern.

Separate to the Messaging API, ServiceStack provides a Redis Pub/Sub Server library which is what powers Redis Server Events and Redis MQ. The Pub/Sub features also extend to ServiceStack's Server Events which provides real-time features to Ajax/JavaScript and .NET ServerEvents Clients allowing you to easily build rich, live Web Apps like React Chat and jQuery Chat (in less that 200 lines of JS).

Illuminance