-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native Kotlin suspending gateways #107
Native Kotlin suspending gateways #107
Conversation
968bae5
to
0c300a5
Compare
@sandjelkovic I think the checks are failing with permissions errors. Tests pass locally. |
d5e57d5
to
fba6d5d
Compare
c4f25f7
to
ca71397
Compare
afe06ba
to
16c40e6
Compare
16c40e6
to
867afe7
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Our apologies for the longer than usual wait here @jnfeinstein. Firstly, we're keen to learn what your driving force was to provide this pull request, Joel. Secondly, I have a heads-up for you on a potential other solution we were thinking of. Furthermore, this would lose the conceptual copy you've done here. Anyhow, let us know what your thoughts are on the above. |
Due to inactivity, this issue is being closed. If time allows it, @jnfeinstein, please look at the earlier asked question from my end. |
Heh, thanks @smcvb. Four months should've been more than ample time for my to draft a response. 😆 It's been a few months so please excuse a few cache misses in my memory. Reactor is excellent software, and can absolutely handle the use-case of asynchronous command/query/event handling. It does however require additional dependencies both in terms of code and knowledge, and the learning curve can be steep. To be frank, it really wasn't such a lift to write suspending gateway implementations, especially with the Stretching my memory a bit here - I think that the underlying threading infrastructure is also different. The Kotlin suspending infrastructure uses coroutine dispatchers, whereas Reactor uses the netty event loop, which are not the same. Kotlin authors will find it easier to stay within the single world of coroutine dispatchers rather than having to bridge two threading models. Plus lower cost in system resources. Finally, I'd like to see the Kotlin extension more closely aligned with the patterns of |
Thanks for the insights here, @jnfeinstein. And, no worries for the late reply. We're sometimes also richly late because of other obligations 😅 If I follow your suggestions closely, I believe you're OK with keeping this issue closed(?), as long as we move the Kotlin Extension to provide more core component support, correct? |
This PR provides asynchronous gateway implementations relying on Kotlin coroutines. It is largely a refactor of the
ReactorCommandGateway
found inextension-reactor
, but with the guts swapped out. I believe this implementation will integrate easier with Kotlin projects as it does not require knowledge or usage of Project Reactor. Behavior should mimic that ofCommandGateway
when it is not possible to matchReactorCommandGateway
due to Reactor specifics.I have dropped support for running multiple commands and queries. These are implemented in
extension-reactor
usingflatMap
syntax, the equivalent of which would be simple loops in Kotlin. I have also replaced queries usingClass
syntax (as opposed toResponseType
syntax) with inline reified generic implementations.