krishthakur248/quickpull

Purpose and Entry Points

This repository implements a carpooling application with browser-based rider/driver screens and a separate Node.js backend. Primary UI entry points are index.html, Dashboard-Connected.html, and AddRide-Connected.html. The backend starts from car-pulling-backend/src/server.js.

Frontend Application Layer

The frontend is a static HTML/JavaScript client rather than a bundled web application. It manages authentication, API access, trip operations, matching, messaging, and notifications through shared service scripts:

• api-client.js

• auth-service.js

• trip-service.js

• matchingService.js

• message-service.js

• notification-manager.js

Connected pages likely invoke these services to render dashboards, create rides, find rides, and communicate with matched users.

Backend HTTP/API Boundary

The backend follows a conventional Express-style separation of server, routes, controllers, middleware, and models. car-pulling-backend/src/server.js accepts HTTP requests and delegates them through route modules:

• car-pulling-backend/src/routes/auth.routes.js

• car-pulling-backend/src/routes/trip.routes.js

• car-pulling-backend/src/routes/message.routes.js

• car-pulling-backend/src/routes/user.routes.js

Controllers implement the API operations and form the boundary between request handling, persistence, and matching logic.

Identity and Authorization

Authentication is handled by controller, route, and middleware layers:

• car-pulling-backend/src/controllers/auth.controller.js

• car-pulling-backend/src/routes/auth.routes.js

• car-pulling-backend/src/middleware/auth.js

The browser-side counterpart is auth-service.js. Protected trip, user, and messaging operations should pass through the authentication middleware before reaching controllers.

Core Domain and Persistence

The durable application entities are users, trips, and messages:

• car-pulling-backend/src/models/User.js

• car-pulling-backend/src/models/Trip.js

• car-pulling-backend/src/models/Message.js

Database initialization/configuration is isolated in car-pulling-backend/src/config/database.js. Trip lifecycle operations—including publishing, finding, accepting, completing, and location-related updates—are centered in car-pulling-backend/src/controllers/trip.controller.js.

Route Matching Pipeline

Trip discovery and compatibility evaluation are a distinct backend capability, not only a frontend filter. Matching utilities are:

• car-pulling-backend/src/utils/matchingEngine.js

• car-pulling-backend/src/utils/advancedRouteMatching.js

• car-pulling-backend/src/controllers/trip.controller.js

The expected flow is: client submits or queries trips; the trip controller loads relevant trip data; matching utilities evaluate route compatibility; matching results return through trip APIs to frontend services such as matchingService.js. The repository’s OSRM-focused documentation and test files indicate routing/mapping integration is an important external-service boundary.

Messaging and Realtime/Location Concerns

Messaging is exposed as its own API/domain path:

• car-pulling-backend/src/controllers/message.controller.js

• car-pulling-backend/src/routes/message.routes.js

• message-service.js

Location tracking and active-trip behavior appear architecturally significant from the dedicated integration/debugging materials and trip-focused client code. Relevant validation harnesses include Testing/verify-location-tracking.js and Testing/debug-trip-completion.js; production logic remains primarily under the trip controller and trip model.

Runtime and Integration Shape

The system consists of a static browser frontend plus a Node.js backend with package-managed dependencies in car-pulling-backend/package.json. It relies on a configured database via car-pulling-backend/src/config/database.js and has route-matching integration points associated with OSRM, evidenced by Testing/test-osrm.js and car-pulling-backend/src/utils/advancedRouteMatching.js.