-
Feature
-
Resolution: Done
-
Major
-
None
-
False
-
None
-
False
-
Release Notes
-
---
Deprecate quarkus-reactive-routes extension
Metadata for the extension should be
"redhat-support": [ "deprecated" ]
Context (from Clement):
There are reactive routes (@Route) and reactive routes (routes registered on the router)
At the end, everything is a reactive route (the second type). That includes RestEasy, extensions exposing endpoints and assets, but also the first type of reactive route.
@Route (provided by the reactive route extension) is a declarative model to simplify the registration of routes on the router. It was kept simple on purpose. So if the user needs more advanced features such as validation, they should switch to RestEasy reactive.
Q1: Isn’t reactive routes closer to how Vert.x works? E.g. should we keep it in the product to allow vert.x users to move to RHBQ?
A1: Vertx users will inject the router and register their routes directly on it (without the declarative model).
Thomas Qvarnström: So we can consider dropping support for reactive routes in the product, but for Fireball I would recommend that we mark it as deprecated and not drop it since there might be customers using it.
- is blocked by
-
QUARKUS-2527 Add support for deprecated label to code.quarkus.redhat.com
- Closed
- is documented by
-
QUARKUS-2651 [Docs]: Document the deprecation of the quarkus-reactive-routes extension in RHBQ
- Closed