Quarkus and the Mutiny to java.util.concurrent.Flow migration

[Julien Ponge]

Hi,

As Mutiny is switching from the legacy Reactive Streams API to the JDK Flow APIs [1], I’m currently looking at migrating existing code bases.

The migration in itself isn’t very complicated as the APIs are isomorphic, but I’m going to need some guidance on which strategy to adopt for different parts of the code base.

1. Code that just depends on Mutiny and not org.reactivestreams types is unaffected. That’s the case for Hibernate Reactive, the migration will be just a version bump.
2. Most code shall be migrated from org.reactivestreams types to java.util.concurrent.Flow types.
3. Some code may depend on third-party libraries that are still using the legacy APIs, and for these we can use the Mutiny Zero adapters [2] to go back and forth between the APIs.
4. Perhaps some code (RestEasy?) need to directly support both APIs at the same time (e.g., a Flow.Publisher and a RS Publisher).

If you are more familiar that I am about a particular module then please let me know what you think is best, it’ll be very helpful :-)

Doing a quick grep in the Quarkus repository I found the following pieces of code that explicitly depend on the org.reactivestreams package.

Extensions

• extensions/resteasy-reactive

• extensions/smallrye-reactive-messaging

• extensions/smallrye-reactive-messaging-amqp

• extensions/smallrye-reactive-messaging-kafka

• extensions/narayana-jta

• extensions/reactive-routes

• extensions/resteasy-classic/resteasy-mutiny-common

• extensions/mailer

• extensions/hibernate-validator

• extensions/mongodb-client

• extensions/grpc

Tests

• integration-tests/mongodb-panache-kotlin

• integration-tests/smallrye-context-propagation

• integration-tests/mongodb-panache

• integration-tests/devmode

Core-ish

• independent-projects/resteasy-reactive

• core/deployment

[1] https://github.com/smallrye/smallrye-mutiny/discussions/994 

[2] https://smallrye.io/smallrye-mutiny-zero/0.4.3/flow-adapters/ 

[Loïc MATHIEU]

Hi Julien,

Did you also check documentation and quickstarts ?
We used the Publisher interface some time ago for documenting SSE with a reactive stream, I checked some guides and they appear to have moved to Mutiny.

The MongoDB with Panache guide contains a sentence saying Multi implements Publisher, it should be updated after the change, see https://quarkus.io/guides/mongodb-panache#reactive 

Regards,

Loïc

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/3BE876F7-9326-47EF-984F-0837C90C617F%40ponge.org.

[Julien Ponge]

Hi Loic,

Yes I didn’t include the docs but I had found them in grep ;-)

Thanks

[Julien Ponge]

Hi,

I’m going offline end of the week for a little while, so I thought I’d share progress on this topic.

Overall things are going well, but Reactive Messaging is causing me more headaches.

I’ve captured notes in https://github.com/quarkusio/quarkus/issues/26675 to track progress.

My scratchpad branch at https://github.com/jponge/quarkus/tree/scratchpad/rs-publisher-to-flow has work-in-progress fixes for the Quarkus code base:

• Resteasy Reactive to support both Flow and legacy RS APIs
• Resteasy Classic / Reactive Routes fixed with adapters
• Mailer extension upgraded to Flow
• Narayana JTA: I added Flow support but I’m quite unsure as I didn’t find tests for the reactive part
• Hibernate Validator: nothing to do
• MongoDB client: fixed with Flow/RS adapters as the library depends on RS APIs
• gRPC: migrated tests
• Reactive Messaging: see below
• Integration tests: still pending, to be done once the rest builds

I tried 2 drafts to address Reactive Messaging (the project, not the extensions yet).

The main issues are that the library is still on a Java 8 baseline (Flow was introduced in 9), and there is a strong API adherence to Eclipse Microprofile Reactive Messaging specs (hence Java 8 + legacy Reactive Streams).

So I tried the following approaches: they compile, but tests do not pass (I think it’s due to my current lack of familiarity with the internals of the library such as the mediator bits).

1. https://github.com/smallrye/smallrye-reactive-messaging/pull/1826 is a Flow migration with RS/Flow adapters where RS types come from Microprofile specs
2. https://github.com/smallrye/smallrye-reactive-messaging/pull/1835 is a less intrusive first step where APIs are kept as-is, but Flow/RS adapters are used to bridge with Mutiny APIs based on Flow.

It’s not a very complicated change per-se (again, the APIs are isomorphic), but there are libraries with various constraints to align or bridge with adapters so I’m looking forward to any tip/guidance/help you may have :-)

Cheers

- Julien

[Julien Ponge]

Hi,

For those interested in this topic, the draft branch that I have at https://github.com/jponge/quarkus/tree/scratchpad/rs-publisher-to-flow now builds with Flow, especially with the help of Ozan who made a branch for Flow-ified Reactive Messaging https://github.com/smallrye/smallrye-reactive-messaging/pull/1896

The next steps are:

1. Align all milestone releases of the involved projects (Mutiny, Vert.x Mutiny bindings, Hibernate Reactive, etc)
   
2. Clean up and offer a Quarkus PR draft to check in CI
   
3. Work toward final releases across the involved projects
   
4. Promote a Quarkus PR with final Flow-ified versions.
   

Cheers

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/2BB4DF01-6A1D-448E-B13B-99A50C9B419F%40ponge.org.