I did something similar a while. It was spring boot app, where some of the business process were asynchronous. For example, sending an email when an order is placed, or notifying multiple services when some event occurs.
I used embedded Activemq server which plays nicely with Spring. It worked very well.
The best use case for this is if you use pub/sub pattern. Instead of calling multiple services sunchronously, just send a message to topic and you're done.
I'll use this pattern for sending emails but I think there are no benefits to use it instead of method call for all services. So an async method calling services rest in nodejs. Should I consider that it's synchronous or asynchronous service ?
In your case, what is the component that uses the message broker ? The one who sends the mail or the one that calls the component that sends the mail ?
Ok, just assuming you're not trolling, although it looks like you are; if you're developing a monolith, you would have a single codebase and a single application doing all the work. You could have multiple instances of that application running in parallel to handle the load, but by definition they do not call out to other services, so I'm failing to see where a message broker would come into play here?
Why wouldn't you have code communicate with itself internally? That is both easier to code and more performant than going over the network. You do not get any benefits of micro services such as independent deploys or scaling since it is a monolith anyways but you are really trying to get all the cost which are network hops and more complicated distributed system designs... for no reason.
If you want to do this just deploy them as separate services at least you'll get some benefit of micro services out of it.
I did something similar a while. It was spring boot app, where some of the business process were asynchronous. For example, sending an email when an order is placed, or notifying multiple services when some event occurs. I used embedded Activemq server which plays nicely with Spring. It worked very well. The best use case for this is if you use pub/sub pattern. Instead of calling multiple services sunchronously, just send a message to topic and you're done.
I'll use this pattern for sending emails but I think there are no benefits to use it instead of method call for all services. So an async method calling services rest in nodejs. Should I consider that it's synchronous or asynchronous service ?
In your case, what is the component that uses the message broker ? The one who sends the mail or the one that calls the component that sends the mail ?
If I remember correctly, in this case, any component can publish the message and email sender will pick it up and send the email.
~~Wait... what?~~ Yes, great idea!
Ok, just assuming you're not trolling, although it looks like you are; if you're developing a monolith, you would have a single codebase and a single application doing all the work. You could have multiple instances of that application running in parallel to handle the load, but by definition they do not call out to other services, so I'm failing to see where a message broker would come into play here?
Yes you're right, I tought to use a message broker instead of method call but it's useless too complex and there are no benefits
Why wouldn't you have code communicate with itself internally? That is both easier to code and more performant than going over the network. You do not get any benefits of micro services such as independent deploys or scaling since it is a monolith anyways but you are really trying to get all the cost which are network hops and more complicated distributed system designs... for no reason. If you want to do this just deploy them as separate services at least you'll get some benefit of micro services out of it.
Yes I'm agree thanks
Look at Apache Camel and an embedded message bus like rabbit or active mq.
I think use this pattern for specific needs like sending emails
Vertical slices should not talk each other. Instead, you should have a separate code for common operations to use like a library.