Problem
Currently, the runs statistics view (e.g., /runs?mode=charts&calendarMode=duration) requires fetching all runs via GET /api/v2/runs/ and performing client-side aggregation.
This approach has significant performance issues:
- Backend overload: The endpoint returns complete run objects with all fields, creating unnecessary database load
- Slow response times: Users experience delays while waiting for all runs data to be fetched and processed
The aggregation logic is currently implemented in libs/bublik/features/runs/src/lib/runs-stats in the UI repository.
Solution
Introduce a dedicated /api/v2/runs/stats/charts endpoint that performs server-side aggregation and returns pre-computed statistics.
Do know if path is good, check it
Endpoint Design
GET /api/v2/runs/stats/charts
Query Parameters:
start_date (optional): Start date for the period (ISO 8601 format)
finish_date (optional): End date for the period (ISO 8601 format)
- Additional filters matching existing
/api/v2/runs/ parameters (branch, tags, etc.)
References
Problem
Currently, the runs statistics view (e.g.,
/runs?mode=charts&calendarMode=duration) requires fetching all runs viaGET /api/v2/runs/and performing client-side aggregation.This approach has significant performance issues:
The aggregation logic is currently implemented in
libs/bublik/features/runs/src/lib/runs-statsin the UI repository.Solution
Introduce a dedicated
/api/v2/runs/stats/chartsendpoint that performs server-side aggregation and returns pre-computed statistics.Do know if path is good, check it
Endpoint Design
GET
/api/v2/runs/stats/chartsQuery Parameters:
start_date(optional): Start date for the period (ISO 8601 format)finish_date(optional): End date for the period (ISO 8601 format)/api/v2/runs/parameters (branch, tags, etc.)References