Textile product information manager

Fabric specifications lived in spreadsheets and in the heads of the people who maintained them. Every specification sheet was laid out by hand in a design tool, so a corrected composition or care instruction meant reopening and re exporting each document, and the version a customer received was rarely the current one.

The data model is the product. Textiles have real relationships to model: compositions, finishes, care requirements, commercial classifications and business lines, each with its own constraints. Those live as typed enumerations and relations in Postgres, defined once in a schema that the application and its validation share, so an invalid record cannot be written from any screen. Large catalog views are virtualized so browsing thousands of records stays responsive.

Specification sheets are generated on demand rather than stored. The route renders an internal, print styled page in a headless browser and returns a paginated document. The browser instance is reused across requests, since starting one per request is the difference between a fast response and a timeout. Two sheet variants exist for different audiences, and both render in either language from the same source data, which removes the manual layout step entirely.

Rendering documents from a live page instead of composing them with a document library was a deliberate trade. It means the sheet is styled with the same tools as the rest of the interface, and a designer can adjust the layout without touching generation code. The cost is a heavier runtime, which is why the browser is shared and why the route validates the record before spending one.

Sheets are generated per request rather than cached to storage. For this catalog the render is fast enough that a stale document was the bigger risk, and it removes a whole class of invalidation bugs.