[RFC] Frontend Architecture Strategy for V1.0

[Arian-Ott]

Summary

This RFC proposes the architectural design for the initial Hyperion User Interface (V1.0). The goal is to establish a decoupled Single Page Application (SPA) that interacts with the existing Python/FastAPI backend via WebSockets to provide a collaborative, real-time control surface for DMX lighting.

Motivation

Currently, Hyperion operates as a headless backend. To reach feature parity with established lighting controllers, a GUI is required.

Unlike traditional CRUD applications, a lighting controller requires:

• High-frequency state updates (visualizing fader movements from other clients).
• Low-latency command injection (user input to DMX output).
• Multi-User Consistency (multiple clients modifying the same Redis state simultaneously).

Technical Constraints & System Design

1. Client-Server Communication

The communication layer must transition from a request/response model to an event-driven model for runtime operations.

Command Channel (WebSocket): Used for all real-time interactions (e.g., show.create). The payload must use a compact JSON structure to minimize serialization overhead.

{
  "cmd": "show.create",
  "data": {"name": "foo"}
}

State Propagation (Server -> Client): The backend serves as the Single Source of Truth. The frontend must not maintain a derived state that drifts from the backend Redis store.

2.Multi-User Synchronization Strategy (future versions)

To support multiple concurrent operators, the architecture must handle race conditions:
Optimistic UI: The client renders changes immediately upon user interaction.

Reconciliation: If the backend rejects a change or another user overrides it, the client must roll back to the authoritative server state received via WebSocket broadcast.

3. Performance Requirements

Rendering: The DOM update cycle must be decoupled from the network cycle to prevent UI blocking during burst traffic.

Latency: The architectural overhead (UI Event -> WebSocket Message -> Python Handler) should be minimized to ensure tactile responsiveness.

Proposed Stack (Open for Discussion)

The following stack is proposed for the implementation. The community is invited to validate or challenge these choices based on the performance requirements above.

Runtime: Browser-native (ES Modules).

Build Tooling: Vite (for fast HMR and optimized bundling).

Framework: Open Question – React, Vue, or Svelte?

Constraint: Must support efficient re-rendering of large lists (e.g., patch grids with 512+ cells) without virtualization artifacts.

State Management: Open Question – Needs to handle ephemeral WebSocket streams efficiently.

[Arian-Ott]

Going forward, Hyperion will use vue 3 as its frontend framework. It is the most simple solution at that point.