Analytics as code

GoodData.UI is the code that shows analytics in your application. The analytics themselves (the data model, metrics, visualizations, and dashboards) live in a GoodData workspace, and GoodData lets you manage them as code too. This page explains what that means, which tools do it, and where the two meet.

What analytics as code means

Instead of building every metric and dashboard by hand in the GoodData web interface, you describe them in text files and keep the files in a Git repository, next to your application code. Each object is a YAML file:

type: metric
id: percent_revenue

title: "% Revenue"
description: Percent of Total Revenue

maql: SELECT {metric/revenue} / {metric/total_revenue}
format: "#,##0.0%"

With analytics in files, you can treat them the way you treat code:

• Version control. Every change is in the history: what changed, when, who changed it, and why. You can revert one.
• Review. Changes go through pull requests and code review, on GitHub, GitLab, or wherever your code lives.
• Automation. A CI/CD pipeline validates the files and deploys them to a workspace, for example to a test workspace on every pull request and to production on release.

The files cover datasets and date datasets (the logical data model), metrics written in MAQL, visualizations, dashboards, and dashboard plugins. See Object Structures for the format of each.

The tools

To try it, follow Get Started with GoodData for VS Code.

Where GoodData.UI fits

Analytics as code decides what the workspace contains. GoodData.UI decides where and how your application shows it. The two meet at object IDs: the id in a YAML file is the ID your components load.

// The visualization's YAML file has `id: revenue_by_region`
<InsightView insight="revenue_by_region" />

// The dashboard's YAML file has `id: sales_overview`
<Dashboard dashboard="sales_overview" />

Metrics and attributes work the same way when you build a visualization in code with BarChart, PivotTable, and the other components, where a workspace metric becomes a measure. To catch a renamed or deleted object before your users do, generate typed constants for the workspace with @gooddata/catalog-export, as the quickstart does: an ID that no longer exists then fails the TypeScript build instead of an empty chart at runtime.

One way to wire the two together:

1. You change a metric in its YAML file and open a pull request.
2. CI runs gd validate on the files, and a reviewer approves the change.
3. On merge, CI runs gd deploy to update the workspace.
4. The application’s build regenerates the catalog with @gooddata/catalog-export and compiles. If an ID the application uses is gone, the build fails here.
5. The application ships, and its components show the updated analytics.

Keeping the analytics files and the application in one repository lets a single pull request change both: for example, a new metric and the chart that shows it.