Skip to content

Instantly share code, notes, and snippets.

@kylebrandt

kylebrandt/notes.md

Created Jun 2, 2020
Embed
What would you like to do?
frame in grafana encoding notes

Frame encoding within Grafana

By Destination

Case Backend Plugin:

  • If going to frontend leave it encoded
  • If going to alerting, decode it

Case Core (Internal) Datasource:

  • Encode Frames when sending to frontend

Underlying assumption is we do not want to just always decode and then encode it, even though this would reduce possible code paths. The reasons not to do it are:

  • Decoding and Encoding consumes resources, so do not want to do it if it is not needed.
  • It would get in the way of trying out new features in the SDK with a current version of Grafana. Warning, the "why" is a bit confusing, but follows: In many cases when using a backend plugin we want to try out newer data frame features without updating Grafana. This can be done because FrameMeta and FieldMeta are in the SDK and encoded to bytes. So if both the backend plugin and frontend use new properties, Grafana doesn't need to be updated because in this case it is just passing bytes.

From perspective when authoring

When authoring X, ideally:

  • Core (Internal) Datasource: Just return data frames, do not need to worry about encoding.
  • Backend Plugin: Same as above (and it is already like this)
  • Alerting: Receive unencoded data frames

However with Alerting, until we have removed tsdb.TimeSeries from alerting, it is probably fine to just un-encode them if that is easier.

@marefr

This comment has been minimized.

Copy link

@marefr marefr commented Jun 2, 2020

Cool. Not just sure how to solve "leave it encoded if going to frontend, otherwise not" if we're planning to reuse QueryDataHandler from the SDK - at least that's my current plan. Possible to encapsulate this in the data frames?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.