rhaeon66/blood_plus

1. Repository shape

- BloodPlus is a two-tier monorepo: a Django REST API backend in backend/ and a Next.js frontend in frontend/.

- The main architectural boundary is client UI vs. server API, connected over HTTP/JSON.

2. Backend role

- backend/config holds the Django project configuration, URL routing, and WSGI entrypoint.

- The backend exposes the domain through DRF APIs and uses Simple JWT for auth and CORS to allow the browser frontend to call it.

3. Backend domain apps

- The backend is split into four Django apps, each representing a domain boundary:

- users for authentication and user profile management

- locations for location data

- donations for donation lifecycle

- blood_requests for blood request creation and tracking

- Each app has its own models.py, serializers.py, views.py, urls.py, and migrations, so the API is organized by domain rather than by a single monolith.

4. User/auth subsystem

- users is the identity and profile subsystem.

- It includes a custom user model/managers, JWT-related serializers/views, a stats.py module for user metrics, and management commands such as create_superuser and populate_data.

- This app is the primary source of authenticated identity used by donations and blood request records.

5. Donation subsystem

- donations models donation records and their status workflow.

- The migrations show status evolution and an approved_at timestamp, which implies a donation approval/review process.

- This app likely feeds the profile page’s donation history and donation statistics.

6. Blood request subsystem

- blood_requests handles requests for blood, including creation and detail retrieval.

- The app has separate serializers, views, and URL routes, indicating it is exposed as its own REST resource.

- The frontend’s request form and blood-request listing/detail pages map directly to this backend domain.

7. Location/data subsystem

- locations is a supporting domain for geographic data used by requests, donors, or profile filtering.

- The repo also includes a Bangladesh upazila JSON dataset in the frontend tree, which likely backs location selectors or seeded data.

- This suggests location data is treated as reference data rather than a standalone user-facing feature.

8. Persistence and data model

- The backend uses SQLite in development (backend/db.sqlite3 per README) and Django migrations are the schema source of truth.

- The ORM is the main persistence layer; there is no separate service or database boundary in the repo.

9. Frontend role

- The frontend uses Next.js App Router under frontend/app/ with route-based pages for:

- home, about

- auth sign-in/register

- blood requests list/detail

- request-blood form

- profile

- This is a server-renderable React app, but the architecture is effectively a browser client for the Django API.

10. Frontend component structure

- UI is decomposed into feature components under frontend/components/:

- homepage sections

- shared layout (Navbar, Footer)

- profile widgets and modals

- request-blood form and sign-in prompt

- This indicates the frontend is organized by page/feature composition rather than a shared design-system-only approach.

11. Client state and API access

- frontend/lib/api.js centralizes HTTP calls, and frontend/lib/authStore.js uses Zustand for client-side auth state.

- This is likely where JWT tokens/session state are stored and attached to API requests.

- The frontend depends on Axios for request transport and on the backend’s JWT endpoints for sign-in/register flows.

12. Operational flow

- Typical request flow is:

1. User interacts with a Next.js page

2. UI component calls the API layer

3. Django REST endpoint validates the request and JWT/auth context

4. Django ORM reads/writes SQLite through the domain app model

5. JSON response returns to the frontend for rendering

- CORS is the key deployment/runtime bridge that makes this browser-to-API flow work.

13. Repo tooling and environment

- Both sides include .env.example files, implying environment-specific configuration for API URLs, auth settings, and similar runtime values.

- Styling is handled with Tailwind CSS, and lint/build tooling is configured on the frontend.

- The backend includes standard Django management commands and migration-based schema management, which are important for diagramming the deployment/setup path.