> REST is request -> response, single connection, one direction only, which is a very limited way to model messaging
You seem to be implying that being limited is a bad thing. Constraints are important to keep problems tractable.
You seem to be implying that being limited is a bad thing. Constraints are important to keep problems tractable.
it is, when the limits are a bad thing.
Imagine if houses could only be built in the shape of a cube, because someone decided that the cube is the perfect shape for something else entirely.
HTTP has its place, REST has its place, messaging is a lot more than REST though.
It's always been, even before HTTP was invented.
Using REST for everything is the textbook example of if all you have is a hammer, everything looks like a nail
A lot of those failures won't even be detected, because you don't have proper monitoring, whereas in sync world you fail early and loudly.
And instead of "we had a downtime" you can sugarcoat it as "we had a processing delay". What's not to love?
You shall obviously set up monitoring of the MQ and all its DLQs. Once you've done that, you will literally never have a failing processing flow that isn't caught. A successfully initiated Mats Flow will either run to completion, or it will DLQ. Guaranteed.
The MatsBrokerMonitor is a Mats-specific such monitor (compared to the generic monitor ActiveMQ comes with). The pages here are a bit lacking, but it at least explains a bit: https://mats3.io/docs/matsbrokermonitor/
Proper monitoring typically requires application specific details and logic, which queues, being a dumb bus, typically don't have.
E.g. your client has a scheduled downtime every midnight, so you want your monitoring to not alert on messages produced by account X between 00:00 and 02:00. Oh, and ideally these exclusion rules are set up by non-technical folks (maybe even by customer himself).
At least this limitation can cause massive complexity once perf optimizations are needed. I think that’s important to factor in when we’re talking about the issues with large and resilient systems in either paradigm.
Personally I like message passing because it’s more true to the underlying protocol (TCP or UDP) and actually interops quite well (all things considered) with request-reply systems - it just requires two separate messages and a request id which is standard practice in request-response anyway. The inverse is not true though: we have like 10 different hacky solutions in the last decade for sending server initiated messages to clients.
Wrt. returning a Future, this is what the MatsFuturizer does, giving you a sync-async bridge into the "Mats fabric": https://mats3.io/docs/sync-async-bridge/