santoshkumar555/private

1. This is a three-part travel/booking system: a public customer-facing frontend, a separate admin dashboard, and a shared Node.js backend API. The backend is the source of truth for domain data such as users, hotels, locations, packages, bookings, and payments.

2. The public frontend lives in frontend/ and uses Next.js App Router. Its route groups split the site into (public) pages and (auth) pages, with route-level layouts for authenticated vs unauthenticated experiences. The app mixes server-rendered pages with client components for interactive flows like search, checkout, wishlist, and booking management.

3. The admin dashboard lives in admin/ and is a separate React + Vite application. It has its own routing, layouts, and UI components for operational work: dashboard stats, CRUD screens for hotels/locations/packages/users, booking review, and profile/settings management. It talks directly to the backend through dedicated service modules.

4. The backend in backend/ is an Express API organized by domain and audience. Routes are split into auth, user, admin, payment, and health, and controllers are grouped under matching folders. This makes the API boundary explicit: public/user operations are separated from privileged admin operations.

5. Core data entities are modeled in backend/models/ as user, booking, hotel, location, and package. The API shape mirrors these entities: each domain has create/read/update/delete controllers for admin use, and read-only or self-service controllers for end users.

6. The main request pipeline on the backend is layered: routes → middleware → validation → controller → services/models. Middleware handles authentication, admin authorization, body parsing, logging, rate limiting, uploads, and error handling. Validation is split by domain so bad requests are rejected before business logic runs.

7. Several external integrations materially shape the architecture:

- Cloudinary for media/file uploads.

- Razorpay for payment order creation, payment verification, and webhook handling.

- Email/OTP services for registration, verification, password reset, and related auth flows.

These integrations are isolated in backend/services/ and called from controllers.

8. Authentication and user identity are multi-channel. The backend exposes login/register/admin-login, refresh token, logout, OTP verification, password reset, and email verification endpoints. The frontend stores auth state in context/storage utilities and uses protected routes and cookie/token helpers; the admin app has its own login flow and access checks.

9. Booking is a cross-cutting workflow spanning all three layers. Users browse packages/hotels/locations in the public frontend, create bookings through the backend, and may pay through the payment service. Users can later view/cancel bookings, while admins can inspect and update booking status from the dashboard.

10. Public browsing features are driven by search and content endpoints. The frontend has dedicated API wrappers for packages, hotels, locations, and payments, plus UI components for destination pages, listing filters, featured packages, and hotel/package detail pages. This suggests most browsing pages are data-driven and parameterized by slugs/ids.

11. State management differs by app. The public frontend uses Redux slices for UI/toasts/wishlist/booking state plus an auth context; the admin app is more page-local and service-driven. Both apps centralize API calls in service modules rather than calling fetch/axios directly from views.

12. The repository also includes operational support artifacts: seeders for bootstrapping admins, users, hotels, locations, packages, and bookings; Postman docs for the API; and environment/config modules for DB, CORS, and cloud services. These pieces indicate the backend is designed to be deployable and testable independently of the frontends.

13. For an architecture diagram, the key boundaries are: public customer UI, admin UI, backend API, database/models, and external services. The dominant data flows are browse/search → read APIs, auth/session flows, booking/payment flows, and admin CRUD flows, all converging on the backend as the shared business layer.