Reactive Wrapper Support#795
Merged
Merged
Conversation
ae344a2 to
9628905
Compare
velo
approved these changes
Oct 10, 2018
velo
left a comment
Member
There was a problem hiding this comment.
I liked, add just 2 minor suggestions...
Sorry for taking so long
| if (library == null) { | ||
| throw new IllegalStateException("A Reactive Streams Library has not been specified"); | ||
| } | ||
| super.contract(new ReactiveDelegatingContract(this.contract)); |
Member
There was a problem hiding this comment.
Would recommend checking if contract is an instance of ReactiveC and only warp of not
| if (ReactiveStreamsLibrary.REACTOR == this.library) { | ||
| return new ReactorInvocationHandler(target, methodHandlerMap); | ||
| } else if (ReactiveStreamsLibrary.RXJAVA == this.library) { | ||
| return new RxJavaInvocationHandler(target, methodHandlerMap); |
Member
There was a problem hiding this comment.
Should this be inject on the builder so becomes a configuration a give flexibility?!
ReactiveFeign.builder()
.withInvocationHandler( RxJavaInvocationHandler::new )
...
Member
There was a problem hiding this comment.
That would allow ReactiveStreamsLibrary to be removed...
Member
Author
There was a problem hiding this comment.
What I might do is create custom builders instead. I'll give it a try.
9628905 to
c86e5a9
Compare
Adding support for Reactive Streams `Publisher` return types. Support is provided through the `ReactiveInvocationHandler` and follows a similar pattern used by `feign-hystrix`. Each method invocation is wrapped in a `Callable`, which is then wrapped into the appropriate Reactive Streams `Publisher`, as defined in the builder and the return type of the method. This approach is not "reactive all the way down". The requests are still executed via a regular `Client` and are synchronous. However, it is possible to still take advantage of the backpressure, scheduling, and functional support provided by the library implementations. Limitations: Streams are not supported and Iterable responses are not treated reactively. Iterables must be explicitly cast into a reactive type. Reworked Builders and removed the need for the enumerator
c86e5a9 to
49ea8a5
Compare
Member
Author
|
@velo Created specific Builders for Reactor and RxJava and removed the libraries enum |
Closed
velo
pushed a commit
that referenced
this pull request
Oct 7, 2024
Adding support for Reactive Streams `Publisher` return types. Support is provided through the `ReactiveInvocationHandler` and follows a similar pattern used by `feign-hystrix`. Each method invocation is wrapped in a `Callable`, which is then wrapped into the appropriate Reactive Streams `Publisher`, as defined in the builder and the return type of the method. This approach is not "reactive all the way down". The requests are still executed via a regular `Client` and are synchronous. However, it is possible to still take advantage of the backpressure, scheduling, and functional support provided by the library implementations. Limitations: Streams are not supported and Iterable responses are not treated reactively. Iterables must be explicitly cast into a reactive type. Reworked Builders and removed the need for the enumerator
velo
pushed a commit
that referenced
this pull request
Oct 8, 2024
Adding support for Reactive Streams `Publisher` return types. Support is provided through the `ReactiveInvocationHandler` and follows a similar pattern used by `feign-hystrix`. Each method invocation is wrapped in a `Callable`, which is then wrapped into the appropriate Reactive Streams `Publisher`, as defined in the builder and the return type of the method. This approach is not "reactive all the way down". The requests are still executed via a regular `Client` and are synchronous. However, it is possible to still take advantage of the backpressure, scheduling, and functional support provided by the library implementations. Limitations: Streams are not supported and Iterable responses are not treated reactively. Iterables must be explicitly cast into a reactive type. Reworked Builders and removed the need for the enumerator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adding support for Reactive Streams
Publisherreturn types. Supportis provided through the
ReactiveInvocationHandlerand follows a similarpattern used by
feign-hystrix. Each method invocation is wrapped in aCallable, which is then wrapped into the appropriate Reactive StreamsPublisher, as defined in the builder and the return type of the method.This approach is not "reactive all the way down". The requests are still
executed via a regular
Clientand are synchronous. However, it is possibleto still take advantage of the backpressure, scheduling, and functional support
provided by the library implementations.
Limitations: Streams are not supported and
Iterableresponses are not treatedreactively.
Iterablesmust be explicitly cast into a reactive type.Special thanks to @ilaborie for doing much of the upfront work. See #491 and #622