How rqkeebhasan-png/efootball- works
1. Overall shape
- This is a single-page React app for eFootball tournament operations.
- The frontend is the primary application; the backend is Supabase providing Auth, Postgres, Storage, and Realtime.
- There is no custom server in the repo; all business data flows directly from the UI to Supabase.
2. Application shell and routing
- src/main.tsx and src/App.tsx define the app bootstrap and route composition.
- src/components/layout/AppLayout.tsx and Navbar.tsx provide the shared shell for authenticated areas.
- ProtectedRoute.tsx enforces route-level access control, likely based on login state and user role.
3. Role-based surface area
- The app is split into two major user domains: player and admin.
- Player pages live under src/pages/player/ and cover dashboard, tournaments, matches, profile, public profile, and search.
- Admin pages live under src/pages/admin/ and cover dashboard, tournament CRUD, player management, reviews/disputes, and tournament details.
4. Authentication and session state
- src/hooks/useAuth.ts and src/store/authStore.ts form the auth boundary.
- Supabase Auth is the source of truth for login/session.
- The auth store likely mirrors the current user, profile, and role so the UI can render player vs admin views and gate protected routes.
5. Tournament domain flow
- useTournament.ts feeds tournament-related pages and components such as TournamentCard, BracketView, and AdminTournamentDetailPage.
- The tournament flow includes listing tournaments, viewing bracket state, creating/editing tournaments, and navigating into a specific tournament’s matches and bracket.
- src/utils/bracket.ts is an important domain utility: it encapsulates single-elimination bracket generation and seeding logic.
6. Match lifecycle
- useMatch.ts connects match pages and match components such as MatchCard and SubmitResultModal.
- The main match flow is: players view assigned matches, submit a result with proof, and then the system either auto-confirms or sends the result into a review path.
- The 1-hour result window and default-win behavior are part of the domain rules surfaced in the UI and enforced through backend data/state.
7. Dispute and moderation path
- Admin review pages (AdminReviewsPage.tsx) indicate a moderation queue for disputed or unconfirmed match outcomes.
- This creates a separate control flow from ordinary player interactions: player submissions move into either confirmation or referee review.
- AdminPlayersPage.tsx and SuspendedPage.tsx show that account status is also an administrative concern.
8. Realtime notifications
- src/store/notificationStore.ts and src/components/player/NotificationPanel.tsx form the in-app notification subsystem.
- README indicates Supabase Realtime drives updates, so notifications are likely pushed from backend changes into the UI without polling.
- This subsystem is separate from core routing and is used to surface match updates, confirmations, and admin actions.
9. Supabase data boundary
- src/lib/supabase.ts is the central client boundary for all backend access.
- The app depends on Supabase for:
- Auth: login, register, password reset
- Database: tournaments, profiles, matches, reviews, roles
- Storage: screenshot uploads for match proofs
- Realtime: notification delivery and live status changes
- The migrations under supabase/migrations/ define the persistence model and security rules.
10. Security and authorization model
- 002_rls_policies.sql is architecturally important because it enforces row-level security in the database, not just in the UI.
- Role checks are therefore layered:
- route/UI gating in the frontend
- RLS policies in Supabase
- This matters for diagramming because the trust boundary is not in the client; Supabase is the enforcement point.
11. File upload and media handling
- 003_storage_buckets.sql shows a dedicated storage layer for screenshot evidence.
- Match result submission therefore has a two-part write path: structured data into the database and proof media into storage.
- The storage bucket is part of the app’s core match verification workflow, not an optional add-on.
12. UI component architecture
- src/components/ui/ contains the reusable design system primitives: buttons, cards, forms, inputs, etc.
- Feature components are grouped by domain (layout, tournament, match, player) rather than by technical layer.
- This keeps tournament and match flows composed from shared primitives without duplicating UI scaffolding.
13. Data and formatting helpers
- src/types/ centralizes the domain model shape used across hooks, pages, and components.
- src/utils/format.ts handles presentation formatting, while bracket.ts handles tournament logic.
- These utilities sit between raw Supabase data and rendered UI, translating backend records into domain-aware view models.
14. Delivery and runtime
- The app is built with Vite, styled with Tailwind CSS, and hosted on GitHub Pages.
- .github/workflows/deploy.yml provides CI/CD that builds and deploys the static frontend on pushes to main.
- Environment configuration is client-side only via VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY, which is consistent with a static hosting architecture.
15. How to draw the architecture
- A good diagram would show:
- Users entering the React/Vite SPA
- The SPA routing into player and admin areas
- Frontend hooks/stores calling the Supabase client
- Supabase splitting into Auth, Postgres with RLS, Storage, and Realtime
- A separate GitHub Actions → GitHub Pages deployment path for the frontend build
- The main boundary is between the client app and Supabase; most business behavior is implemented as frontend domain logic plus backend data/security rules.
Main entry points: App.tsx App · supabase.ts Supabase client · player Player area · useMatch.ts Match flow
Components 19
Frontend app
React/Vite SPA, feature routes, and shared UI.
- main · Vite entrypoint that mounts the React app.
src/main.tsx - App · Top-level route composition for the single-page app.
src/App.tsx - App shell · Shared authenticated layout and navigation chrome.
src/components/layout/AppLayout.tsx - Protected route · Route guard for login and role-based access.
src/components/layout/ProtectedRoute.tsx - Auth hook · Connects UI state to Supabase auth session and profile.
src/hooks/useAuth.ts - Auth store · Mirrors current user, profile, and role for the UI.
src/store/authStore.ts - Player area · Player-facing tournament, match, profile, and search pages.
src/pages/player - Admin area · Operations surface for tournaments, players, and reviews.
src/pages/admin - Tournament flow · Fetches and coordinates tournament listing and detail state.
src/hooks/useTournament.ts - Match flow · Drives assigned matches, result submission, and review paths.
src/hooks/useMatch.ts - Notifications · In-app notification panel fed by live backend updates.
src/store/notificationStore.ts - UI kit · Reusable buttons, cards, forms, and inputs.
src/components/ui - Domain utils · Bracket generation and display formatting helpers.
src/utils
Supabase backend
Managed auth, database, storage, realtime, and security rules.
- Supabase client · Central client used by the frontend to reach Supabase services.
src/lib/supabase.ts - Supabase Auth · Login, registration, password reset, and session source of truth.
- Postgres + RLS · Persistent tournament, profile, match, review, and role data with row-level security.
supabase/migrations - Storage bucket · Screenshot evidence uploads for match proof.
supabase/migrations/003_storage_buckets.sql - Realtime · Pushes live updates for match status and notifications.
Delivery
Static build and deployment pipeline for the frontend.
- Deploy workflow · Builds and publishes the static frontend to GitHub Pages.
.github/workflows/deploy.yml
Connections 25
- main → App: mounts · Bootstraps the SPA root.
- App → App shell: uses · Wraps authenticated views in the shared shell.
- App → Protected route: guards · Applies route access control.
- App → Player area: routes · Sends logged-in players to player pages.
- App → Admin area: routes · Sends admins to operations pages.
- Protected route → Auth hook: checks session · Reads login and role state for gating.
- Auth hook → Auth store: syncs · Keeps current user and role in local UI state.
- Auth hook → Supabase client: calls · Uses the shared client for auth and profile access.
- Player area → Tournament flow: loads · Player views depend on tournament data.
- Player area → Match flow: loads · Player views depend on match data and submissions.
- Player area → Notifications: shows · Surfaces live notifications in the player surface.
- Admin area → Tournament flow: manages · Admin CRUD and detail pages use tournament state.
- Admin area → Match flow: reviews · Moderation flows inspect submitted match outcomes.
- Match flow → Storage bucket: uploads proof · Sends screenshot evidence to storage.
- Match flow → Postgres + RLS: writes results · Persists results, confirmations, and review records.
- Tournament flow → Postgres + RLS: reads/writes · Uses persisted tournament and bracket data.
- Notifications → Realtime: subscribes · Receives pushed updates from backend events.
- Supabase client → Supabase Auth: auth · Routes sign-in and session calls to Supabase Auth.
- Supabase client → Postgres + RLS: data · Reads and writes application records.
- Supabase client → Storage bucket: media · Uploads and retrieves match proof files.
- Supabase client → Realtime: events · Consumes live status updates.
- Postgres + RLS → Supabase Auth: references roles · Database policies and user metadata depend on identity.
- Domain utils → Tournament flow: supports · Bracket logic feeds tournament pages and components.
- Domain utils → Player area: formats · Presentation helpers support player-facing views.
- Deploy workflow → main: builds · CI builds the Vite app from the frontend entrypoint.