shashwattt26/reyansh-diagnostics

1. Top-level shape

- This repo is a two-tier application: a Node/Express backend in backend/ and a React/Vite frontend SPA in frontend/frontend/.

- The backend is the system of record and API gateway; the frontend is a browser client for patients and staff.

2. Primary business boundary

- The core domain is a diagnostic center workflow: public booking intake, staff authentication, live booking management, lab report delivery, and admin-only staff/privacy actions.

- The architecture is organized around those workflows rather than generic CRUD resources.

3. Frontend subsystem

- The frontend is a single-page React app with route-level pages such as LandingPage, AdminDashboard, AdminLogin, StaffManagement, VerifyEmail, and ResetPassword.

- Reusable landing-page sections live under src/components/landing/, while app-wide layout and utilities live under src/components/layout/ and src/components/.

- Routing is handled client-side, with SPA deployment support via vercel.json.

4. Public vs. authenticated UI

- Public users mainly interact with the landing/marketing flow and the booking entry points.

- Authenticated staff users enter through the admin/staff portal, which consumes live booking data and exposes report-processing and account-management screens.

- This separation is important for diagramming because the same backend serves both public and restricted flows, but the UI paths are distinct.

5. Backend API boundary

- The backend is an Express server in backend/server.js with route modules split by concern: authRoutes, bookingRoutes, adminRoutes, reportRoutes, searchRoutes, and staffRoutes.

- config/db.js connects to PostgreSQL via a pool, and config/cloudinary.js centralizes blob-storage integration.

- utils/logger.js and utils/sendEmail.js support cross-cutting concerns rather than domain logic.

6. Authentication and session model

- Authentication is JWT-based with HTTP-only cookies, not frontend token storage.

- authRoutes covers staff registration, login, and email verification; password reset is handled as a separate flow.

- middleware/authMiddleware.js and middleware/roleCheck.js form the main trust boundary for protected endpoints.

7. Booking intake and prescription upload flow

- Public booking requests hit the booking API, usually as multipart form submissions.

- middleware/upload.js handles temporary file reception; the uploaded prescription is then forwarded to Cloudinary, and the local file is cleaned up after upload.

- The booking record, including the Cloudinary URL and a generated tracking code, is stored in PostgreSQL.

8. Report processing flow

- Final lab reports are uploaded through the report routes and follow the same storage pattern: temporary local file → Cloudinary → database update.

- Report upload changes booking state to indicate that the report is ready, which is then reflected in staff/admin screens.

- This is a separate domain path from patient booking because it is restricted to internal staff roles.

9. Real-time update path

- The backend is also a Socket.IO server, used to push booking changes to connected clients without polling.

- The key event is new booking creation: once the booking is persisted, the server emits an event and the admin dashboard prepends the new record in memory.

- For architecture diagrams, this is the main asynchronous data flow between backend and staff UI.

10. Security and access control

- Security is layered through middleware: rateLimiter.js for abuse prevention, validator.js for request validation, roleCheck.js for authorization, and authMiddleware.js for session protection.

- backend also uses helmet, bcrypt, and cookie-based auth; the readme indicates role-based access for admin-only operations such as staff management and data anonymization.

- The booking tracking code is a privacy boundary: it supports lookup without exposing internal identifiers directly.

11. External services and persistence

- PostgreSQL stores users, bookings, roles, and report metadata.

- Cloudinary stores prescription and PDF report files; the local filesystem is only a temporary staging area.

- Resend sends verification and password-reset emails.

- These are the three key external integrations that materially shape the architecture.

12. Testing and delivery

- The backend includes route-level tests under backend/__tests__, and the frontend includes component tests such as BookingCard.test.jsx.

- CI is defined in .github/workflows/ci.yml, and Dependabot is configured for dependency maintenance.

- Deployment is split by tier: frontend to Vercel-like static hosting, backend to a Node service with PostgreSQL and external service credentials.

13. Important diagram boundaries

- Draw the browser/SPA boundary separately from the Express API/socket server boundary.

- Inside the backend, show separate lanes for auth, booking intake, admin/staff operations, and report uploads.

- Show the shared infrastructure layer beneath them: PostgreSQL, Cloudinary, and Resend, with Socket.IO as the real-time channel between backend and admin UI.