zihad-1883/l1-a9-sportnest-sports-facility-booking-management-system-client

1. SportNest is a Next.js App Router client application. The repo is organized around routed screens in src/app, with most business UI living in reusable components under src/app/components. It is primarily a frontend for a separate backend API, with only auth-specific route handling inside this repo.

2. The application shell is defined globally in src/app/layout.js and styled through src/app/globals.css, TailwindCSS, and DaisyUI. The shared shell likely wraps all pages with common navigation and footer components, while loading.jsx files provide route-level pending states and not-found.jsx handles unknown routes.

3. The public-facing marketing layer is concentrated on the home and informational pages: src/app/page.js, about-us, plus sections like Banner, HowItWorks, WhyChooseUs, Testimonials, FeaturedFacilities, and Footer. This makes the homepage a conversion entry point rather than just a dashboard.

4. Facility discovery is centered on all-facilities and all-facilities/[id]. The list page uses search/filter UI, card summaries, and sport-type filtering, while the detail page uses FacilitiesDetails to show a single facility and likely acts as the handoff into booking.

5. Booking is a dedicated flow implemented by BookingForm, with cancellation handled by BookingCancelAlert and booking history surfaced in MyBooking. The data path is: user action in the UI -> form/alert component -> backend API call -> updated booking state shown on the bookings page.

6. Facility management is a separate owner/admin-style subsystem. add-facility, manage-facilities, EditFacilityForm, and FacilityDeleteAlert support creating, editing, and deleting facilities, so the architecture distinguishes between browsing/bookings and facility CRUD operations.

7. Authentication is handled through Better Auth. The local auth boundary is exposed at src/app/api/auth/[...all]/route.js, while src/lib/auth.js and src/lib/auth-client.js separate server/client auth setup. The README also indicates email/password and Google login, with protected routes guarded by JWT-based access control.

8. The app’s main business data does not live in this repository. Client pages call an external backend via NEXT_PUBLIC_API_URL, which is where facility, booking, and user data are fetched and mutated. MongoDB is mentioned in the README, but it is part of the backend persistence layer, not the frontend runtime.

9. src/proxy.js is the request-time protection boundary for private routes. It likely redirects unauthenticated users away from booking/management pages and keeps the public pages accessible without login.

10. The component architecture is intentionally modular: forms, cards, alerts, navigation, and content sections are isolated as separate React components. That keeps page files thin and makes it easier to diagram the system as a set of route-level screens composed from shared UI primitives, with auth and data access as the main cross-cutting concerns.

11. Operationally, the project is built for browser deployment on Vercel, with environment variables for auth and backend integration. Key external dependencies that materially affect architecture are Next.js App Router, Better Auth, axios-style HTTP calls, and UI libraries for styling and interaction.