3 ms·

> 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

> 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/
      - hbrn 4y ago
        The major problem with dead letter queues is that people naturally end up mixing recoverable and non-recoverable errors together, which results in all errors being ignored. 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).

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/
    - hbrn 4y ago
      The major problem with dead letter queues is that people naturally end up mixing recoverable and non-recoverable errors together, which results in all errors being ignored. 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).