tanjiyajuthi/bibliodrop

1. This is a Next.js App Router application organized around a public marketing/browsing site plus role-based dashboards. The main architectural boundary is between:

- public/auth pages,

- main customer-facing pages,

- authenticated dashboards for different roles,

- API routes for auth and user management.

2. The top-level app shell lives in src/app/layout.js, with global styling in src/app/globals.css and an app-level loading state in src/app/loading.js. Route grouping is used heavily to keep the UI segmented without changing URLs:

- src/app/(auth) for sign-in/sign-up flows,

- src/app/(main) for the public site,

- src/app/dashboard for authenticated role-specific areas.

3. Authentication is handled through a dedicated API surface at src/app/api/auth/[...all]/route.js, which is the central backend entry point for auth-related requests. Client/server auth helpers are split into src/lib/auth-client.js and src/lib/auth.js, indicating a clear separation between browser-side auth usage and server-side auth logic.

4. User role management is a separate concern from authentication itself. The route src/app/api/user/role/route.js suggests the application assigns or updates roles independently, which then drives access control and dashboard routing. This is reinforced by the presence of a /choose-role page in the main area.

5. The public-facing site is under src/app/(main) and includes pages for books, categories, contact, and role selection. The main landing page is src/app/(main)/page.js, while detail pages live under dynamic routes such as:

- books/[id]

- categories/[id]

This indicates the app supports list/detail browsing for content entities.

6. The public UI is composed from reusable presentation components in src/components/home and src/components. Notable shared components include:

- navigation and footer elements,

- book cards,

- featured content,

- top categories,

- rating and review UI.

These components likely feed both the public pages and authenticated views, keeping display logic reusable.

7. There is a clear dashboard subsystem with a shared shell at src/app/dashboard/DashboardShell.jsx, plus shared navigation components in src/components/dashbaord (top nav and side nav). This shell likely provides the common layout and auth-aware navigation for all dashboard roles.

8. The dashboard is split by role into three main branches:

- dashboard/admin for administrative management,

- dashboard/librarian for operational/catalog actions,

- dashboard/reader for end-user self-service features.

Each role has its own page hierarchy and separate navigation surface, which is a strong sign that access control and UX differ materially by role.

9. Within the admin dashboard, the app includes management areas for analytics, books, categories, roles, users, and transactions, plus an admin profile page. This suggests the admin role is responsible for overseeing both catalog data and system-level entities, and likely for reviewing operational/payment records.

10. The librarian dashboard focuses on book operations and fulfillment-oriented flows. It contains pages for:

- adding/editing books,

- delivery,

- wish list,

- profile.

This points to a workflow-centered role that manages inventory/content and handles items moving through a process.

11. The reader dashboard is centered on personal library activity. It includes:

- books,

- reading list,

- wish list,

- reviews,

- delivery,

- profile.

The presence of reviews, reading list, and delivery pages suggests the app is not just a catalog, but supports user-specific engagement and post-interaction workflows.

12. A dedicated src/app/payment-success/page.jsx page indicates the system has at least one transactional step with a post-payment redirect/confirmation state. Combined with the admin transactions page, this implies a flow that crosses from public/user interaction into backend transaction tracking.

13. Utility and integration code is concentrated in src/lib/helper, including generic helpers and an image upload helper (imbb.js). That separation suggests external media handling is abstracted out of the UI pages, likely to support book/category asset management across dashboards.

14. Overall, the architecture is a role-based Next.js monolith with:

- route-level segmentation for public, auth, and dashboard areas,

- reusable shared UI components,

- a small set of API routes for auth and role updates,

- centralized auth utilities,

- role-specific dashboards that appear to govern catalog, user, and transactional workflows.