I wanted to look into communication/decoupling patterns and how to improve them.
My current approach is to have a centralized commander in the form of an Event Bus and make him be the one to respond to most external interactions, like UI or network. Whenever a new event pops up, the receiver callback sends a signal to the bus, which spreads it to the receivers. The message contains all the contextual elements needed to respond to that signal, making the receiver orchestrator only having to deal with processing and rendering those changes.
Example: my program is connected through a socket to a live stocks
feed. Whenever a new stock arrives, it parses the payload into an
object and signals the bus with it. My current window is subscribed for that
event and whenever it gets signaled, it looks for the event payload in
its internal list and applies any value changes on screen.
One shiny new technology that’s getting attention lately is Reactive. If I understand it correctly, in this new paradigm every piece of information is considered a flow over time, in which we have an observable component that we subscribe to, and every time it gets signalled you can just process it. This observable piece of information can be referenced (injected?) in as many classes as wanted.
Are there any advantages from an architectural perspective from using ReactiveX having Buses?
5
It’s not really a question of one or the other. They can easily be combined.
The idea behind reactive streams (or whatever you may want to call them) is not exactly new in the functional world. The basic motivation behind it is to make composition easy. You can operate on streams the same as you would on values. So for example you could take the value of a text field and see that as a stream, then transform that stream by having each value be used as a search term over some search database, then transform that stream of search result lists to a stream of UI components and then just use that stream as the content of a window. So you have a lot of transformations from one data type to another, which can be written in complete isolation and then you wire that up. The contracts are pretty small. You can quite easily substitute the search term -> search result list transformation for another one, that uses a cache, or a different database or search strategy or what not.
The idea behind event buses is that events can travel pretty freely through your system and it makes it easy to plug behavior onto those events. Although that can just as easily become a big mess. In some sense you are just creating a loosely typed system here. You have no straight forward way of knowing whether events you subscribed for are ever fed onto the bus, or whether events that you trigger are ever consumed. Or whether a conflict
occurs and so on. So event buses have their strengths and weaknesses.
None the less, the two concepts are orthogonal. You can take a stream and feed it into an event bus, and you can take specific events from an event bus and produce a stream from them.
So you could say reactive streams are about how you transform data in events, and event buses are about how the events get from one subsystem to another.