1. Anything that is connected to user interface should be synchronous by default.
2. You can't predict which parts of your system will be connected to user interface.
3. Here's the worst part: async messaging is viral. A service that depends on async service becomes async too.
You should be very cautions introducing async messaging to your systems. The only parts that should be allowed to be async are the ones that can afford to fail.
I spend good amount of time trying to work around these dumb enterprise patterns when building products on top of async APIs. You are literally forced to build inferior products just because someone thought that async messaging is so great. It's great for everybody, except the final user.
Async processing is not a virtue, it's a necessity for high load/high throughput systems.
The reason SOA failed many years ago is precisely the async message bus.
I appreciate some events can be asynchronous for clients, for example: actions taken by other users, or events generated by the system. However, I do think implementation details (using async in the server) should be encapsulated from clients: when users save a new document, it's much easier for the client to receive a useful albeit delayed response, rather than "event submitted", wait for the result on a stream. Of course, other relevant clients may need to hear about that event too. The service architecture should not affect / make-life-harder for clients.
Therefore I think disagree with both parent and grandparent comments. Use each when they make sense, not "synchronous by default" (grandparent comment, though I do think there are good points made), or "asynchronous based on service architecture" (parent comment).
> But my better solution is to pull the async-ness all the way out to the client: https://matssocket.io/
To make a point out of it: This is not event based in the event sourcing way of thinking. It is using messages. You put a message on a queue, someone else picks it up. Mats implements a request/reply paradigm on top ("messaging with a call stack").
In the interactive, synchronous situation, you do not "wait for an event" per se. You wait for a specific reply. When using the MatsFuturizer (https://mats3.io/docs/sync-async-bridge/), it is extremely close to how you would have used a HttpClient or somesuch.
MatsSocket: The Dart/Flutter implementation is used in a production mobile app. For the Norwegian market only, though.
The JS implementation is used in an internal solution.
Would have been really nice with a bit more usage, yes. It is actually pretty nice, IMHO! ;-)
> Async processing is not a virtue, it's a necessity for high load/high throughput systems.
> 1. Anything that is connected to user interface should be synchronous by default.
If everything UI is synchronous, you prevent users from acheiving high throughput. Sometimes that's fine, but sometimes it's not.
It's simple to wait for a response to a request sent via asynchronous messaging. It's not simple to split a synchronous API into send and receive parts. However, REST is HTTP and there's lots of async HTTP libraries out there.
Here’s someone who disagrees, AWS CTO Werner Vogels: https://youtu.be/RfvL_423a-I
His entire Re:invent keynote was on topic of async systems, and why you need it.
So the argument is that synchrony taken to extreme is ridiculous, therefore we need asynchrony? Sorry, but that's a textbook manipulation. Almost like he's trying to sell us something...
2. You can't predict which parts of your system will be connected to user interface.
3. Here's the worst part: async messaging is viral. A service that depends on async service becomes async too.
You should be very cautions introducing async messaging to your systems. The only parts that should be allowed to be async are the ones that can afford to fail.
I spend good amount of time trying to work around these dumb enterprise patterns when building products on top of async APIs. You are literally forced to build inferior products just because someone thought that async messaging is so great. It's great for everybody, except the final user.
Async processing is not a virtue, it's a necessity for high load/high throughput systems.
The reason SOA failed many years ago is precisely the async message bus.