Feedback from commandhandler

First of all, thank you for your effort in creating a neat library and ecosystem around it.

I was wondering if there is a way already built in to handle errors in handling a command. My api layer may send a command via the bus . Value objects are created and validated before constructing the command itself, but there may be infrastructural errors which prevents from the command to get fulfilled successfully. How do you get the command handler to send a message back to the caller that my command has failed? Currently I’m using the command handler directly in my api layer (handler.handle(MyCommand)) which is not ideal, especially since I already use the bus .

I could perhaps subscribe to the events which are produced by the commands, but that introduces bad user experience (because there’s no immediate feedback) and complicates even further imo.

So in short, is there a way to handle a command synchronously and wait for its output?

What I could imagine is the following.

try {
  const result = await this.bus.send(myCommand) 
  // the result should contain the outcome from the successful invocation of the command
} catch(e) {
 if(e.constructor === InfrastructorError) {
  // handle things
 } else { 
  // handle everything else
 }
}

Thanks and looking forward to your suggestions.

[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.