Feedback from commandhandler about bus

[adenhertog]

Hi @r3dsm0k3

Thanks for your feedback. Your current workaround is probably the simplest, though it does bypass the bus entirely. When using it, the library needs to be agnostic around its environment. The problem when trying to invoke a callback when the command finishes comes down to not being guaranteed where the command gets executed.

The command handler could be on another instance of the API, or could be sitting in a separate application service. In theses cases your command would leave the current node, traverse the message transport, be processed at some point (depending on the load of your message handling service) and an event/reply emitted.

Once the event is emitted, there's no way to ensure that the originating API instance will be the one who receives it - at least not in a pub/sub style setup. One way to achieve this is to enhance the library to support private ephemeral queues and enable a replyToSender() function. This would allow a command handler to directly send a response to the sender of the command by placing the response in the sender's private queue.

The idea of a callback passed into send() would work fine for a single-instance of a memory-queue, but the ultimate goal of this library is to provide the same functionality regardless of the size or setup of the underlying services.

I'll use this ticket to track .replyToSender() and .replyTo() functionality

[psaunders]

@adenhertog this would be awesome, I'm building a very API centric tool so it'd expand the places I can use this from a bit of the deep backend to almost all of it.

[adenhertog]

Hey Ajith,

I think here you're talking about the request-response pattern of EIP messaging, ie: https://www.enterpriseintegrationpatterns.com/patterns/conversation/RequestResponse.html. This library has currently only implemented a pub-sub style so there's no way to await a bus-based response directly.

Implementing something like this wouldn't be too difficult and using it would be pretty similar to your example.

There may be an alternative depending on what's requesting your API. If your consumer is a web front end, would it be feasible to subscribe the resulting event via a websocket?

[r3dsm0k3]

Hi @adenhertog , thanks for the quick response.
I'm building a graphql api, which maybe consumed by web frontends or desktop applications or mobile apps. In this case, I'm registering a user and there's no way to respond with an error/registered user's uuid. We'd have to have another query for this. As I said, I currently work around this with not using the commandbus, but instead calling the commandhandler directly. From the library I'm only using the eventbus and the DDD modules. It would be really great if I could use all the features if there was a work around.

How about handing in an optional callback function along with the .send() ? It could get triggered after all the registered handlers have finished processing the message and bus can invoke it.

[manarhusrieh]

Recently, I have applied a similar approach using Web sockets with the service bus. The command handler at the end of its execution would send a message through web socket and the API would wait for this message from web socket to resolve the promise.