Central Facility

Central Facility sits at the centre of a cloud C-ITS operational ecosystem. Roadside and in-vehicle systems register, emit events, and receive configuration; downstream consumers depend on validated, enriched event data reaching them reliably. Multiple operators and systems interact with those workflows through the platform—not through ad hoc integrations per deployment.

The backend coordinates ingestion, validation, enrichment, publishing, and monitoring. The frontend is where operators observe that work: station health, event state on the map, configuration with deployment-wide impact, and the workflows they run when something needs attention.

I led the frontend rebuild and architecture—replacing a surface that could not absorb more operational domains with a structured React SPA, clear route and store boundaries, and an explicit home for map-heavy event workflows.

Operational workflows were fragmented. Event coordination across systems lacked consistent visibility. Operators pieced together state from logs, side channels, and screens that did not share a mental model—health summaries, station metadata, live map events, and high-impact settings all lived in different corners of the product.

The frontend had to centralise that visibility without collapsing unrelated domains into one undifferentiated UI:

• Large operational datasets and near-real-time event streams
• Event lifecycle management from ingestion through publication
• State-heavy interactions across filters, toggles, and configuration drafts
• Filtering and search complexity across map entities and tabular views
• Keeping maps, tables, and event detail panels synchronised
• Operational responsiveness under incident load—not only on quiet afternoons

The frontend is organised around operational boundaries. Health, settings, station management, certificates, and the Events map each need predictable navigation, permissions, and state—without leaking into one another.

A shared authenticated shell wraps lazy-loaded feature routes. Global providers handle auth, theming, and data clients; MobX stores hold domain-specific operational state. The Events workflow gets its own provider stack and map store so map complexity does not flatten the global state tree or force unrelated screens to re-render when a layer toggles.

REST and GraphQL—including subscriptions where events need to stream—each appear where they fit the workflow. The architecture prioritises legible boundaries over forcing one fetch or state pattern everywhere.

Transport events move through a pipeline operators need to see and trust: ingestion from roadside and in-vehicle systems, validation, enrichment, then publication to downstream consumers. The frontend surfaces where an event sits in that progression—not as an abstract backend status, but as operational state operators can act on.

• Live event visualisation on the map, with overlays for traffic direction and cooperative ITS messaging where operators inspect what infrastructure is publishing
• Simulated events for test and rehearsal, driven through the same map tooling as live traffic so workflows stay familiar
• Correlation between map entities, list panels, and detail views—what is highlighted on the map is the same object the side panel describes

When an outage or bad configuration lands, operators often start on the map. The UI has to meet them there with accurate state, not send them hunting through raw logs.

Operational density is a design constraint, not something to hide. I focused on patterns that keep complex workflows scannable under pressure:

• Map and table coordination—selection, filters, and search driving the same operational entities across views
• Layer toggles and overlay inspection for live, simulated, and message-oriented event contexts
• Detail panels and workflow-driven UI that reflect event state without burying operators in fields that do not matter at 2 a.m.
• Guardrails on high-impact settings—what changes, for whom, and whether it propagates across the deployment

Inconsistency on an operations floor shows up as mistrust. Shared interaction behaviour—how toggles work, how panels sync with the map, how simulation mirrors live mode—mattered as much as component reuse.

I established reusable patterns so new operational areas could land as routes and stores instead of rewiring navigation from scratch each time.

• Authenticated shell, shared layout, and feature-based routing with lazy-loaded areas
• Reusable UI components for configuration, station ops, and diagnostics screens
• MobX-backed domain stores with clear separation between health, settings, station metadata, and map state
• Data fetching patterns aligned with GraphQL subscriptions for streaming operational reads and simpler REST where appropriate
• Filtering and search architecture local to the Events slice, keeping map redraws and entity updates predictable
• Storybook and conventions engineers could recognise months later—accessibility and stable markup as part of how components are built, not a polish pass at the end

These diagrams capture the two layers of frontend structure: the application shell that coordinates routes, providers, and data paths; and the Events slice where map state, filters, and operational interactions stay local to that workflow.

Application shell, routing, and data paths

The authenticated shell wraps feature routes for Events, dashboards, settings, and certificates. Domain stores and providers sit above REST and GraphQL services—keeping operational boundaries visible in the code.

Events and map sub-architecture

The Events workflow owns its own provider stack and map store. Filters, search, entities on the canvas, and simulation state stay isolated from global application state—so map interactions remain performant and debuggable.

• Operational frontend systems need honest domain boundaries. Health is not a special case of map state—and pretending otherwise makes debugging a mess under incident load.
• Complex event workflows benefit from a dedicated sub-architecture. Treating the map as a generic CRUD screen would have missed how operators actually work.
• State-heavy UIs require disciplined store design. Resisting one undifferentiated MobX root kept near-real-time views predictable on ordinary hardware.
• Map, table, and detail experiences must stay synchronised. Selection and filter state shared across views beats three independent implementations that drift.
• Maintainable architecture in a long-lived operational product means conventions people can extend without heroic context-loading—rebuild once with clear boundaries rather than patch indefinitely.
• Operational density and usability are not opposites. Specialists need fast scanning and the fields that matter when something breaks—not a simplified UI that hides the truth.