Question

I have been using Rx for a little bit now to create an event bus (think CQRS/ES) within a single application, and it seems to work great. However, after surveying a bunch of different Event Sourcing frameworks, I have not seen Rx used once. It seems like a really good fit as opposed to a reflection/container based dispatcher, but perhaps there is something I am missing. I’d rather not spend a bunch of time on something that has a showstopper 3 months in. Is there a reason why Rx isn’t a good fit?

Thanks,
Erick

Answer 1

Rx is very definitely a fantastic framework for event-driven and reactive programming in general. In fact, I would say that limiting yourself to IObservable interfaces for dispatching is actually better form than anything more heavy weight. You are then naturally using a ‘messaging’ oriented style, which lends itself well to scale and immutability. Separation of concerns becomes natural.

The area in which you may struggle in future is if your systems extends beyond a single application. Rx is very simple within a single application, but requires some effort as soon as you need to add ‘infrastructure’ between your applications. Not that it doesn’t work! It does, as you plumb in different sources for your Subject and IObservable instances – it just needs to be done manually in some cases, whereas other ‘event sourcing’ frameworks (what did you have in mind?) may have a bigger range of external ‘adapters’.

About Rx being used in this way in general (ie, on the internet). First, remember that there are many other platforms than just .NET and Rx will not show up in any of them. The reactive style might, under a different name.

Secondly, you – are – not – alone. Including someone who likes Rx so much for CQRS they want to do it in Scala and the JVM!