About the Project

This case study details the development of a Compliance Reporting Platform, focusing on the challenges and solutions related to rendering architecture and execution architecture. The primary goal was to create customer-facing compliance reports that visually matched the product's branding and were paginated, with preview capabilities. The backend was primarily built using Go.

Key Features and Decisions

• Frontend Rendering: The decision was made to build the report within the existing Next.js frontend to leverage its design system, including typography, color tokens, tables, badges, and spacing conventions. This avoided duplicating presentation logic and ensured consistency with the product's visual language.

• SSR for Rendering: Server-Side Rendering (SSR) was employed using a special route and a short-lived token. This allowed a headless browser (Chromium) to receive substantially rendered HTML, optimizing the print pipeline process.

• Report Variants: The platform supported five distinct report projections (DEFAULT, OWNER_WISE, INDIVIDUAL_OWNER_WISE, CLOUD_WISE, INDIVIDUAL_CLOUD_WISE), all sharing a common document shell and data structure but adapting the presentation of sections based on the selected type.

• Dual Render Modes: The same HTML structure was styled differently for browser previews (scrollable, anchor navigation) and for printing to PDF. This was achieved using CSS, including @media print and paged-media CSS properties, to control layout, page breaks, headers, and footers.

• Asynchronous Generation: Report generation was designed as an asynchronous job, allowing users to configure reports and return to the product while the job processed. This provided a non-blocking user experience.

Outcome and Learnings

While the document architecture successfully addressed the presentation and maintainability requirements, the deployment model faced challenges with resource management under heavy load. The chromedp/Chromium process significantly increased memory pressure, leading to rollbacks of automated PDF generation. The key takeaway is the distinction between rendering architecture and execution architecture, emphasizing the need for explicit capacity management for resource-intensive workloads like browser rendering.

Future Improvements

Recommendations for future iterations include:

• Scoping rendering credentials with least-privilege tokens.

• Creating a single, unified document tree for all report elements.

• Bounding the renderer in dedicated workers with strict concurrency and resource controls.

• Benchmarking alternative renderers like Typst before committing to a rewrite.