Data Apps
A data app is a configuration-based visualization tool that allows you to create interactive dashboards from SQL queries without writing complex frontend code.What are Data Apps?
Data apps in Oxy are defined using YAML configuration files (.app.yml) that specify both the data processing tasks and how to visualize the results.
ℹ️ Info
Data apps are designed to make it simple to transform SQL query results into meaningful visualizations with minimal effort. The .app.yml files abstract away the complexity of building dashboards, allowing you to focus on the data and insights rather than visualization code.
Data App Components
In a data app YAML file, you need to specify the following components:| Component | Description | Required |
|---|---|---|
| name | Unique identifier for the data app | Required |
| description | Brief explanation of the app’s purpose | Optional |
| tasks | SQL queries that prepare data for visualization | Required |
| display | Visualization components to render the data | Required |
Tasks
Thetasks section defines SQL queries that will extract and transform data from your databases. Each task has the following structure:
| Field | Description | Required |
|---|---|---|
| name | Identifier for the task (referenced in display) | Required |
| type | The task type (currently only execute_sql is supported) | Required |
| database | Database connection to use (defined in config.yml) | Required |
| sql_query | Inline SQL query to execute | Required if sql_file not provided |
| sql_file | Path to SQL file to execute | Required if sql_query not provided |
| variables | Key-value pairs for variable substitution in queries | Optional |
| cache | Cache configuration for query results | Optional |
| export | Configuration for exporting query results | Optional |
⚠️ Warning Make sure your tasks are named uniquely as these names are referenced in the display section.
Display
Thedisplay section defines how to visualize the data produced by your tasks. Several visualization types are supported:
Markdown
Markdown blocks can be used to add formatted text, headers, and documentation:Controls
Controls add interactive filter widgets to your app. When the user changes a control value, every task that references that control re-runs automatically and all charts and tables update. Controls are defined inline in thedisplay list using type: control:
| Field | Description | Required |
|---|---|---|
| name | Identifier used to reference the control value in SQL via {{ controls.<name> }} | Required |
| control_type | Widget type: select, date, or toggle | Required |
| label | Human-readable label shown above the widget | Optional |
| default | Initial value when the app loads | Optional |
| options | Option list for select controls — static strings or Jinja expressions | Required for select (or use source) |
| source | Task name whose first column provides options dynamically for select controls | Optional (alternative to options) |
Control types
select — a dropdown menu. Populate options from a static list, from Jinja expressions, or from a task query:
date — a date picker that injects a YYYY-MM-DD string. The default can be a static date or a Jinja expression:
toggle — a boolean on/off switch:
Using control values in SQL
Reference control values in your task SQL using Jinja syntax:
ℹ️ Info
Controls must be placed before the charts and tables they affect in the display list. The controls bar is rendered at the top of the page and stays visible as you scroll.
Bar Chart
Line Chart
Pie Chart
Table
Row (multi-column layout)
Userow to arrange multiple charts side by side: