spring-projects / spring-integration

Spring Integration provides an extension of the Spring programming model to support the well-known Enterprise Integration Patterns (EIP)
http://projects.spring.io/spring-integration/
Apache License 2.0
1.53k stars 1.1k forks source link

Document which channel adapter / gateway is Reactor friendly or not in the endpoints table #3773

Open markusherbert opened 2 years ago

markusherbert commented 2 years ago

Expected Behavior I think we should document which endpoint in the endpoints table is Reactor friendly or not. I'd like there to be a check (like a V tag, different color, or another signal) that will help users to understand if this Inbound Adapter/ Outbound Adapter/ Inbound Gateway/ Outbound Gateway has a reactive option or not. In regards to async implementations, I'm not sure if this should be classified as reactive, get mentioned in another category, or don't get mentioned at all.

Current Behavior It's really hard to understand for example if the MqttPahoMessageHandler can interact reactively or not. The same is relevant for most of the extensions. Resolving this issue can improve Reactive Spring Integration users' life very much.

Context I really suffer from understanding which channel adapter/ gateway has a reactive behavior or not, except in cases like ReactiveMongoDbStoringMessageHandler etc. I've also seen the need for this in https://github.com/spring-projects/spring-integration/issues/3771.

artembilan commented 2 years ago

I'm not sure that this one has really some value. We have that table with links to target channel adapters. You follow them and determine from their specif chapter if they are reactive or not. The reactive is not a top-level feature of Spring Integration. It is more implementation details of the specific component. Therefore such a table must not be overcomplicated with an extra info which could be inferred from the target docs. I doubt "reactive" is a first question people are asking looking into Spring Integration reference manual.

I'm not closing this one since we may gather other arguments yet.