Make both /ui/?query= and /ui?query= work

[Rustin170506]

Follow up #645

Test locally:

• Before change

• After change

[simonswine]

I would prefer to redirect /ui to /ui/

[Rustin170506]

I would prefer to redirect /ui to /ui/

Usually, we use /ui?a=xxx instead of /ui/?a=xxx. For example: https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3Ahi-rustin+archived%3Afalse+phlare.

I think adding a redirection here is a little bit weird. It is not common to have this kind of redirection.

[simonswine]

I don't think it is weird, usually this redirection is done to support relative linking of assets and APIs.

Maybe an example to make it clearer:

• User wants Phlare to mount a via a reverse proxy in there https://tooling.corp/phlare
• When you are accessing it using /phlare/ui, the API will be under ../api
• When you are accessing it using /phlare/ui/, the API will be under ../../api.

Thanks why I think a redirect is better in this case. And we would always be at the same "depth" for relative linking

cc @eh-am

[eh-am]

@simonswine's reasoning is sound, another way of looking at this is that the entire /ui/ subpath is its own "app", where / is the root of that app.

Honestly I didn't do any work here hoping that we would default the UI to the root instead of /ui/ once most pages were ready. But oh well.

[Rperry2174]

Off-topic: I would like to ask what is the relationship between this UI and the UI in grafana? Will they be merged? And what is the relationship with pyroscope UI?

We will provide more official guidance in this at our next community meeting / via other channels.

However, just so you are in the loop as you've been helping us with this (thanks btw!) our long term goal is merging the Pyroscope and Phlare projects.

Once they are merged there will likely be two ways to view profiling data:

1. Via standalone UI (the one being talked about here)
2. Via Grafana UI (explore tab and deeper integrations into Grafana)

In the meantime, we've made this UI compatible with both phlare and pyroscope projects to unify the frontend which users interact with while we work on merging the backend.

That way when the projects are eventually merged it will be done in the "background" with minimum disruption to users (from a UI perspective)

[Rustin170506]

I don't think it is weird, usually this redirection is done to support relative linking of assets and APIs.

Maybe an example to make it clearer:

• User wants Phlare to mount a via a reverse proxy in there https://tooling.corp/phlare
• When you are accessing it using /phlare/ui, the API will be under ../api
• When you are accessing it using /phlare/ui/, the API will be under ../../api.

Sounds reasonable. Thanks for your review!

Honestly I didn't do any work here hoping that we would default the UI to the root instead of /ui/ once most pages were ready. But oh well.

Make sense. I also prefer to move UI to the root and move admin pages to /admin or other routes. It makes accessing the data easier.

[simonswine]

LGTM