First of all, thanks for your reply.
I can’t really say that I have a use case right now.
The initial question that had me ended up here asking questions about RSocket was : which advantages could take the “rest API based micro-service architecture application” I’m working on been ported to a reactive paradigm ?
Thus, I also had to wonder :
- blocking or non blocking ?
- if non blocking, how internal reactive framework back pressure management is working ?
- if it’s working on an internal basis, would it also work through the network in a heterogeneous Rest API based micro service architecture
- what about back pressure management when exchanging with other old school (HTTP Rest API) systems not supporting back pressure
Surprisingly, that’s when I’ve discovered RSocket
I guess that to fulfil my curiosity about RSocket it would takes, as a first step, to turn one of our use case into a real end to end full blown reactive “chain”.
Most of our micro services are Spring Boot WebControler based, so this part shouldn’t be that hard to migrate to Reactor / WebFlux.
The trouble is that we’re on a Rancher, soon K8S, full blown PAAS environment with indeed load balancing and security needs here and there, at very least. And of course we’ll still have to be able to call other team’s REST API.
So, basically, I guess that if I want to setup a POC without reinventing the wheel for the load balancing and security part, I’ll need first to see what I can do with the community edition of Netifi
Next I’ll need to check how complex it would be to also have one of our NodeJs based micro service moved to this RSocket communication layer.
I’ll keep in touch with you if I manage to setup something alike and need extra advices