Architecture
Dashboard Hub is implemented by the Omega Watch microfrontend and Spring Boot service. Operators interact with hubs and widgets in the browser; the service owns persistence, registries, and secure query proxying.
System shape
Qinfinite Shell (Single-SPA)
│
▼
Dashboard Hub Client (Omega Watch / React)
│ REST APIs
▼
Omega Watch Service (Spring Boot)
│
├── MongoDB (hubs, dashboards, containers, widgets, preferences)
├── Widget / hub / template registries (JSON seed)
└── Analytical proxies (for example CrateDB SQL)
Key Components
Web client
| Capability | Detail |
|---|---|
| Hubs and lists | Entry screens for hubs and dashboards |
| Editor | Containers, widgets, filters, save/refresh chrome |
| Widget configuration | Type selection, data binding, preview |
| State management | Zustand store with dashboard/tab/container/widget actions |
| Delivery modes | Standalone Vite app or Single-SPA microfrontend |
| Theming | Light/dark and accent variants aligned with the shell |
Omega Watch service
| Capability | Detail |
|---|---|
| Dashboard engine | CRUD lifecycle for multi-container dashboards |
| Hub APIs | Workspace organization for dashboards |
| Widget registry | Extensible widget-type definitions |
| Container templates | Seeded layout starters |
| Preferences | Per-user container/widget arrangement |
| CrateDB / SQL proxy | Authenticated analytical query execution |
| Data seeding | Bootstrap from hubs.json, widget-types.json, and related templates |
Local service port is commonly 9090 with MongoDB database omega-watch.
API surface (conceptual)
| Area | Base path | Responsibility |
|---|---|---|
| Hubs | /api/hubs | Hub CRUD and hub-scoped dashboard listing |
| Dashboards | /api/dashboards | Dashboard CRUD, publish/unpublish, assignments |
| Containers | /api/containers and dashboard nested routes | Layout container management |
| Widgets | /api/widgets | Registry and widget instances / data |
| Preferences | /api/preferences/... | Personal layouts |
| Analytical proxy | /api/cratedb (or equivalent) | SQL execution for database-backed widgets |
Treat path details as deployment-specific; gateway prefixes may wrap these routes in enterprise environments.
Data flow
User edits dashboard
→ Client store updates
→ REST calls persist hubs/dashboards/containers/widgets
→ Widget render requests data
→ Service resolves source (mock/API/SQL/BizOps/catalogue)
→ Payload mapped and drawn in the widget
→ Refresh strategy schedules the next fetch or waits for push
Security notes
| Concern | Approach |
|---|---|
| Auth | Session cookie via BFF or bearer token via API gateway |
| Secrets | Analytical and system credentials stay on the service |
| Authorization | Hub-scoped IAM features for manage/view/publish/export |
| Browser isolation | Microfrontend mount under the shell; avoid leaking host credentials into widget config |
How Dashboard Hub relates to BizOps Engine
| Product | Stores | Primary users |
|---|---|---|
| BizOps Engine | Projects, processes, jobs, workflows | Automation builders / operators |
| Dashboard Hub | Hubs, dashboards, widgets | Operators, leads, business stakeholders |
Use Engine to change how work runs; use Dashboard Hub to show whether outcomes and health match business expectations.