In past year or so I've been watching dozens of tech talks about reactive architectures. Most of the time I have felt inspired by them but could not quite get a grasp on what a reactive architecture is really like. Sure, the list of gained benefits such like 100x increase in response times is convincing but not having the experienced that myself, it all seems a bit vague. I need something concrete.
The funny thing is that for the last one and a half years I have been working on a message-driven, non-blocking component (service). The technology stack is at least partially modern, with AngularJS (Some might object, I know...), Vaadin with websocket push as the only server-client communication method and Akka. There is no Java EE or any heavy platform used but rather a customized version of Karaf OSGi container where we run the software as small modules. The UI is not locked at any point, the user can navigate at any time since there are no HTTP requests. Every end-user action results either to a command or a query starting from such user actions as a button click or a navigation event -> websocket -> Akka message -> some other service.
Here's the thing though. This "some other service" can be one of many other components which make up the system. Unfortunately the service is always accessed via SOAP or REST. This is where the nice non-blocking flow will terminate. While inside our component, it does not matter who will answer to the actor who has sent the command or query (we don't use ask pattern), the answering party is never the service which has actually executed the action but rather the SOAP or REST client running inside our component. That is then where we block.
There is certainly value that there is blocking only on the "edges" of the component. However here I come back to my original point of me not fully embracing the reactive architecture. It is not enough that there is one part (component) attempting to be reactive. In our case since it is responsible of the UI, it creates the illusion of a non-blocking world.
Recently three components have been added to the system, all of which handle streams of data. The most interesting one is Apache Kafka. The drive seems to be towards modernizing the architecture and there is hope for me to getting some valuable experience on a system-wide reactive design.
The funny thing is that for the last one and a half years I have been working on a message-driven, non-blocking component (service). The technology stack is at least partially modern, with AngularJS (Some might object, I know...), Vaadin with websocket push as the only server-client communication method and Akka. There is no Java EE or any heavy platform used but rather a customized version of Karaf OSGi container where we run the software as small modules. The UI is not locked at any point, the user can navigate at any time since there are no HTTP requests. Every end-user action results either to a command or a query starting from such user actions as a button click or a navigation event -> websocket -> Akka message -> some other service.
Here's the thing though. This "some other service" can be one of many other components which make up the system. Unfortunately the service is always accessed via SOAP or REST. This is where the nice non-blocking flow will terminate. While inside our component, it does not matter who will answer to the actor who has sent the command or query (we don't use ask pattern), the answering party is never the service which has actually executed the action but rather the SOAP or REST client running inside our component. That is then where we block.
There is certainly value that there is blocking only on the "edges" of the component. However here I come back to my original point of me not fully embracing the reactive architecture. It is not enough that there is one part (component) attempting to be reactive. In our case since it is responsible of the UI, it creates the illusion of a non-blocking world.
Recently three components have been added to the system, all of which handle streams of data. The most interesting one is Apache Kafka. The drive seems to be towards modernizing the architecture and there is hope for me to getting some valuable experience on a system-wide reactive design.
Comments
Post a Comment