Uber

Django RideShare Service is a full-stack web application that lets users request rides, share open trips with other passengers, and lets registered drivers search and claim rides that match their vehicle and capacity. The app manages the complete ride lifecycle — from open request through driver confirmation to completion — with role-based access at every step.

The application is built around two user roles: passengers (who own or join rides) and drivers (who maintain a profile with vehicle details and claim open rides). Passengers create ride requests specifying destination, arrival time, passenger count, vehicle preference, and whether the ride can be shared. Drivers register a profile with license plate, vehicle type, max capacity, and any special info, which the system uses to determine eligibility for each open ride. When a driver confirms a ride, the status locks to CONFIRMED and confirmation emails are sent to the owner and all sharers. The assigned driver then marks the ride COMPLETE after the trip.

Rides go through three states: OPEN, CONFIRMED, and COMPLETE. An owner creates a ride while it is OPEN and can continue editing it. If the ride is marked sharable, other users can search for it by destination, arrival window, and passenger count, and join it via a RideShare record that validates their arrival window against the ride's scheduled time. Drivers see a filtered search of open rides where is_eligible_for_ride() checks that their vehicle type matches any preference, their max_passengers covers the combined headcount of the owner and all sharers, and any special requests are satisfied. Once a driver confirms, the ride can no longer be edited or joined. All active rides — whether owned, shared, or being driven — surface on the user's ride list dashboard.

• Role-aware views using LoginRequiredMixin and UserPassesTestMixin enforce ownership, driver-only actions, and open-ride edit restrictions
• Sharer arrival-window validation ensures join requests are consistent with the ride's scheduled arrival time
• Driver eligibility check combines vehicle type, passenger capacity, and special-request matching in a single model method
• Email notifications (console backend in development) alert the owner and all sharers on confirmation
• Full Django admin interface for User, Driver, Ride, and RideShare
• Deployable via Docker Compose with Postgres, a migration init container, Django dev server, and Nginx reverse proxy

Models and business logic: User extends AbstractUser with a unique email. Driver is a one-to-one extension of User holding vehicle info and the is_eligible_for_ride(ride) method. Ride carries the lifecycle state machine with methods confirm_with_driver, mark_complete, and can_be_shared. RideShare enforces a unique_together constraint on ride + sharer and validates the arrival window in clean().

Views and forms: All views are class-based. Passengers use CreateView and UpdateView for rides, FormView for the sharer search, and a detail view to join. Driver-facing views are gated with a test_func that checks for an existing driver_profile. The driver confirmation view calls confirm_with_driver, updates status, and sends email in a single transaction.

Infrastructure: Docker Compose runs four services — db (Postgres with a named volume), web-init (runs makemigrations + migrate with a retry loop), web (Django on 0.0.0.0:8000 as nobody), and nginx (proxies host port 8000 to the web service). Tailwind CSS is loaded via CDN in the base template.

No live demo available. See the repo for Docker Compose setup and run instructions.

Django · PostgreSQL · Docker · Nginx · Tailwind CSS

• Full ride lifecycle from passenger request to driver completion
• Sharable rides with per-sharer arrival window and capacity validation
• Driver eligibility filtering by vehicle type, capacity, and special requests
• Dockerized deployment with Postgres, init migrations, and Nginx reverse proxy