Stellar-IX
Two years and four months on a legacy codebase: a rewrite that cuts a load time from 4 s to 300-500 ms, and more than ten modules shipped in TypeScript.
- 4 s → 300-500 msaverage load time (declared)
- 194 / 200commits on the FastAPI backend
- 5aggregation levels, hour to year
The problem
The VMware monitoring application re-authenticated on every token expiry and loaded every entity of both datacenters to build its menu, then one more call per item. Slow on first load, never in sync with reality.
The approach
A hybrid FastAPI backend: the vSphere REST API for everyday operations, pyVmomi for the advanced SDK functions, and an entity cache.
TypeScript on a legacy base
The codebase was ejs and Node.js. TypeScript for every new module was adopted after several team discussions, then more than ten modules were shipped with Docker CI/CD and systematic code review.
The thesis
The Master's thesis, from the M2 internship carried out at Stellar-IX, covers the same ground: virtual machine performance monitoring and dynamic billing. ClickHouse is chosen there after comparison with InfluxDB, TimescaleDB and Prometheus.
Virtubill
The thesis project, designed and built alone: a TypeScript Node.js API in Clean Architecture (customers, virtual machines, billing reports) and an Angular interface, containerised with Docker and shipped through GitLab CI/CD. The API syncs the inventory on a schedule and stores performance metrics in ClickHouse, where materialised views aggregate them by hour, day, week, month and year. The monthly report applies pricing rules: a discount or surcharge depending on an uptime threshold, plus resource and licence costs.
What can be checked
The code belongs to the company and is not published. The load-time gain is a declared figure, with no archived measurement. The FastAPI backend's git history (194 of 200 commits) and the thesis do exist.