GraphiQL-UI with context-path

[t1]

The GraphiQL-UI doesn't work on, e.g., WildFly, because the application runs on a sub-path, e.g. https://hostname/appname/graphql but the render.js file defines the api path to be just /graphql.

If this path was defined to be relative to the actual path, it would work also on application servers.

[phillip-kruger]

Thanks ! Are you doing a PR ?

[t1]

I'm not good at JavaScript ;-)

[phillip-kruger]

Use this as a learning opportunity ;)

[jmartisk]

If you're using my feature pack in WildFly, this should not be an issue: https://github.com/wildfly-extras/wildfly-graphql-feature-pack/blob/1.1.0.Final/subsystem/src/main/java/org/wildfly/extension/microprofile/graphql/deployment/GraphiQLUIDeploymentProcessor.java#L113 - basically the deployment processor changes the render.js during deployment and overwrites the context root with the correct one. This mechanism is somewhat brittle, so I assume there might be cases where it breaks (I haven't tested EAR deployments I think, but for WAR it should work and the UI should be available at <context-root-of-the-webapp>/graphql-ui).

Anyway, how do you imagine doing this generally? render.js is just a static JS file. I don't think it's possible to find the correct context root using JS code inside the script. This has to be managed by the runtime server "somehow".

In any case if you decide to do any changes in render.js for this, let me know, because it would most definitely break the mentioned ~~hack~~ solution that I have in WF :)

[t1]

After googling a bit, I'd go with window.location.href and then make it relative. I assume that your ~~hack~~ solution won't be necessary any more ;-)

BTW: I'd love to go to the WF feature pack, but we have some way to go to get there and it's not the top priority. There also some issues that I didn't have the time to investigate enough to see what exactly is wrong. E.g. the zip you provide doesn't contain the jars... I thought it already did, but they aren't there any more.

[jmartisk]

After googling a bit, I'd go with window.location.href and then make it relative. I assume that your ~hack~ solution won't be necessary any more ;-)

That gives you the location of the graphql-ui, not the location of the /graphql endpoint, which can potentially be different than the default /graphql (Quarkus already has a configuration option to change it, I'm planning to add something like that for WildFly too). So only the server knows the location - we would somehow need to pass this information to the script when serving it, but I'm not sure if that's possible. Maybe if we switched from a static JS file to a servlet (or something like that) that generates the correct script dynamically.

BTW: I'd love to go to the WF feature pack, but we have some way to go to get there and it's not the top priority. There also some issues that I didn't have the time to investigate enough to see what exactly is wrong. E.g. the zip you provide doesn't contain the jars... I thought it already did, but they aren't there any more.

There are three zips that appear in the build/target directory after building, see the README at https://github.com/wildfly-extras/wildfly-graphql-feature-pack/tree/main/build - the 'full' and 'overlay' zips contain JARs, only the thin zip contains a Maven-based distribution

[t1]

the location of the graphql-ui, not the location of the /graphql endpoint

I assumed that these are relative to each other, but if Quarkus has a configuration option, that may not be the case... hmmm... how does Quarkus do that, then, without patching the render.js?

zips that appear in the build/target directory

I've opened https://github.com/wildfly-extras/wildfly-graphql-feature-pack/issues/49

[t1]

As a first step, I just wanted to prove that it's possible. What do you think?

[jmartisk]

hmmm... how does Quarkus do that, then, without patching the render.js?

It seems Quarkus performs pretty much the same patching of render.js: https://github.com/quarkusio/quarkus/blob/1.12.2.Final/extensions/smallrye-graphql/deployment/src/main/java/io/quarkus/smallrye/graphql/deployment/SmallRyeGraphQLProcessor.java#L498

[phillip-kruger]

Yup, that is why I was suggesting we do that in SmallRye. Some java class (RenderJsCreator) that allows doing this.

[jmartisk]

That would be cool, I'm just not sure how to do it in a runtime-neutral way (that is without having to do a significant amount of wiring on the runtime side, which would defeat the purpose. There will always necessarily be some wiring on the runtime side, because at minimum you need to account for the configured /graphql path, and each runtime uses its own specific ways to configure this). The UI jar itself does not contain any Java classes, it's a set of static resources. But perhaps there is an easy way, I just don't see it right now.