How mubin-0xc7dfc8c3c4/mancity-dashboard works
1. Overall shape
- This is a single Next.js App Router application that combines the frontend, API layer, and database access in one codebase.
- The main architecture is a CRUD-style football operations dashboard backed by Prisma and MySQL.
2. User-facing entrypoints
- app/page.tsx is the primary dashboard page.
- app/layout.tsx provides the shared shell for the app, and app/globals.css applies global styling.
- The page-level UI is assembled from domain components under components/mcfc.
3. Domain UI subsystems
- components/mcfc/dashboard.tsx, players.tsx, matches.tsx, staff.tsx, training.tsx, and trophies.tsx are the main business modules.
- These represent the top-level functional areas of the product: team overview, player management, match management, staff management, training sessions, and trophy records.
- They likely consume data from the API routes and render the operational dashboard views.
4. API layer
- The app/api/* tree is the backend surface of the application.
- There are resource-specific route handlers for players, matches, staff, training, and trophies, each with:
- a collection route: route.ts
- an item route: [id]/route.ts
- This structure implies standard REST-style operations for listing, creating, reading, updating, and deleting records.
5. Analytics/summary endpoint
- app/api/stats/route.ts is a separate read endpoint for dashboard metrics.
- It likely aggregates counts or operational summaries across multiple entities rather than exposing a standalone CRUD resource.
6. Data access boundary
- lib/db.ts is the central database access point, most likely the Prisma client singleton.
- This is the key boundary between route handlers and the database; all persistence flows through this layer rather than direct SQL in components.
7. Persistence model
- prisma/schema.prisma defines the data model and database mappings.
- The README specifies MySQL as the backing store, so Prisma is the ORM abstraction over MySQL tables.
- prisma/seed.ts provides initial data bootstrapping for development or local setup.
8. Request/data flow
- Typical flow is: dashboard component -> fetch/API call -> Next.js route handler -> Prisma via lib/db.ts -> MySQL -> JSON response -> UI render.
- The API routes are the main integration boundary; the UI is separated from direct database access.
9. Shared UI system
- components/ui/* is a reusable design-system layer built from Shadcn UI primitives.
- These components provide the app’s common visual building blocks: tables, dialogs, forms, tabs, cards, toasts, dropdowns, etc.
- The business screens in components/mcfc are composed from these lower-level UI primitives.
10. Client-side helpers
- hooks/use-toast.ts and components/ui/toaster.tsx support user notifications.
- hooks/use-mobile.ts suggests responsive behavior detection for mobile-adaptive UI.
11. Styling and frontend tooling
- Tailwind CSS is the primary styling system, configured via tailwind.config.ts and postcss.config.mjs.
- components.json indicates a Shadcn/UI setup, which explains the large set of generated primitive components.
12. Environment and infrastructure
- The app expects a DATABASE_URL pointing to MySQL, as documented in the README.
- There is no separate backend service or external API dependency shown in the tree; the Next.js app itself serves both frontend and backend concerns.
13. Examples and non-core code
- examples/websocket/frontend.tsx and examples/websocket/server.ts appear to be a standalone demonstration rather than part of the main football dashboard path.
- They are useful as an auxiliary sample but should be treated as separate from the production data flow.
14. What to show in an architecture diagram
- A good diagram would center on:
- browser/UI
- Next.js pages/components
- Next.js API routes
- Prisma database layer
- MySQL database
- Around that, show the five main domain modules: players, matches, staff, training, and trophies, plus a cross-cutting stats/overview endpoint.
Main entry points: dashboard.tsx Overview · ui UI kit · db.ts Prisma client · page.tsx Dashboard
Components 22
Next.js app
App Router entrypoints and shared shell
- Dashboard · Primary dashboard entry page
app/page.tsx - App shell · Shared application layout
app/layout.tsx - Global CSS · Global styling entry
app/globals.css
Domain UI
Football operations screens assembled into the dashboard
- Overview · Top-level team dashboard view
components/mcfc/dashboard.tsx - Players · Player management screen
components/mcfc/players.tsx - Matches · Match management screen
components/mcfc/matches.tsx - Staff · Staff management screen
components/mcfc/staff.tsx - Training · Training session screen
components/mcfc/training.tsx - Trophies · Trophy records screen
components/mcfc/trophies.tsx
API layer
REST-style route handlers and dashboard metrics
- Players API · REST resource for players
app/api/players/route.ts - Matches API · REST resource for matches
app/api/matches/route.ts - Staff API · REST resource for staff
app/api/staff/route.ts - Training API · REST resource for training
app/api/training/route.ts - Trophies API · REST resource for trophies
app/api/trophies/route.ts - Stats API · Aggregated dashboard metrics
app/api/stats/route.ts
Shared UI
Reusable design-system primitives and client helpers
- UI kit · Reusable interface components
components/ui - Toasts · Notification hook and toaster
hooks/use-toast.ts - Mobile hook · Responsive behavior helper
hooks/use-mobile.ts
Data layer
Prisma schema, seed data, and DB client
- Prisma client · Central database access boundary
lib/db.ts - Schema · Data model and mappings
prisma/schema.prisma - Seed data · Initial development data
prisma/seed.ts
Examples
Standalone demo code not on the main product path
- Websocket demo · Standalone websocket example code
examples/websocket/frontend.tsx
Connections 31
- Dashboard → App shell: uses shell · Dashboard is rendered inside the shared app layout
- Dashboard → Global CSS: styled by · Page and layout inherit global styles
- Dashboard → Overview: assembles · Main page composes the overview screen
- Overview → Players: links · Overview surfaces player management
- Overview → Matches: links · Overview surfaces match management
- Overview → Staff: links · Overview surfaces staff management
- Overview → Training: links · Overview surfaces training operations
- Overview → Trophies: links · Overview surfaces trophy records
- Players → Players API: fetches · Player UI reads and mutates player data through the API
- Matches → Matches API: fetches · Match UI reads and mutates match data through the API
- Staff → Staff API: fetches · Staff UI reads and mutates staff data through the API
- Training → Training API: fetches · Training UI reads and mutates training data through the API
- Trophies → Trophies API: fetches · Trophy UI reads and mutates trophy data through the API
- Overview → Stats API: reads metrics · Dashboard summary pulls aggregated stats
- Players API → Prisma client: queries · Route handler persists via Prisma
- Matches API → Prisma client: queries · Route handler persists via Prisma
- Staff API → Prisma client: queries · Route handler persists via Prisma
- Training API → Prisma client: queries · Route handler persists via Prisma
- Trophies API → Prisma client: queries · Route handler persists via Prisma
- Stats API → Prisma client: aggregates · Stats endpoint computes summaries from stored records
- Prisma client → Schema: maps to · Client is generated from the Prisma schema
- Seed data → Schema: seeds · Seed data matches the model shape
- UI kit → Toasts: supports · Toaster wiring sits on top of UI primitives
- UI kit → Mobile hook: supports · Responsive helpers inform shared UI behavior
- Overview → UI kit: composes · Domain screens are built from the shared UI kit
- Players → UI kit: composes · Domain screens are built from the shared UI kit
- Matches → UI kit: composes · Domain screens are built from the shared UI kit
- Staff → UI kit: composes · Domain screens are built from the shared UI kit
- Training → UI kit: composes · Domain screens are built from the shared UI kit
- Trophies → UI kit: composes · Domain screens are built from the shared UI kit
- Websocket demo → UI kit: independent · Standalone example code is separate from the main dashboard flow