How nhmcare11-glitch/adabibnak works
1. This is a Next.js App Router application for a medical/telemedicine platform. The architecture is split between route-driven UI under app/, server-side business actions under actions/, and shared infrastructure in lib/ plus prisma/.
2. The main user-facing surfaces are role-based dashboards and workflows:
- patient dashboard
- doctor dashboard and doctor verification/face-login
- secretary dashboard
- admin dashboard
- verification manager dashboard
- public doctor listing, specialty browsing, and appointment booking
- chat and video-call experiences
3. Route structure is the primary boundary. app/(auth) contains sign-in/sign-up flows, while app/(main) contains authenticated application areas. This suggests a protected shell pattern where authentication and authorization decide which layout and routes a user can access.
4. Authorization is central to the system. middleware.ts, lib/checkUser.ts, and the app/api/check-role route imply role-based gating across the app. The existence of dedicated dashboards for admin, doctor, secretary, patient, and verification-manager means access control is not just cosmetic; it drives the route and data model boundaries.
5. Business operations are implemented in actions/ as server-side actions grouped by domain: appointments, availability, chat, doctor, notifications, onboarding, payments, prescriptions, user management, verification, video calls, and role-specific flows. These actions are likely the main orchestration layer between UI and persistence.
6. Persistent data appears to be backed by Prisma and a relational database. prisma/schema.prisma, migrations, lib/prisma.ts, and lib/data.tsx indicate the app reads and writes structured domain entities such as users, doctors, appointments, prescriptions, payments, notifications, and verification records.
7. The appointment lifecycle is a key business flow. Users browse doctors by specialty, open a doctor profile, select a time slot, submit an appointment form, and then view appointments in role-specific dashboards. Supporting pieces include app/(main)/doctors/..., actions/appointments.js, actions/availability.js, and dashboard appointment lists.
8. Payments are a separate subsystem with both patient and doctor-facing views. actions/payment.js, actions/paypal.js, lib/payment-utils.ts, patient payment components, and doctor approval cards indicate the platform handles payment setup, payment status, approvals, and likely commission accounting. app/(main)/patient-dashboard/paypal-return shows a redirect/return flow from an external payment provider.
9. Communication features are split into chat, notifications, and video calls. Chat is route-based under app/(main)/chat/[id] with supporting actions in actions/chat.js. Notifications are exposed through app/api/notifications/* and UI components like NotificationsBell. Real-time feel is probably achieved through client components polling or server updates rather than a separate realtime service, based on the tree alone.
10. Doctor identity verification is a distinct subsystem. lib/face/*, the public face model assets, app/(main)/doctor/face-login, app/api/doctor/face-verification/*, and actions/verification-manager.js indicate browser-side face embedding/compare logic backed by server verification endpoints. This is a clear security boundary around doctor login/verification.
11. Several domain-specific dashboards aggregate data rather than own it. The admin dashboard manages verified and pending doctors, commissions, and availability. The secretary dashboard manages appointments, doctor/patient lists, and salary/payment views. The verification manager dashboard focuses on review/approval workflows. These screens are consumers of the same core domain data with different permissions.
12. The public experience also includes health content and utilities. app/guide/*, app/calculators/child-growth, components/HeroSection.tsx, and components/HealthGuideSection.tsx suggest the site is not only transactional but also informational. This content layer is separate from the authenticated operational workflows.
13. Internationalization is first-class. i18n/request.ts and messages/en.json, ar.json, fr.json show localized UI strings, so diagramming should include an i18n layer shared by routes and components rather than treating text as static.
14. Shared UI and application shell concerns live in components/ and components/ui/. This includes the header/footer/navigation, notification bell, theme provider/toggle, and reusable cards/forms. These are cross-cutting presentation primitives used by the route pages, not standalone business modules.
15. Overall data flow is: browser route/UI -> server action or API route -> Prisma/database and supporting services -> updated dashboard or route state. The notable external boundary is PayPal for payments, plus model files in public/models and face-processing code for verification running partly in the browser and partly through API endpoints.
Main entry points: actions Server actions · lib Shared libs · middleware.ts Access guard · components UI components
Components 25
Auth routes
Sign-in, sign-up, and access redirection flows
- Auth flows · Sign-in and sign-up entry points under the auth layout
app/(auth)
Main app
Authenticated route groups and role-based workspaces
- App shell · Top-level application layout and protected route composition
app/layout.tsx - Protected shell · Authenticated application area that branches into role-specific and public-in-app experiences
app/(main) - Doctor browse · Public doctor listing, specialty browsing, and booking entry flow
app/(main)/doctors - Booking flow · Doctor profile, availability, slot selection, and appointment submission
app/(main)/doctors/[specialty]/[id] - Patient dash · Patient profile, payment, and appointment management surface
app/(main)/patient-dashboard - Doctor dash · Doctor-facing overview with appointments and payment approvals
app/(main)/doctor-dashboard - Doctor verify · Face-login and verification pages for doctor identity
app/(main)/doctor/face-login - Secretary dash · Operational workspace for appointments, people lists, and payment/salary views
app/(main)/secretary-dashboard - Admin dash · Administrative controls for doctors, availability, and commissions
app/(main)/admin - Verification mgr · Review and approval workspace for verification operations
app/(main)/verification-manager - Chat · Threaded messaging experience inside the authenticated app
app/(main)/chat/[id] - Video call · In-app video calling experience and layout
app/(main)/video-call - Onboarding · Post-auth setup and profile completion flow
app/(main)/onboarding
Backend core
Server actions, API routes, and persistence layer
- Access guard · Global request-time auth and authorization gate
middleware.ts - Role check · Server endpoint for role validation and redirect decisions
app/api/check-role/route.js - Notifications API · Read and update notification state for the app shell and dashboards
app/api/notifications - Reminder cron · Scheduled reminder dispatch for appointment operations
app/api/cron/send-reminders/route.ts - Face API · Browser-to-server endpoints for doctor face verification
app/api/doctor/face-verification - Server actions · Domain actions for appointments, payments, chat, users, verification, and dashboards
actions - Prisma DB · Schema, migrations, and database access for domain entities
prisma/schema.prisma
Shared UI
Reusable UI, i18n, and client-side application primitives
- Shared libs · Prisma client, authorization helpers, payment utilities, face models, and shared data access
lib - UI components · Reusable layout, navigation, forms, cards, and dashboard primitives
components - i18n · Locale request handling and translated message bundles
i18n/request.ts
Public content
Health content, calculators, and marketing surfaces
- Guide content · Health guides, calculators, and homepage content surfaces
app/guide
Connections 23
- Access guard → Auth flows: gate · Blocks or redirects unauthenticated users into auth flows
- Access guard → Protected shell: protects · Protects authenticated areas and role-based navigation
- Role check → Access guard: supports · Used by request-time authorization checks
- Protected shell → Doctor browse: routes to · Exposes public-in-app doctor browsing
- Doctor browse → Booking flow: opens · Doctor specialty and profile pages lead into booking
- Booking flow → Server actions: submits · Appointment creation and slot handling are orchestrated server-side
- Patient dash → Server actions: uses · Loads and updates patient profile, payments, and appointments
- Doctor dash → Server actions: uses · Fetches appointments and payment approvals via server actions
- Secretary dash → Server actions: uses · Consumes operational lists, salary, and payment workflows
- Admin dash → Server actions: uses · Drives admin management of doctors, commissions, and availability
- Verification mgr → Server actions: uses · Processes verification review and approval operations
- Chat → Server actions: messages · Chat threads are coordinated through server-side chat actions
- Video call → Server actions: session flow · Call state and session actions are coordinated through backend actions
- Notifications API → UI components: feeds · Notification state is surfaced in shared UI such as the bell and shell
- Face API → Shared libs: uses · Face embedding, comparison, and model loading live in shared libs
- Doctor verify → Face API: verifies · Doctor login/verification pages invoke face verification endpoints
- Server actions → Prisma DB: persists · Core domain operations read and write relational records
- Shared libs → Prisma DB: connects · Shared data access uses the Prisma client and helpers
- Shared libs → i18n: localizes · Locale-aware utilities and shared UI draw from message bundles
- UI components → App shell: composes · Reusable UI pieces assemble the app shell and route layouts
- Guide content → UI components: renders with · Public informational pages are built from shared presentation primitives
- Onboarding → Server actions: starts · Onboarding writes user state through server actions
- Reminder cron → Server actions: triggers · Scheduled reminders reuse appointment and notification orchestration