-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feedback from commandhandler #36
Comments
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? |
Hi @adenhertog , thanks for the quick response. How about handing in an optional callback function along with the |
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 The idea of a callback passed into I'll use this ticket to track |
@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. |
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. |
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.
Thanks and looking forward to your suggestions.
The text was updated successfully, but these errors were encountered: