wild-cloud/wild-central
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs: Revised UI refactor — services as the entrypoint

Browse Source 
Complete rewrite of the UI refactor plan based on the insight that
services are the entrypoint for everything. DNS, certs, proxy routes
are effects of service registrations, not independent config surfaces.

Two sidebar sections: Services (outward-facing, service-driven) and
Central (inward-facing, device config). Each service page answers
"what did Central do because of registered services?"

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Paul Payne
2026-07-09 22:00:58 +00:00
parent a9249e32d8
commit 0646abb9af
1 changed files with 109 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files

210
working/ui-refactor.md
View File

@@ -1,138 +1,146 @@
# Wild Central UI Refactor
## Current Problems
## Core Insight
### 1. DNS is three overlapping pages
Everything flows from the **service**. When a service is registered, Central lights up the components it needs: DNS records, proxy routes, TLS certs, DDNS records. The other pages aren't independent configuration surfaces — they're views into the effects of service registrations.
- `/central/dns` — hybrid view showing both LAN DNS (dnsmasq) and DDNS (Cloudflare A records)
- `/central/lan-dns` — duplicates the LAN DNS portion of `/dns`
- `/central/ddns` — separate DDNS page
This creates two clear sections:
A user configuring DNS doesn't know where to go. Three pages, overlapping scope, no clear ownership.
- **Services section** — the service-driven system. Everything here exists because services were registered (or because services need it to function). This is what Wild Cloud and Wild Works interact with.
- **Central section** — the device itself. Firewall, VPN, security, DHCP. These exist whether or not any services are registered. This is the appliance config.
### 2. Cloudflare is scattered across three pages
The Cloudflare API token is needed by DDNS, certificates, and tunnels — but each is configured in a different section. First-time setup requires hopping between Cloudflare, DDNS, and Certificates pages.
### 3. "Ingress Proxy" is jargon
Shows registered services and HAProxy config. "Ingress" is Kubernetes terminology. Most users think "reverse proxy" or just "services." The registered services display deserves to be the primary view — that's what consumers (Wild Cloud, Wild Works) care about, not HAProxy stats.
### 4. The sidebar order is arbitrary
No grouping by function. DNS next to Ingress next to Firewall next to VPN. A user doing initial setup can't follow a logical flow.
### 5. Overview is nearly empty
Just operator email and a restart button. Should be a status dashboard: are all daemons running? How many services registered? Any certs expiring? Any security alerts?
## Current Navigation (9 items, flat)
## Navigation
```
Services
├── Dashboard (default landing — health, warnings, at-a-glance status)
├── Cloudflare (THE setup page — token, zones, tunnel. Prerequisite for everything)
├── Services (registered services — the primary config surface)
├── DNS (complete DNS picture — internal + external resolution per service)
└── Certificates (TLS status per service — what's provisioned, what's missing)
Central
├── Overview → operator email, restart button
├── Cloudflare → API token verification
├── DNS → LAN DNS + DDNS hybrid (confusing)
├── Ingress Proxy → HAProxy + registered services (jargon)
├── Firewall → nftables rules
├── VPN → WireGuard server + peers
├── Certificates → TLS cert provisioning
├── CrowdSec → intrusion detection
└── DHCP → DHCP server + leases
├── Firewall (nftables rules)
├── VPN (WireGuard server + peers)
├── CrowdSec (intrusion detection)
└── DHCP (IP address assignment + leases)
```
Hidden/redundant pages (routed but not in sidebar):
- `/central/lan-dns` — duplicate of DNS page
- `/central/ddns` — separate DDNS page
## Page Designs
## Proposed Navigation (9 items, better organized)
### Dashboard
```
Central
├── Dashboard → system health, daemon status, registered services count, cert warnings
├── Services → registered services from Wild Cloud/Works (the primary consumer view)
├── DNS → LAN DNS config (dnsmasq only, one page)
├── Cloudflare → token + DDNS records + tunnel status (all in one place)
├── Certificates → TLS cert status and provisioning
├── Firewall → nftables rules
├── VPN → WireGuard server + peers
├── CrowdSec → security alerts + decisions
└── DHCP → DHCP server config + leases
```
The landing page. At-a-glance system health:
- Daemon statuses: dnsmasq ✓, haproxy ✓, wireguard ✓, crowdsec ✓
- Registered services: 9 services (7 public, 2 internal)
- Certificates: 2 valid, 1 missing — ⚠ warning
- DDNS: synced, public IP 216.243.55.15
- Cloudflare: token valid ✓
- Warnings/actions: "wild-cloud.payne.io needs a TLS cert → Provision"
## What Changes
If Cloudflare isn't configured, the dashboard shows a prominent setup prompt directing the user there first.
### Overview → Dashboard
### Cloudflare
Replace the empty overview with a status dashboard showing:
- All daemon statuses (dnsmasq, haproxy, nftables, wireguard, crowdsec) — green/red
- Registered services count + breakdown by source
- TLS cert warnings (expiring soon, missing)
- Recent security alerts (from CrowdSec)
- DDNS sync status
- Quick links to configure missing items
The prerequisite page. Everything public depends on this:
- API token management (set, verify, show accessible zones)
- Tunnel status (cloudflared connection, connected services)
- DDNS provider config (which records to sync, current public IP, last sync)
### Ingress Proxy → Services
This is the first page a new user configures. Without the token, public DNS and TLS certs don't work — the UI should make this dependency obvious.
Rename and restructure:
- Primary view: list of registered service domains with status, reach, subdomains indicator
- Each service row shows: domain, backend, type (L4/L7), reach (internal/public), TLS mode
- Collapsible "Advanced" section for HAProxy raw config, stats, generate/restart
- Remove HAProxy jargon from the primary view
### Services
### DNS consolidated
THE primary interaction surface. Every registered service in one table:
Kill `/central/lan-dns` (duplicate) and `/central/ddns` (moved to Cloudflare):
- One DNS page showing dnsmasq config: listen address, upstream servers, active DNS entries
- DHCP stays separate (it's dnsmasq too, but different concern)
- DDNS moves to Cloudflare page (it's a Cloudflare API concern)
| Domain | Backend | Type | Reach | DNS | TLS | DDNS |
|--------|---------|------|-------|-----|-----|------|
| cloud.payne.io | 192.168.8.240:443 | L4 passthrough | public | ✓ resolves | ✓ passthrough | ✓ A record |
| *.cloud.payne.io | (same) | L4 wildcard | public | ✓ resolves | ✓ passthrough | — |
| central.payne.io | 127.0.0.1:15055 | L7 proxy | internal | ✓ resolves | ✓ 88d left | — (internal) |
| wild-cloud.payne.io | 127.0.0.1:5055 | L7 proxy | internal | ✓ resolves | ⚠ missing | — (internal) |
| payne.io | 192.168.8.240:443 | L4 exact | public | ✓ resolves | ✓ passthrough | ✓ A record |
### Cloudflare becomes one-stop shop
Each row shows the **complete status** of one service — every effect Central provides for it. The user sees immediately: "wild-cloud.payne.io is missing a TLS cert." Click a row to see details or take action.
Consolidate:
- API token management (from current Cloudflare page)
- DDNS records (from current DDNS page)
- Tunnel status (currently missing from UI entirely)
- All three share the same Cloudflare token — configure once, see all effects
Central's own domain (from config) appears in this table too — it's just another service from the user's perspective.
### First-time user flow
The service detail view shows:
- All the effects (DNS entry, proxy route, TLS cert, DDNS record)
- The registration source (wild-cloud, wild-works, config)
- Actions: provision cert, change reach, deregister
The navigation should support a linear setup flow:
HAProxy raw config, stats, and generate/restart move to a collapsible "Advanced" section at the bottom.
1. **Dashboard** — see what's running, what needs attention
2. **Cloudflare** — set API token (enables DDNS + certs)
3. **DNS** — verify LAN DNS is configured
4. **Certificates** — provision TLS certs
5. **Services** — registered services appear as Wild Cloud/Works connect
### DNS
## Pages to delete
The **complete DNS picture** for all services. Not a configuration page — a status view showing how every domain resolves, from both inside and outside the network.
- `LanDnsPage.tsx` — duplicate, fold into DNS
- `DdnsPage.tsx` — fold into Cloudflare
- `LanDnsComponent.tsx` — duplicate component
For each service domain:
| Domain | Internal (LAN) | External (Internet) |
|--------|---------------|---------------------|
| cloud.payne.io | 192.168.8.240 (direct to k8s LB) | 216.243.55.15 (via DDNS) |
| central.payne.io | 192.168.8.151 (Central) | — (internal only) |
| internal.cloud.payne.io | 192.168.8.240 (with local=/) | — (never forwarded) |
## Pages to rename
Plus DNS server infrastructure status:
- dnsmasq: running ✓, listening on 192.168.8.151
- Upstream forwarders: 1.1.1.1, 8.8.8.8
- DDNS sync: last checked 2m ago, public IP 216.243.55.15
This replaces the three overlapping DNS pages (dns, lan-dns, ddns) with one coherent view.
### Certificates
TLS cert status for every service that needs Central to terminate TLS:
| Domain | Status | Expires | Issuer | Action |
|--------|--------|---------|--------|--------|
| central.payne.io | ✓ valid | 88 days | Let's Encrypt | Renew |
| wild-cloud.payne.io | ⚠ missing | — | — | Provision |
Services with TLS passthrough (k8s instances) don't appear here — their backend handles TLS.
"Provision" and "Renew All" buttons. "Add Wildcard" for opt-in wildcard certs.
Requires Cloudflare token — if not configured, shows a prompt directing to Cloudflare page.
### Firewall, VPN, CrowdSec, DHCP
These are Central's own infrastructure config. Not service-driven. Each is its own page under the "Central" sidebar section. No changes needed to their content — just the grouping.
## Key Design Principles
1. **Services are the entrypoint.** Every page in the Services section answers: "what did Central do (or need to do) because of the services registered with it?"
2. **Status over configuration.** DNS and Certificates pages are primarily status views — they show the effects of service registrations. The user configures services, not DNS entries directly.
3. **Dependencies are visible.** Dashboard warns if Cloudflare isn't configured. Certificates page warns if token is missing. Services page shows which effects are green vs red.
4. **Two sections, two concerns.** Services = outward-facing (what Central does for consumers). Central = inward-facing (what the device does for itself).
## Migration
### Pages to delete
- `LanDnsPage.tsx` — duplicate
- `DdnsPage.tsx` — folded into Cloudflare
- `LanDnsComponent.tsx` — duplicate
### Pages to rename
- `CentralPage.tsx` → `DashboardPage.tsx`
- `IngressProxyPage.tsx` → `ServicesPage.tsx`
- `IngressProxyComponent.tsx` → `ServicesComponent.tsx`
- `CentralComponent.tsx` → `DashboardComponent.tsx`
## Sidebar items to rename
### Pages to rewrite
- `DashboardComponent` — new status dashboard (currently just operator email)
- `ServicesComponent` — new service table with per-service effect status
- `DnsComponent` — unified DNS view (internal + external per service)
- `CloudflareComponent` — add DDNS management and tunnel status
### Sidebar changes
- Two labeled groups: "Services" and "Central"
- "Overview" → "Dashboard"
- "Ingress Proxy" → "Services"
## Sidebar icons
| Item | Current Icon | Proposed Icon |
|------|-------------|---------------|
| Dashboard | Server | LayoutDashboard |
| Services | Network | Globe |
| DNS | Router | Router (keep) |
| Cloudflare | Cloud | Cloud (keep) |
| Certificates | ShieldCheck | ShieldCheck (keep) |
| Firewall | Shield | Shield (keep) |
| VPN | Lock | Lock (keep) |
| CrowdSec | ShieldAlert | ShieldAlert (keep) |
| DHCP | Wifi | Wifi (keep) |
- Remove DNS/LAN DNS/DDNS → replace with single "DNS"
- Add DDNS content to Cloudflare page