Difficulty: Expert | Type: Architecture / Performance
Background: Live mode entirely depends on NEXT_PUBLIC_CORE_API_URL being reachable; there's no documented behavior for what happens when the guildpass-core backend is temporarily down or slow.
Problem: A backend outage currently likely results in a broken or fully non-functional frontend for all users simultaneously, with no graceful degradation — even read-only, previously-fetched data (e.g. a member's own last-known membership status) becomes unavailable.
Expected Outcome: The app detects backend unavailability and falls back to a clearly-labeled "offline/degraded" mode showing the last successfully cached data (with a visible staleness indicator) for read-only views, while clearly disabling mutations that require a live connection.
Suggested Implementation: Layer a persistent cache (e.g. React Query's built-in persistence to localStorage with a TTL) on top of the existing query layer, add network/backend-health detection (building on the health-check idea from #8), and design explicit UI states for "showing cached data, may be stale" vs. "action unavailable, backend unreachable."
Acceptance Criteria:
- Simulated backend outage (mock mode scenario) results in cached read views remaining visible with a staleness indicator, not a blank/broken page.
- Mutating actions are clearly disabled (not silently failing) during detected outages.
- Recovery (backend becoming reachable again) is detected and the degraded banner clears automatically.
- Design doc covers cache staleness/security tradeoffs (e.g. should sensitive admin data ever be cached this way).
Likely Affected Files/Directories: lib/api/live.ts, lib/api/, app/layout.tsx
Labels: architecture, performance, GrantFox OSS, Maybe Rewarded, Official Campaign | FWC26
Difficulty: Expert | Type: Architecture / Performance
Background: Live mode entirely depends on
NEXT_PUBLIC_CORE_API_URLbeing reachable; there's no documented behavior for what happens when theguildpass-corebackend is temporarily down or slow.Problem: A backend outage currently likely results in a broken or fully non-functional frontend for all users simultaneously, with no graceful degradation — even read-only, previously-fetched data (e.g. a member's own last-known membership status) becomes unavailable.
Expected Outcome: The app detects backend unavailability and falls back to a clearly-labeled "offline/degraded" mode showing the last successfully cached data (with a visible staleness indicator) for read-only views, while clearly disabling mutations that require a live connection.
Suggested Implementation: Layer a persistent cache (e.g. React Query's built-in persistence to
localStoragewith a TTL) on top of the existing query layer, add network/backend-health detection (building on the health-check idea from #8), and design explicit UI states for "showing cached data, may be stale" vs. "action unavailable, backend unreachable."Acceptance Criteria:
Likely Affected Files/Directories:
lib/api/live.ts,lib/api/,app/layout.tsxLabels:
architecture,performance,GrantFox OSS,Maybe Rewarded,Official Campaign | FWC26