Oneapp

Context & problem

Marketing reporting data sat in backend services; the reporting screens needed it in a shape they could render. There was no agreed contract between the two, so integrating and displaying that data was the slow part of the work.

Users & team

Marketing reporting users. I worked with the backend team, who owned the services the report data came from.

Personal contributions

• Mapped the reporting data the frontend actually needed, with the backend team.
• Aligned the API contract to that map.
• Validated responses before rendering them.
• Reworked how the application retrieves and processes report data.

Architecture & decisions

Vue.js and Quasar on the frontend, Golang with Gin on the backend, PostgreSQL for storage.

The decision that mattered was sequencing: agree the data map first, fix the contract second, adjust the frontend last. Settling the shape at the contract meant the frontend no longer had to compensate for responses it could not predict.

Key features

• Report data served through defined API services.
• Responses validated before they reach the screen.
• Retrieval and processing of report data handled in one place on the frontend.

Challenges & solutions

The hard part was not fetching the data but agreeing on it. The frontend needed specific fields in a predictable shape, while the backend exposed what its services already held.

Mapping the required fields first gave both teams one reference to build against. The API contract was then fixed to that map, responses were validated on arrival, and the retrieval and processing flow was simplified to match.

Results

Report data now moves through one agreed API contract, so what the report displays matches what the backend returns.