Admin panel

[emschwartz]

It would be kind of neat if you could look at all the charts, etc that autometrics would generate for you, without having to run Prometheus separately. I'm thinking along the lines of an admin panel or UI that would somehow be bundled with the autometrics libraries and then exposed on another endpoint or port from your application itself. Obviously, this would only be in development mode and we'd probably want most of the actual UI to be served from some remote thing so we don't need to bundle tons of JS and whatnot into the actual libraries.

Some annoying things about this is we'd need to figure out how to "run the queries" without actually having the Prometheus query engine, or we'd need to figure out how to display the same graphs without using the actual queries.

[arendjr]

What if instead of opening a full UI panel, we would just open an API endpoint that can be queried by the extension for function discovery, instead of relying on Prometheus for that. It wouldn't work outside the extension (or Fiberplane) obviously, but otherwise it might achieve the same thing. And we might fix autometrics-dev/vscode-autometrics#11 sideways.

[mies]

I imagine we could still add an admin panel of course that would query that endpoint and visualize this?

[gagbo]

Where would the server serving that endpoint run?

[mies]

@gagbo this would be bundled inside autometrics-rs as an example and use the server of your app. Similar to the get_metrics handler you would have to implement the get_admin handler that would be served on /admin. You probably would only want this to work during development. P.S. I actually like /explorer and get_explorer over admin/get_admin on second thought.

[gagbo]

I see, that works yeah :)
That would mean that all the different language implementations would have to implement their own handler for that route right? Will we use an OpenAPI spec to materialize the expected format for all implementations?

[mies]

Correct on different implementations, but with the same React/JS bundle(probably served from the internet though there might be some value in having this available when you're offline though that's probably an outlier scenario that we will implement if people really want it). I don't have strong opinions on the OpenAPI angle to be honest but seems like the right approach to keep the various implementations in sync.

[gagbo]

I struggle to understand how we would make the UI without running Prometheus as it's the query engine that provides data.

Do we want the Admin/Overview page to directly show graphs even if there's no data (no Prometheus)? If so, what's the data generation strategy, and how do we make it different enough from real data?
If not, then I guess making sure the UI updates ASAP with actual data is going to be enough

We want to run the UI in "development" mode so that there's little friction to try and see what autometrics has to say. That means we want to be able to run fully locally right? In that case, we need to ship somehow the UI so that local visualization is available too. I guess the lowest friction method to ship a screen/UI is to pack it in a VSCode extension — it's a one click install (even as an additional "Autometrics Dashboard" extension) and then 1 click to go to the relevant screen. No server to run in a background, no need to open a browser tab/separate GUI app.

For non-local "Admin panels", once autometrics is actually deployed with an app somewhere, I suppose we could write a small React app specifically to run as the server, which wouldn't be a costly setup since users are likely to already manage a Grafana deployment to look at the metrics. And we could have a public library for anyone to write their UIs if they want to?

[mies]

I like the compile Prometheus to WASM idea, but leveraging local storage is super interesting as well; to a large extent you don't really need a complete Prometheus instance for this local development story, some lightweight db could suffice. PQLite? 😀

[emschwartz]

Given how complicated Prometheus is, I'd guess that it would be easier to compile the entire thing to WASM (if that's even possible) than trying to extract specific components and re-wire them together or rewriting any amount of its functionality

[mies]

agreed; compiling to wasm would be the most ideal solution (assuming reality)

[gagbo]

We could try to replicate one of the postgres-in-wasm projects (like https://github.com/snaplet/postgres-wasm ) to give a portable prometheus somewhere?

[mies]

Good idea. I know the Snaplet crew very well so I can also ask them for any insights if useful?