Consider releasing artifact

[kptfh]

There are tons of devs waiting for working ReactorFeign. Especially they are interested in Spring's implementation (witht Ribbon/Hystrix support).
@kdavisk6 Let's release this artifact so I can proceed with Spring's WebClient implementation.

[velo]

@kdavisk6 and I talked about this.

I think we should release this as io.github.openfeign.incubation until we get a solid api.

What do you think?

Can I begin the release right now?

[kptfh]

@spencergibb @ryanjbaxter are you OK with it? Will you approve the pull request in Spring Cloud with io.github.openfeign.incubation dependency ?

[kptfh]

@velo @kdavisk6 How do you estimate the time you need to get solid API?

[velo]

I think when we have all the API tickets solved, it will be a solid and stable api good for a release
https://github.com/OpenFeign/feign-reactive/issues?q=is%3Aopen+is%3Aissue+label%3AAPI

They may require work to be done on feign-core as well

[kdavisk6]

Apologies for the delay in responding, I was away with the family. I am just about finished a few bug fixes for core. I can help starting later this week.

[ryanjbaxter]

As long as the API in the Spring Cloud project is stable we wouldnt mind using something that is incubating but if that Spring Cloud API could change as well than we will have to take a different approach.

[kptfh]

@kdavisk6 @velo Ok, guys. Let's release it somehow. Don't want to stop progress. Probably for someone it may be determinative that java has reactive feign client while choosing language for project.
JFMI, how do you estimate time it may take to solve all API issue?

[kdavisk6]

I've started looking into the API issues and I believe that most of these API issues can be solved if we change the approach being taken. Most of this library is a refactor of core feign concepts using functional style and paradigms. The reactive areas are limited to executing the Request, which we can simplify by wrapping the existing synchronous implementation in a Reactive wrapper.

I've started working on that in my fork and you can see what I have here:

https://github.com/kdavisk6/feign-reactive/tree/reactive-core/feign-reactive-core/src/main/java/feign

From my perspective, this should be sufficient for us to get an initial release out. Since this approach extends from feign directly, it will allow this library to support everything regular feign does, including logging, encoding, decoding, OkHttp, ApacheHTTP, Jackson, GSON, etc... solving all of our API issues.

With regards to Spring Cloud, all that should be necessary is a new Targeter, as my approach is extremely close to HystrixFeign. Please take a look at my fork and let me know what you all think. @spencergibb and @ryanjbaxter I would appreciate if you could check my assumptions and provide us with your perspective on this problem.

@velo and @kptfh I would appreciate if you could look at my fork and let me know your thoughts.

[kptfh]

which we can simplify by wrapping the existing synchronous implementation in a Reactive wrapper.

@kdavisk6 Reactive programming is not just interface it's also means reactive implementation behind the scene. Wrapping sync call with reactive interface will not make them reactive. You need all the chain to be reactive and at the end of this chain is reactive http client should be. But in your approach whole chain is not reactive and it kills any gains that reactivity can give.
BTW How are you going to process Flux with this approach?

[kptfh]

The main benefit reactive approach gives is low threads consumption. But with your approach threads usage remains high (one per call)

[kdavisk6]

I agree with you. A fully reactive Feign is the goal of this project.

My proposal is a trade off. If accepted, we would be able to release something in the near term, clearing any blocks on other downstream projects. We can then take the time we need to refactor each API component, updating core if necessary, taking an iterative approach. The alternative is to wait until we have refactored every API and closed every issue.

I'm trying to find a balance here, between moving things forward without moving too quickly.

[kptfh]

dead end