// the find
adrianhajdin/uber
Build a full-stack Uber Clone Application with Expo’s latest features and lightning-fast edge-ready Postgres database in React Native.
A React Native and Expo Router tutorial app, the companion to a JavaScript Mastery video, that walks through a full ride-hailing flow: Clerk auth, Google Maps with directions, Stripe payments, and Neon Postgres behind Expo API routes. It suits someone who wants to see how those pieces fit together in one codebase, not someone who needs a production ride app.
The backend sits in app/(api) as Expo Router +api.ts files, so the ride, user, driver, and Stripe routes live beside the screens in one repo with no separate server to deploy. Neon's serverless driver talks to Postgres over HTTP, which suits an edge-style deployment where a persistent connection pool would not hold up. Client state is split into zustand stores, and lib/map.ts keeps the region math and driver-time calculation out of the components. Clerk covers sign-up, email verification, and Google OAuth, which removes the auth work that usually eats a week in projects like this.
lib/map.ts reads the directions key from EXPO_PUBLIC_GOOGLE_API_KEY, but the README tells you to set EXPO_PUBLIC_DIRECTIONS_API_KEY, so a setup that follows the README gets an undefined key. Anything with the EXPO_PUBLIC_ prefix ships in the JS bundle, and calculateDriverTimes calls the Directions API twice per driver from the device on every search. The README schema defines rides.user_id, but the GET rides query and the Ride type filter on user_email, so the documented schema does not match the code. lib/utils.ts builds the sort key by concatenating created_at with ride_time, which is an integer duration, so sortRides produces invalid dates. fetchAPI also constructs an Error without throwing it, so HTTP failures pass through as successful responses. The last push was October 2024, so expect Expo SDK, Clerk, and Stripe API drift, and no test files appear in the tree.