4 ms·
Not really a guru, but RPC is traditionally not thought of a message queue architecture -- it's almost always built around a request-reply cycle with no queuein
by lomnakkus 12y ago
Not really a guru, but RPC is traditionally not thought of a message queue architecture -- it's almost always built around a request-reply cycle with no queueing.
Reactive Streams seems to really boil down to a push-based (Functional?) Reactive Programming (with some queueing added in in the distributed case). As Erik Meijer explains[1], it's mostly about a small extension to the "Observer" pattern which comes about if you dualize the "Iterator" pattern properly.
EDIT: In short, there's very little really new under the sun here in CS terms, but this approach seems to be going through a hype cycle at the moment.
[1] https://www.youtube.com/watch?v=looJcaeboBY https://www.youtube.com/watch?v=looJcaeboBY (I'm sure you can find other explanations, but I like Erik's.)
- noname123 12y agoThanks for clarifying RPC's specific socket-level implementation details and how Reactive Stream relates to the Observer/Iterator pattern. Tbh, I tried to use Akka and RxJava for a bit but found it to be a bit cumbersome and ended up implementing pub-sub by way of ZeroMQ and Google Protobuf. I suppose I won't be able to leverage features such as composability and filtering on the message stream though. But I didn't like how the Reactor pattern implementation was a black box where I didn't know what was going on under the hood. Wish the best of luck to both teams however.