4 ms·

> And if you're doing that, why force the client to think in terms of async messaging at all? Just let them do REST, and hide the queue under the API layer of t

> And if you're doing that, why force the client to think in terms of async messaging at all? Just let them do REST, and hide the queue under the API layer of the receiver. because REST is stupid REST is request -> response, single connection, one direction only, which is a very limited way to model messaging . There is more than one communication mode and bidirectional messaging is a thing. REST also offers no control whatsoever over the communication channel, so you are stuck with the configuration set on the server side which might or might not be correct for your use case See RSocket for an example of a message driven protocol which solves most of the shortcomings of REST on the bright side REST is also stupid simple which is why is so widely deployed, it doesn't require thinking > response, you've essentially circled back around to clients having to use a client with REST-like no, because you did not block there waiting for the timeout which defaults to 30 seconds for HTTP and even if you abandon on the client side, the server will still process the request, there's no way to abort it once it's been started.

naasking 4y ago
> 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.
- klabb3 4y ago
  In my experience the amount of serialized (network blocking) calls needed under the request reply paradigm always grows over time as the application gets larger. 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.
  - naasking 4y ago
    Request/reply is also message passing, it's just synchronous rather than asynchronous. To reduce blocking while preserving synchronous semantics, you can immediately return a future as your reply.
    - stolsvik 4y ago
      Totally agree that HTTP can also be considered message passing, just synchronous! 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/ https://mats3.io/docs/sync-async-bridge/
- peoplefromibiza 4y ago
  > You seem to be implying that being limited is a bad thing 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
  - naasking 4y ago
    This just seems like a list of platitudes lacking an actual justification. The fact is, synchronous request/reply semantics is Turing complete, as are async messaging semantics. I could can opt-in to sending an async message via a standard request/reply, but I can't opt out of it if async messages are the default. Async messages introduce DoS vulnerabilities, and even partially mitigating these introduces non-determinism, so opt-in should be the default.
    - hbrn 4y ago
      Async processing is also a great way to sweep failures under the rug. 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?
      - stolsvik 4y ago
        As the article points out, I feel that messaging really shines when it comes to failures: Instead of an - at best - WARN or ERROR log line amongst millions of log lines, the failing message "pops out" of the messaging fabric, into a Dead Letter Queue (DLQ). 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/ https://mats3.io/docs/matsbrokermonitor/

naasking 4y ago

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

klabb3 4y ago
In my experience the amount of serialized (network blocking) calls needed under the request reply paradigm always grows over time as the application gets larger. 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.
- naasking 4y ago
  Request/reply is also message passing, it's just synchronous rather than asynchronous. To reduce blocking while preserving synchronous semantics, you can immediately return a future as your reply.
  - stolsvik 4y ago
    Totally agree that HTTP can also be considered message passing, just synchronous! 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/ https://mats3.io/docs/sync-async-bridge/
peoplefromibiza 4y ago
> You seem to be implying that being limited is a bad thing 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
- naasking 4y ago
  This just seems like a list of platitudes lacking an actual justification. The fact is, synchronous request/reply semantics is Turing complete, as are async messaging semantics. I could can opt-in to sending an async message via a standard request/reply, but I can't opt out of it if async messages are the default. Async messages introduce DoS vulnerabilities, and even partially mitigating these introduces non-determinism, so opt-in should be the default.
  - hbrn 4y ago
    Async processing is also a great way to sweep failures under the rug. 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?
    - stolsvik 4y ago
      As the article points out, I feel that messaging really shines when it comes to failures: Instead of an - at best - WARN or ERROR log line amongst millions of log lines, the failing message "pops out" of the messaging fabric, into a Dead Letter Queue (DLQ). 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/ https://mats3.io/docs/matsbrokermonitor/