• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Paul Clapham
  • Rob Spoor
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Carey Brown

RSocket as Spring de-facto communication protocol

Ranch Hand
Posts: 48
MicroProfile Quarkus Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Given the recent trends toward adopting RSocket as the service-to-service (and even extending to clients) communication protocol and given its, reactive, scalable and elastic nature, would it be the preferable way to approach components RPC communication in a Spring application(s)?
Spring already has great support for various communication protocols and methods among the different components and the a user can still choose from these, but I can see (at least based on my experience) the cases where RSocket would not fit as being limited for Greenfield applications.

What are the know challenges for such a protocol?
Is observability and metrics first-class citizens?

Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Marouane,

Great question. My personal take on this -- and it is shared by many, but your mileage of course may vary due to particular circumstances you're addressing at a particular moment -- is that Reactor and RSocket provide a set of capabilities that are difficult to match in terms of resilience, flow control, transport independence, full bidirectionality, multiplexing, etc. But it isn't a single solution that will supplant all others, for example:

1. Distributed systems of apps that are scaling adequately already
2. Systems of apps that include blocking APIs that cannot or will not be rewritten, e.g. external systems (especially if all bottlenecks are in those external systems)

That said, reactive streams undeniably do add complexity to an otherwise pretty pedestrian application/group of apps. Tooling has had 25+ years under so-called imperative Java to develop, mature, and be refined; and while great strides are being made with reactive-supporting tooling, it clearly began later in the Java ecosystem than that, which is another challenge. But the state of tooling is advancing rapidly, as you might imagine, as many lessons can be drawn from earlier (blocking) efforts; it isn't a 100% green field in that regard.

Regarding observability and metrics (and a few other topics) though, it's far easier to build an API and interactions around a non-blocking API and then block than to go the other way, so that's exactly what you see happening with many aspects of the Spring ecosystem, whether internal, partner, or community. To give one small representative example, Spring Boot Actuator interacts with and produces Reactor types (Publishers, both Monos and Fluxes)...and thus of course can be accessed perfectly well from blocking applications expecting Object<T> and Iterable<T>, etc. So metrics, tracing, security, and other concerns accommodate and embrace Publishers and of course the expectation that context must be maintained when all processes don't occur sequentially on a single thread.

Hope this helps!
    Bookmark Topic Watch Topic
  • New Topic