Hacker News Reader

Comment by mollifier14 | Hacker News Reader

We actually use vega-lite under the hood. vega-lite is vast tool set to build charts with static data. dbt Charts adds a whole layer on top of that, which is dashboards with repeatable SQL queries. Also dbt Charts comes with a lot of opinionated chart style ideas. So vega-lite is a toolbox for chart assembly, and we use that toolbox to build dashboards.

On the standardized charting language, that would be the dream. All agents giving the same spec when they want to build a chart or dashboard, and then having different renderers of that. That is a steep goal. Such a language would need to be simple but still extremely versatile. I'm not sure that combination exists yet. Our language is simple and fairly versatile, but not as versatile as vega-lite itself, or JavaScript code even. Maybe we can evolve in that direction though

View on HN

What do you think about GGSQL, or is that not entirely aligned with what you want? They also produce vega-lite JSON as output.

https://ggsql.org/

I love ggsql, the team behind it, ggplot and the tidyverse in general!

I've been mulling extending dbt Charts to support ggplot, and will likely reach out to the team about this in the next few weeks.

The difference is that Vega-Lite, ggsql, ggplot2 are designed to create a single chart. Yes, you can use facet_wrap() to great a series of charts based on a particular variable, but arguably that's still one chart!

What's missing that is table stakes for a BI dashboard: KPIs, text boxes, dropdowns, data sources, governance, and how the charts are arranged on the page and in relation to one another.

In the next few months we hope to ship a JSON schema that represents a dashboard in the same way that a VegaLite does for a single chart.

Does that make sense?

Oh yeah totally. I guess seeing your SQL queries embedded inside the board doc, I immediately wondered if it would make sense to embed a GGSQL program the same way, but in the charts section instead of the queries section!

I guess at the moment GGSQL itself wants to be directly connected to the source database, whereas you've got a split between queries and the charts which display the results.

It would be really cool to have SQL "all the way down" to the chart definitions as well :)

https://openai.com/index/put-data-to-work/ was a compelling demo for me, being able to interact with a artifact and contextually EDA on a series or outliers is lowering the barrier to entry for BI exploration. I think meeting engineers where they work and being flexible and open sourcing these capabilities is really great to see

Reply on news.ycombinator.com