Comment by peoplefromibiza | Hacker News Reader

Comment by peoplefromibiza | Hacker News Reader

Parent Full thread

peoplefromibiza

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

> 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

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

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.

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?

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/

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

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.

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.

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/

Reply on news.ycombinator.com