shahadat-hossain99/bloodsync-client

1. This is a Next.js App Router application, so the architecture is split around route segments in src/app, with page files defining routes and colocated client components handling interactivity. The top-level app shell is in src/app/layout.js, with global styles in src/app/globals.css.

2. The product domain is a blood-donation platform. The main user-facing surfaces are:

- a public marketing/home area,

- public donation request browsing and detail pages,

- authentication pages,

- a role-based dashboard for donors, volunteers, and admins,

- supporting informational pages under resources.

3. The public/home subsystem is composed of reusable sections in src/components/home such as the hero/banner, “how it works”, “why choose us”, contact, and marquee/ticker widgets. These are assembled into the homepage and likely drive the main acquisition flow from awareness into registration or donation-request browsing.

4. The donation-request subsystem is one of the core data flows. It appears in both public and authenticated areas:

- src/app/donation-requests for public listing/detail viewing,

- src/app/dashboard/create-donation-request for creating requests,

- src/app/dashboard/my-donation-requests for user-owned requests,

- src/app/dashboard/edit-donation-request/[id] for editing,

- src/app/dashboard/all-blood-donation-request for broader administrative/ops visibility.

This suggests a shared underlying request model exposed through both public and dashboard experiences.

5. Authentication is a distinct boundary. The app has sign-in/register pages plus a catch-all auth API route at src/app/api/auth/[...all]/route.js. Supporting auth code lives in src/lib/auth.js, src/lib/auth-client.js, src/lib/core/session.js, and src/lib/core/server.js, with src/context/AuthContext.jsx likely propagating the current session/user through the client tree. The presence of unauthorized, forbidden, and role-specific dashboard layouts indicates authorization is enforced both in routing and UI composition.

6. The dashboard is role segmented. There is a shared dashboard shell in src/app/dashboard/layout.jsx plus role-specific sublayouts for admin, donor, and volunteer. Shared dashboard chrome is implemented in src/components/dashboard/DashboardHeader.jsx and DashboardSidebar.jsx, while individual dashboard pages handle role-specific views like profile, requests, and user management.

7. Data access is split between server-side action modules and client-friendly API wrappers. The src/lib/action/* files suggest server actions or server-only business logic for donations, requests, search, and users. In parallel, src/lib/api/* contains API-facing helpers for donation requests and users. This separation implies a backend boundary where pages and client components call into a thin data layer rather than embedding fetching logic directly.

8. Search is a dedicated subsystem (src/app/search plus src/lib/action/search.action.js). That implies cross-entity lookup over at least donation requests and/or users, and it likely feeds the discovery flow for public users and dashboard operators.

9. Geographic metadata is bundled locally in public/geoInfo with districts, divisions, and upazilas JSON files. The hook src/hooks/useGeoData.js probably loads and normalizes this data for forms such as registration, profile, or donation-request creation, making geography selection a client-side data dependency rather than a remote service call.

10. Shared UI and infrastructure components are centralized:

- src/components/shared/Navbar and Footer for the public shell,

- src/components/Breadcrumb.jsx and src/components/seo/ClientMetadata.jsx for navigation/metadata,

- src/lib/imageUpload.js for upload handling,

- src/lib/marquee.js for ticker content.

This keeps presentation concerns separate from route-specific business logic.

11. The app also includes informational/legal pages under src/app/resources plus privacy-policy, terms, and faq, which are isolated content routes rather than part of the transactional dashboard flow.

12. Overall, the main architecture boundary is: public marketing and browsing on one side, authenticated role-based operations on the other, with shared domain services in src/lib and shared UI in src/components. The data model revolves around users, authentication/session state, donation requests, search, and location metadata.