arman0604/finops

1. This repository is a FinOps analytics product split into two major halves: a Python analytics backend that ingests and transforms cloud billing data, and a React + TypeScript frontend that presents command-center style views in the browser.

2. The data domain is centered on cloud cost sources for AWS, Azure, and GCP. The raw inputs live under data/raw/ as CSVs plus anomaly labels, while cleaned/combined outputs live under data/processed/. This separation suggests an offline batch pipeline before anything is visualized.

3. The main Python processing chain is decomposed by responsibility:

- data_generator.py produces synthetic or test billing datasets.

- normalizer.py aligns heterogeneous billing formats into a unified schema.

- anomaly_detector.py and stream_detector.py handle batch and near-real-time anomaly detection.

- forecasting_engine.py generates spend predictions.

- storage.py persists results to SQLite.

These modules are the core analytics engine and likely feed the UI through API endpoints or generated artifacts.

4. Persistence is lightweight and local-first. There is a SQLite database at both finops.db and data/database/finops.db, which implies the app can operate without external infrastructure. The database is probably used to store normalized spend, anomaly results, and forecast outputs.

5. The application exposes a backend interface via api.py, which likely serves processed analytics to the frontend. chatbot.py and dashboard_app.py suggest additional backend entry points or service wrappers for conversational assistance and dashboard serving, rather than a single monolithic server.

6. The frontend is a Vite-based React app in src/. It uses TypeScript, with a clear page-level structure:

- CommandCenter for executive overview

- AnomalyWatch for anomaly monitoring

- SpendForecasting for forecast views

- DataUpload for ingestion workflows

Shared layout components live under src/components/Layout/, and visualization-specific UI lives under src/components/VisualizationSection/.

7. Frontend data access is abstracted through src/data/api.ts, which likely centralizes calls to the Python backend, while src/data/mockData.ts provides local fallback or development data. That implies the UI can run in a partially disconnected mode during development.

8. There is a generated dashboard artifact: dashboard_generator.py and finops_dashboard.html, plus a copy in static/finops_dashboard.html. This indicates a second delivery path besides the React SPA: a prebuilt HTML dashboard that can be served or opened directly, likely containing the same analytics in a static format.

9. The repo also contains an implementation_plan.md.resolved, which suggests the project was developed from a planned multi-step architecture with staged implementation. The presence of test_finops_dataset.csv reinforces that the project is designed around repeatable local testing with bundled data rather than live cloud integrations.

10. Overall architecture flow: raw cloud billing CSVs enter the Python pipeline, are normalized and stored, then analyzed for anomalies and forecasts. Those results are exposed either through the Python API to the React dashboard or through a generated static HTML dashboard. The browser is the primary interaction layer, while Python owns the data engineering and analytics logic.