Colin Douch
Colin Douch
> Regarding the /visit endpoint, I'm wondering if we could trust the metrics if they are produced from call to go API. It could be easily tricked just calling the...
> I'm wondering if instead of having the endpoint /api/v1/projects//dashboards//visit we have an universal one /api/visit. In this instance, we would include the dashboard/project id in the payload I guess?...
For an event based system I was thinking more along the lines of storing events ourselves, but a log also works and isn't too much of an imposition on top...
I'll get in a PR with the metrics side of things at least. We can discuss logging stuff after that
> For example I forgot why we need a custom fetch To perhaps clarify a bit: Requests to saved datasources get proxied as is to the backing datasource, because we...
@sjcobb I note that we already have a fetch wrapper of sorts in https://github.com/perses/perses/blob/main/ui/core/src/utils/fetch.ts - I could piggy back off that? WDYT?
I think there's still value here. Working within limiting it to just health checks, and piggy-backing off of https://github.com/perses/perses/blob/main/ui/app/src/model/fetch.ts I think I could put something together
Thanks for the review @evan-bradley ! I've updated it with your changes. Those build failures seem unrelated?
@djaglowski considering that that repo has been archived, would it make sense to fork it here?
@atoulme can we get your thoughts here?