meetmendapara09/eld-trip-planner

Purpose and Entry Points

RouteLog Pro is a full-stack commercial-driver trip planner that produces FMCSA Hours-of-Service schedules and ELD-style daily logs. The React client starts at frontend/src/main.jsx and frontend/src/App.jsx; its API boundary is frontend/src/services/api.js. Django starts through backend/manage.py, with HTTP routing rooted in backend/eld_backend/urls.py and deployment-oriented API entry modules at api/index.py and backend/api/index.py.

Client Application

The Vite/React frontend collects trip inputs, invokes the backend, and renders planning artifacts rather than computing compliance logic itself. frontend/src/components/TripForm.jsx captures locations and cycle usage; frontend/src/components/ResultsView.jsx composes returned results. Map, schedule, fuel, summary, and daily-log views consume the resulting trip payload through frontend/src/components/MapView.jsx, frontend/src/components/ScheduleTable.jsx, and frontend/src/components/DailyLogSheet.jsx.

Authentication-aware dashboard and saved/shared-trip views are also client-side application surfaces: frontend/src/pages/DashboardPage.jsx, frontend/src/components/SavedTripView.jsx, and frontend/src/components/SharedTripView.jsx.

API and Domain Boundary

Django REST endpoints are organized into two domains: accounts and trips. URL-to-view dispatch lives in backend/accounts/urls.py and backend/trips/urls.py, with request orchestration in backend/accounts/views.py and backend/trips/views.py. Serializers form the API validation/representation boundary in backend/trips/serializers.py and backend/accounts/serializers.py.

The primary planning endpoint is POST /api/trip/: it accepts current/pickup/dropoff locations plus consumed cycle hours and returns route geometry, scheduled duty segments, logs, coordinates, and aggregate trip metrics.

Trip Planning Pipeline

Trip processing is service-layer orchestration behind backend/trips/views.py:

1. Resolve textual locations to coordinates via backend/trips/services/geocoding.py.

2. Request a drivable route, distance, duration, and geometry through backend/trips/services/routing.py.

3. Convert route duration/distance and cycle state into legally constrained activities with backend/trips/services/hos_scheduler.py.

4. Produce daily ELD duty-status log data in backend/trips/services/log_generator.py.

5. Optionally generate document output via backend/trips/services/pdf_generator.py.

This separates external geographic data from deterministic HOS and reporting calculations.

Persistence, Identity, and Sharing

Trip persistence is modeled in backend/trips/models.py; schema evolution includes trip sharing support in backend/trips/migrations/0002_trip_share_token.py. Accounts use Django models and migrations in backend/accounts/models.py and backend/accounts/migrations/0001_initial.py. These domains enable authenticated driver profiles, saved trips, and token-addressable shared trips while keeping generated planning results exposed through serializers/views.

Compliance and External Services

The HOS scheduler is the compliance-critical component: backend/trips/services/hos_scheduler.py applies 11-hour driving, 14-hour duty-window, 30-minute break, 10-hour rest reset, and 70-hour/8-day cycle constraints; it also accounts for pickup/delivery and periodic fuel-stop activities. Log generation in backend/trips/services/log_generator.py turns this schedule into 24-hour ELD records.

Geocoding uses OpenStreetMap Nominatim. Routing prefers OpenRouteService when ORS_API_KEY is configured and falls back to OSRM. The browser map uses React Leaflet/OpenStreetMap. Backend runtime is Python/Django/DRF; frontend runtime is React/Vite. Deployment configuration exists in backend/render.yaml, backend/vercel.json, and root vercel.json.