Our current convenient MetricSample data structure only exposes a limited fraction of the data in the API response. This is fine for the majority of the applications and there are no plans yet to rework it such that further data like states, bounds or more fields from aggregated metrics are integrated into the existing data structure.
Proposed solution
If we expose access to the underlying, auto-generated pb data structure, users are able access all data that can be retrieved from the UI.
This also needs an example implementation.
Use cases
Anything that needs bounds, states or fields other than mean in aggregate metrics.
Alternatives and workarounds
Rework the current data structure to represent everything. Since this will become very nested like the original response data structure, better would probably be to introduce a new data structure. However, it needs to be seen how much value this brings over the existing auto-generated version.
What's needed?
Our current convenient
MetricSampledata structure only exposes a limited fraction of the data in the API response. This is fine for the majority of the applications and there are no plans yet to rework it such that further data like states, bounds or more fields from aggregated metrics are integrated into the existing data structure.Proposed solution
If we expose access to the underlying, auto-generated pb data structure, users are able access all data that can be retrieved from the UI.
This also needs an example implementation.
Use cases
Anything that needs bounds, states or fields other than mean in aggregate metrics.
Alternatives and workarounds
Rework the current data structure to represent everything. Since this will become very nested like the original response data structure, better would probably be to introduce a new data structure. However, it needs to be seen how much value this brings over the existing auto-generated version.
Additional context
Connected to: