CreateRequestClient vs. CreatePublishRequestClient

[colin-young]

In https://github.com/MassTransit/Sample-RequestResponse/blob/master/src/Client/Program.cs#L63, why is CreateRequestClient being used instead of CreatePublishRequestClient? I recently ran into some difficulty due to the difference: http://stackoverflow.com/q/42496157/173225

My understanding is that as presented it assumes that there is either only a single subscriber to the published message or we don't want any other subscribers to be notified. Both options appear to go against what I'd consider a best-practice when developing a pub-sub system, which is: don't assume anything about how many subscribers a given message may have. Even if you know there is only one today, that may not be true tomorrow.

[phatboyg]

Because commands are different than events -- events are meant to be consumed by multiple observers whereas commands are meant to be processed once, rather than by a bunch of separate consumers.

A service typically owns the command contract, whereas an event producer owns the event contracts. Therefore, it makes sense that multiple observers would subscribe to the event - it's still owned by the event producer.

A command, on the other hand, being owned by the service, should not have that same contract used by another service -- particularly one that does something different. Contract reuse almost never makes sense, and leads to confusion and unexpected outcomes down the road when new engineers pick up the codebase.

Does this help clarify the distinction?

[colin-young]

It makes sense now, but it's definitely a barrier when trying to learn MassTransit, especially when approaching it from one side (publish) and all the examples are from another (command). Would you be interested in a PR that adds a publish sample to highlight the distinction? And, perhaps more importantly, documents the existence of CreatePublishRequestClient. At the moment the documentation for CreateRequestClient is:

Creates a request client that uses the bus to retrieve the endpoint and send the request.

and for CreatePublishRequestClient it is:

Creates a request client that uses the bus to publish a request.

which might be better as:

Creates a request client that uses the bus to retrieve the endpoint and sends the command to the specific endpoint.

Creates a request client that uses the bus to publish an event which is broadcast to all subscribing consumers.

CreateSendRequestClient would be even better, but a breaking change.

[phatboyg]

The documentation update is fine, but changing method names isn't really useful. I still object to the use of the publish request, but I get why people use it. In a later version of MT, we'll be adding routing so that the request client can just use the routing rules to find the consumer for the command without the need to just publish and be smart enough to only have a single consumer for that message type.

[colin-young]

I wasn't suggesting that method names should actually be changed (mostly because of the breaking bit of it).

So maybe I'm abusing MassTransit instead of using it. Here's my scenario:

1. Client POSTs object to API
2. API publishes new object event to MT which is handled according to the registered consumers
3. API gets Id of created object
4. 201/Created response is returned to client with location of new resource

In step 2 I don't care about who is consuming it, just that I am guaranteed to get some sort of response telling me whether or not the request was successful and where to find the new resource. At some point in the future I may have additional services that are interested in knowing about those events (e.g. Wiretap). It seems there are 2 ways to handle that:

1. add additional subscribers (an indirect implementation of a wiretap)
   • pros: can run in isolated process, queues can hold messages even if subscriber is offline
   • cons: not really a wiretap, just an equivalent outcome
2. use observers (a more direct wiretap implementation) to publish the messages to a different queue
   • pros: a more direct realization of the wiretap intent
   • cons: needs to run in the same process as the consumer. Can be worked-around with reflection, Autofac, etc, but more complex deployment

After working through this, I'm coming round to thinking that what I should be doing is:

1. Client POSTs object to API
2. API sends new object command
3. API gets Id of new object/sends 201/Created to client
4. MT publishes NewObjectCreated event
   1. 0..n subscribers to NewObjectCreated event get notified and do their thing

(Not totally sure on order of 3 and 4, but I don't think that's important to this discussion.) Because I'm expecting a response, there should really only be one consumer, otherwise which consumer is producing the response I'm looking for? Is that why you object to the publish request, that people are conflating events and commands? In that case, it would be helpful to update the documentation on Request-Response to cover some pitfalls. I'd be happy to help out with that.