abdulwaheed16/thedigitalcoaching-v1225

1. This is a Next.js App Router application for “The Digital Coaching,” split into three major surfaces: a public marketing site, an authenticated auth flow, and an admin/dashboard area.

2. The public site lives under app/(public) and covers landing/home, about, blogs, courses, curriculum, fee structure, registration, contact, and tutors. These routes are mostly composition of reusable section components from components/pages/* and shared layout pieces in components/layouts/*.

3. Blog content is a first-class domain. Public blog listing and blog detail pages have route-level loading/error/not-found handling, while the dashboard provides create/edit/preview management for blog posts. This suggests a content workflow with separate public consumption and internal authoring paths.

4. The dashboard under app/dashboard is the operational backend for admins. It includes modules for blogs, bookings, enrollments, messages, media, tutors, and settings, with per-entity detail routes and list views. Most of the interactive UI is organized in components/dashboard/*, especially table, filters, detail panes, status controls, and bulk/action components.

5. Authentication is separated from both public and dashboard app routes. The app/auth area contains sign-in, forgot-password, and reset-password pages, while app/(server)/api/auth/[...nextauth] and auth.ts indicate NextAuth-based session handling. middleware.ts and components/auth/protected-route.tsx enforce access boundaries for protected areas.

6. The backend domain logic is concentrated in lib/actions/*. These actions cover blogs, bookings, enrollments, messages, newsletters, notifications, tutor applications, uploads, users, and auth. In this repo, many UI screens likely call these actions directly rather than going through a separate REST layer.

7. Data persistence appears to be Prisma-backed. prisma/schema.prisma, seed scripts, and config/prisma.ts indicate a relational database as the main system of record for application data such as users, posts, bookings, enrollments, and messages.

8. File and media handling is a separate subsystem. app/(server)/api/uploads/*, lib/supabase/*, lib/supabase-upload.ts, and the dashboard media library components show that uploaded images/files are stored and managed outside the core database, with Supabase used as the storage integration.

9. The app uses a mixed server/client architecture. Server-rendered route segments and route handlers handle data fetching, while client components power forms, tables, dialogs, upload progress, search, and dashboard interaction. React Query support in components/providers/query-provider.tsx and lib/react-query.ts suggests some data is also fetched and cached client-side.

10. Shared business rules are centralized in lib/validations/*, lib/rbac/*, and helper modules under lib/helpers/*. This creates a clear boundary between UI and domain rules such as input validation, permissions, date formatting, and status/color mapping.

11. Cross-cutting UI concerns are handled through providers and global shells: components/providers/* for theme/query/dashboard state, app/layout.tsx and route-specific layouts for app shells, and global styling via app/globals.css, styles/globals.css, and Tailwind config. The dashboard likely has its own header/sidebar layout distinct from the public header/footer.

12. There are also a few external integrations that affect architecture: email templates and transporter code under lib/emails/*, WhatsApp helpers/widgets in lib/whatsapp.ts and components/whatsapp-*, and pixel/analytics support in components/providers/facebook-pixel-provider.tsx and lib/fpixel.ts. These are side-effect systems around lead capture, notifications, and engagement.

13. Static/domain reference data is stored in data/* and public/images/*, including curriculum, programs, testimonials, and lead/message examples. This supports marketing and curriculum pages without requiring a full backend round-trip for every section.

14. Overall, the architecture is a monorepo-style Next.js web app with a strong separation between public content, authenticated admin operations, and server-side domain/data services. The most important diagram boundaries are: public vs dashboard routes, client UI vs server actions/route handlers, database vs file storage, and authentication/authorization as the gatekeeper for dashboard access.