A forecasting model is only one part of a useful forecasting product. IberGrid is a web platform for forecasting PVPC electricity prices in peninsular Spain, but its interface goes beyond a single prediction: it presents a next-day hourly forecast, a weekly outlook, market context, model performance, and source status.
That wider surface is an important engineering choice. It places the forecast beside the information needed to interpret and operate it.
Designing around questions
The repository exposes several distinct views of the same domain. The day-ahead forecast answers an immediate hourly question, while the weekly outlook extends the time horizon. Market context gives the forecast a surrounding frame, and the performance and status views make the system itself visible.
Treating these as separate concerns keeps the product from collapsing into one overloaded chart. The interface can present predictions, context, and operational information without pretending they are interchangeable.
Separating product and model work
IberGrid is organised into clear application boundaries:
- A FastAPI backend under
apps/api - A Next.js frontend under
apps/web - Scheduled jobs under
apps/worker - Data processing and model training under
packages/ml
PostgreSQL provides persistence, MLflow supports model tracking, and PyTorch Forecasting supplies the forecasting layer. This structure lets the web experience, API contract, background work, and machine-learning code evolve as distinct parts of one system.
Making the data path explicit
The documented sources are REData, OMIE, and Open-Meteo. The repository also provides separate commands for backfilling data, training a model, and publishing results, with that sequence listed as the recommended order.
That explicit workflow matters. It makes the path from source data to a published forecast visible in the project’s operational interface instead of hiding every stage behind a single command.
Exposing operational context
The API includes health and readiness routes alongside endpoints for day-ahead and week-ahead forecasts, market context, latest model performance, and latest source status. Docker Compose brings up the frontend, API, MLflow, and PostgreSQL services for local development.
The result is a product surface that reflects the whole system: not only what the model predicts, but also which services and information make that prediction available.