ADR-0007: Angular Frontend with Server-Side-Only Enforcement¶
- Status: accepted
- Date: 2026-06-04
- Deciders: Nicolas Burri
Context¶
The frontend technology was tentatively Angular (project_overview.md), alternatives open for discussion. Multi-language support is required (Swiss language regions, possibly EU). A decisive lens: LQMS will undergo Computerized System Validation (CSV, GAMP 5 / ISO 13485 §4.1.6) as a QMS tool — the validated state must be maintained across changes, making upgrade predictability and dependency surface part of the decision.
Options Considered¶
The framework choice itself is nearly CSV-neutral: LQMS is custom software (GAMP Category 5) regardless, validation is black-box against requirements, and all major frameworks are equally automatable with modern E2E tooling. The differentiators are operational:
Angular¶
- Pros: batteries-included (router, forms, http, i18n in one framework) → small SOUP surface; published LTS schedule (majors ~every 6 months, 18-month support windows) → re-validation is plannable and batchable; TypeScript-first; strong fit for form-heavy enterprise UIs.
- Cons: heavier framework; smaller hiring pool than React.
React (+ ecosystem)¶
- Pros: largest ecosystem and talent pool; flexible.
- Cons: the stack is assembled from many independently-churning packages → larger SOUP list, more unsolicited change-control triggers, upgrades harder to batch into planned validation windows.
Vue¶
- Pros: lean, approachable; middle ground on ecosystem assembly.
- Cons: same multi-package churn as React in practice (router, state, i18n separate); smallest enterprise track record of the three.
Decision¶
Angular, as a separate application consuming the REST API (ADR-0005). The i18n mechanism (Angular built-in i18n vs. ngx-translate) is an implementation-time detail.
Two binding principles accompany the choice:
- The frontend is never an enforcement point. All compliance-relevant rules — four-eyes, transition permissions, review policies, scope separation — are enforced exclusively server-side (as ADR-0002/0003 already guarantee). The frontend only reflects permissions. Consequence: frontend defects cannot produce compliance-relevant failures, keeping their risk classification and the depth of per-change frontend re-validation low.
- The automated E2E suite is validation evidence, not just QA. It serves as the regression evidence for maintaining the validated state after changes. Testability is therefore a frontend requirement: stable selectors, seedable test data, deterministic flows.
Consequences¶
- Frontend dependencies join the SOUP list; Angular's LTS calendar drives planned upgrade/re-validation windows (configuration management plan).
- E2E tooling (Playwright or Cypress — TBD at scaffolding) becomes part of the verification plan's system level.
- API design must expose effective permissions so the UI can reflect them without duplicating rule logic.
- Multi-language support is designed in from the first screen — retrofitting i18n is expensive; catalog entries already carry translations (ADR-0004).