HAP

HAP sits between government transport data operations and external data consumers. Agency datasets arrive with different structure, freshness, and quality; the platform normalises them into records operators can govern, then publishes through APIs and messaging so downstream systems integrate once—not per source system.

That work spans configuration, transformation, quality validation, publication, and ongoing monitoring. The frontend is the operational layer where stewards, partners, and platform admins manage those workflows day to day.

I lead the frontend architecture across both applications—how the apps are split, how shared patterns stay consistent, and how complex data workflows remain understandable for non-engineering users.

Transport data publication was fragmented. Operators faced manual publishing overhead, limited visibility into data quality, and awkward partner self-service. Platform teams needed operational monitoring without opening every log line. When publication failed, the issue was often visibility—not a silent backend failure.

The frontend had to support that reality without splintering into two unrelated codebases:

• Multi-tenant organisation context across publishing and admin workflows
• RBAC-aware routes, navigation, and actions for different user roles
• Complex configuration flows for datasets, transformations, and quality rules
• Shared code and conventions across two products with different audiences
• Data-dense dashboard UX that stays readable under operational load

Data Exchange and Control Centre are independent SPAs with different users and risk profiles. Both share a frontend monorepo: layout shell, UI primitives, auth helpers, Apollo/GraphQL infrastructure, MobX store patterns, and typed codegen. That keeps everyday frontend work in one place while permissions and mental models stay split across two apps.

Data publishing flow

Transport data moves through ingestion, transformation toward DATEX-II where required, quality validation, and publication—only then is it reliable input for navigation providers and other downstream consumers.

Frontend architecture

Both applications sit on shared UI and runtime foundations, then connect to AppSync GraphQL and the platform services behind publication, validation, and transport data workflows.

Data Exchange is the partner and publishing portal—where data owners and stewards configure datasets, manage access, and follow publication workflows within their organisation context.

• Dataset configuration, source feeds, data sources, and transformations toward published outputs
• Quality rules and data quality visibility across the ingestion-to-publication pipeline
• API keys, members, and organisation-scoped administration for partner and self-service access

The UX aligns with how records are actually governed—operators can see where a dataset sits, what failed validation, and what is live without piecing it together from ad hoc reports.

Control Centre is the internal operations console—where platform admins monitor health, investigate incidents, and administer organisations across the HAP estate.

• Availability, incidents, logs, metrics, and impact alerts
• Operational dashboards for platform visibility under load
• Organisation administration and cross-tenant oversight

Internal tooling has to tell the truth about state. These screens give operators enough signal to run the platform without inheriting the noise meant for publishing workflows.

I structured the frontend as shared-first: new work starts in common packages unless there is a clear reason to keep it app-specific.

• Reusable AppLayout, DataTable, and UI primitives across both applications
• Shared organisation, member, and API key flows used by Data Exchange and Control Centre
• GraphQL codegen for typed operations aligned with AppSync schemas
• Storybook documentation for component APIs and integration patterns
• Accessibility and testing built into the workflow—WCAG 2.1 expectations, Vitest and Testing Library for units, Playwright for critical flows

Users operate in public context or within a selected organisation. I designed MobX stores to reset on organisation switch so data from one tenant does not leak into another session.

Navigation, routes, and actions are RBAC-aware across Admin, Write, Read, and Public roles. Sidebar entries, page access, and destructive actions reflect what the signed-in user is permitted to do in the current context—not a single undifferentiated UI with permissions patched on later.

• Multi-tenant enterprise UIs need explicit context boundaries. Organisation-scoped state and RBAC cannot be an afterthought when publication workflows carry real operational risk.
• Two apps with different audiences still benefit from one shared architecture—provided the split is enforced in routing and repository structure, not only in documentation.
• GraphQL/AppSync integration works best when validation feedback and lifecycle transitions live in the API layer the UI reads—not in ad hoc client-side guessing.
• Data-dense operational dashboards need disciplined patterns. Reusing table, status, and lifecycle components beats hand-cutting a new screen for every dataset variation.
• Accessibility, testing, and Storybook are part of sustainable delivery—not a polish pass at the end of a long programme.