Default reactive route returns 404

[geromueller]

Describe the bug

For single page apps unknown routes should return index.html. In classic mode it is possible to add a "last" route which redirects to index.html. In reactive mode the default route returns 404, which breaks the router chain.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[geoand]

In classic mode it is possible to add a "last" route which redirects to index.html. In reactive mode the default route returns 404, which breaks the router chain

I am not sure what you mean by this.

Can you clarify please?

Thanks

[gmuellerinform]

I was in a hurry yesterday, sorry!

In order to have a small and leightweight service, I deliver the frontend using Quarkus. This is how i make sure the single page app is loaded correctly in classic mode:

   void init(@Observes Router router) {
        router.getWithRegex("/.*").last().handler(rc -> {
            if (rc.normalizedPath().equals("index.hmtl"))
                rc.fail(404);
            else
                rc.reroute("index.hmtl");
        });
    }

But in reactive mode, this route never matches!

[geoand]

Thanks for the update, it's very helpful, but I still don't fully understand what But in reactive mode, this route never matches means.
Mind providing an example for this as well?

[gmuellerinform]

It is the same code, but some route/handler which is executed before calls the 404 instead of rc.next(), so the list of routes is not processed to the end.
But, when I move my route up in the order, just before the build in routes (order=10000), I have to guess if it is an SPA route or some actual resource / static file. My workaround curently looks like this:

void init(@Observes io.vertx.mutiny.ext.web.Router router) {
   router.getWithRegex("^(?!/assets\|/api\|/index\\.html).*").handler(rc -> {
      rc.reroute(reroutePath);
   });
}

[gmuellerinform]

See here: https://stackoverflow.com/questions/66965460/quarkus-how-to-implement-routing-for-single-page-apps
I was actually surprised that quarkus does not support this out of the box...

[geoand]

Gotcha, thanks!

I'll leave it to @cescoffier. Also @ia3andy might have some ideas.

[ia3andy]

@gmuellerinform, @geromueller have you tried https://github.com/quarkiverse/quarkus-quinoa/?

It features SPA routing: https://docs.quarkiverse.io/quarkus-quinoa/dev/advanced-guides.html#spa-routing

[gmuellerinform]

@ia3andy I had a look at it, but is solved things I do not need (building frontend, proxies etc)

[gmuellerinform]

I just found this while looking at quinoa: https://github.com/quarkusio/quarkus/blob/main/extensions/resteasy-reactive/quarkus-resteasy-reactive/spi-deployment/src/main/java/io/quarkus/resteasy/reactive/server/spi/ResumeOn404BuildItem.java

This seems like a very complicated way to do something very common..

[geoand]

That is RESTEasy Reactive specific, it has no effect when using routes directly

[gmuellerinform]

@geoand Are you sure? It actually says it does change routing behavior...

[geoand]

I am

[gmuellerinform]

But why does quinoa have to use it then to allow SPA routing?

[geoand]

The reason it says that is because RESTEasy Reactive itself executes (from a Vertx perspective at least) as one big complicated route.
Normally when RESTEasy Reactive can't match a URL it ends the request with 404.

The build item you see allows the next route in the chain to continue the processing when RESTEasy Reactive has not matched the URL

[gmuellerinform]

I mean, yes it is RESTEasy Reactive specific, but then this needs to be changed ;-)

[ia3andy]

I think there is an issue to make this easier, let me find it..

[gmuellerinform]

Could you add an build time option for this, instead if having to create an extension?

[ia3andy]

@phillip-kruger didn't we talk about changing the 404 handling in dev mode to use the dev-ui instead or something? I can't find any issue about it?

[phillip-kruger]

Yea we did, but nothing has been done yet. I have a branch with the index.html page now using Dev UI, I think that is a start.

[ia3andy]

AFAIK the problem is that the 404 handling is done by RR (and RC) with the same routing priority as any other RR resources which is not allowing any other service/extension to provide their own routes with a lower priority than RR.

The 404 handling should be dealt with at a lower priority to allow anyone to hook in. Still if it's not the case yet, I am pretty sure their are reasons for it (probably the side effects and complexity it could involve).

[ia3andy]

@gmuellerinform if you can, my recommendation would be to put your REST api on a specific sub-path (i.e /api), this way you can use the workaround suggested in the Quinoa doc:
https://docs.quarkiverse.io/quarkus-quinoa/dev/advanced-guides.html#spa-routing

[gmuellerinform]

@ia3andy Thanks! This is what I am doing atm. But it is ughly... And I think a simple build time config could help us all:

quarkus/extensions/resteasy-reactive/quarkus-resteasy-reactive/deployment/src/main/java/io/quarkus/resteasy/reactive/server/deployment/ResteasyReactiveProcessor.java

Line 1287 in 5f0dbbc

initClassFactory, launchModeBuildItem.getLaunchMode(), servletPresent || !resumeOn404Items.isEmpty());

[geoand]

Sure, we can do that

[geoand]

Here you go :)

[gmuellerinform]

perfect, thanks a alot!!

[geoand]

🙏