aswinram312004-droid/doctor-appointment-booking-system

Purpose and topology

MediCare is a local full-stack doctor appointment system. A React single-page frontend lets patients browse doctors, authenticate, and book/manage appointments; a Flask API persists users, doctors, schedules, and appointments in PostgreSQL. Administrators manage doctor records and schedules.

Application entry points

• Flask starts from backend/app.py, which composes the API application and route modules.

• React boots from frontend/src/main.jsx and renders the top-level application in frontend/src/App.jsx.

• Backend environment and dependencies are defined in backend/.env and backend/requirements.txt; the frontend is a Vite/npm project via frontend/package.json and frontend/vite.config.js.

API and authentication boundary

The backend exposes the /api HTTP boundary for the frontend. Authentication routes in backend/auth.py register users and issue JWTs; protected appointment and administrative actions depend on those tokens. Flask configuration, request handling, and route registration are centralized in backend/app.py.

Persistence and domain model

PostgreSQL is the system of record, accessed through backend/db.py. The relational schema—including the database-enforced appointment-conflict constraint described by the README—is established in backend/schema.py. Operational bootstrap/validation scripts, backend/setup.py, backend/create_admin.py, and backend/check_db.py, support initial schema and admin/database setup rather than the request path.

Doctor catalog and administration

backend/doctor.py owns doctor-facing API behavior, including doctor listing/detail retrieval and likely admin management operations. The UI presents the catalog and detail views through frontend/src/components/pages/DoctorsPage.jsx, frontend/src/components/sections/Doctors.jsx, and frontend/src/components/sections/DoctorDetails.jsx; admin doctor controls are represented by frontend/src/components/sections/AdminDoctors.jsx.

Appointment lifecycle

backend/appointments.py handles the protected appointment workflow: retrieve a user’s appointments, create bookings, and cancel bookings. Its persistence boundary is the PostgreSQL layer in backend/db.py/backend/schema.py, where schedule conflicts must be rejected. The patient-facing booking surface is frontend/src/components/sections/AppointmentPage.jsx, with doctor selection/details feeding into it from frontend/src/components/sections/DoctorDetails.jsx.

Frontend composition and state boundaries

frontend/src/App.jsx coordinates page-level navigation and shared application composition. Authentication UI is isolated in frontend/src/components/sections/LoginPage.jsx and frontend/src/components/sections/SignupPage.jsx; reusable site framing is in frontend/src/components/layout/Navbar.jsx and frontend/src/components/layout/Footer.jsx. Static or display-oriented doctor data also exists at frontend/src/data/doctors.js, which should be distinguished from the API-backed doctor catalog when evolving data flow.

Runtime and external dependencies

The material runtimes are browser-based React/Vite, Python Flask, and PostgreSQL. The only identified external service boundary is the local PostgreSQL instance configured by DATABASE_URL; security relies on SECRET_KEY and JWT_SECRET_KEY supplied through backend/.env.