TuEats
Every off-meal-plan food option around Temple University's main campus, on one map.
Live site: tueats.co
The problem
Food trucks are a big part of eating at Temple, but the only official directory is a prose page with an embedded Google My Map. It has no list view, no hours, no cuisine info, and it doesn't work well on a phone. Restaurants and cafes are scattered across Google and Yelp, with nothing scoped to campus.
TuEats puts all of it in one mobile-first place: an interactive campus map, search and filters, opening hours, and ratings and reviews from students.
Features
- Interactive campus map built with MapLibre GL. Venues are grouped into campus zones (Liacouras Walk, The Wall, Morgan Hall, Cecil B. Moore Ave, and more), and each venue has a cuisine-coded pin.
- Search with fly-to. Type a venue name and the map jumps to it.
- Filters: Open now, Halal, Vegan friendly, and cuisine/venue type.
- "Open now" is computed in the browser from each venue's wall-clock hours (
America/New_York), so public pages can stay static and fast.
- Member accounts via Google sign-in. Members get a private account page and can rate venues 1–5 stars, write reviews, and submit photos for approval.
- Places of the Week, a ranking based on member ratings.
- Report a problem on any venue (closed, wrong hours, moved). The reporter's IP is hashed, never stored raw.
- Admin dashboard for managing venues: create and edit venues, a draft → published → retired lifecycle, a multi-photo gallery, zone assignment, bulk cuisine tagging, and moderation queues for photos and reports.
Tech stack
| Layer | Technology |
|---|
| Framework | Next.js 15 (App Router), React 19, TypeScript (strict) |
| Styling | Tailwind CSS 4, Framer Motion |
| Maps | MapLibre GL JS + OpenFreeMap vector tiles (no API key needed) |
| Database | PostgreSQL on Supabase, accessed with Drizzle ORM |
| Auth | Supabase Auth: Google OAuth for members, email/password for admins |
| Validation | Zod 4 |
| Storage | Vercel Blob (venue photos) |
| Hosting | Vercel, with preview deploys on every pull request |
| Testing | Vitest (unit), Playwright (end-to-end) |
| CI | GitHub Actions: typecheck, lint, format, tests, build |
Architecture
TuEats is a single Next.js app with no separate backend service.
Browser ──► Next.js server components (reads, static/ISR + tag caching)
└─► Server actions (writes) ──► validate (Zod) ──► authorize ──► rate-limit ──► Drizzle ──► Postgres
│
revalidateTag("venues") ◄┘
Design decisions:
- One write path. Every mutation is a server action that validates, then authorizes, then rate-limits, then writes, then invalidates the cache. The browser never talks to the database directly, and Supabase's auto-generated REST API is locked down with deny-all row-level security.
- Server-only data access. Only
src/lib/db/queries/ imports the database client. The Supabase JS client is used for authentication only.
- Venue-generic data model. "Truck" is just a value of
venue.type. Tables, routes (/eat/[slug]), and components never name a specific venue type, so restaurants, cafes, and vending machines can be added without a migration.
- Event-driven caching. Pages are cached by tag (
venues, venue:{slug}) and refreshed exactly when an admin or member write changes them. There are no timers or cron jobs.
- Authentication ≠ authorization. Signing in only proves who you are. Admin access additionally requires
role = "admin" on the user's profile row, which can only be set directly in the database.
- Privacy by default. Reviews show only a display name. Raw IPs are never stored (salted hashes only), user geolocation never leaves the browser, and user content is rendered as plain text.
Project structure
src/
app/ Routes: public map, /eat/[slug], /account, /about, /admin
actions/ Server actions (the only way data is written)
components/ UI, grouped by feature (map, venues, reviews, admin, …)
lib/ Business logic: hours, ratings, validation, rate limiting
db/queries/ All database reads and writes (Drizzle)
drizzle/ SQL migrations
scripts/ Data seeding and enrichment (KML import, venue enrichment)
tests/e2e/ Playwright tests
Specs/ Software design documents (scope, architecture, security, deployment)
Context/ Design system, decision log, progress log, backlog
docs/ Design notes and screenshots
Getting started
Prerequisites: Node.js 22+, pnpm 10, and a Supabase project.
git clone https://github.com/abislam66/fun-proj.git
cd fun-proj
pnpm install
cp .env.example .env.local # then fill in your Supabase values
pnpm db:migrate # apply database migrations
pnpm seed:kml # optional: seed venues from TuEats.kml
pnpm dev # http://localhost:3000
Scripts
| Command | What it does |
|---|
pnpm dev | Start the dev server |
pnpm build | Production build |
pnpm typecheck | TypeScript type check |
pnpm lint | ESLint |
pnpm format:check | Prettier check |
pnpm test | Unit tests (Vitest) |
pnpm test:e2e | End-to-end tests (Playwright) |
pnpm db:generate | Generate a migration from the schema |
pnpm db:migrate | Apply migrations |
Quality and workflow
- Changes reach
main through pull requests. main is protected, and CI must pass before merging.
- CI runs the typecheck, ESLint, the Prettier check, the Vitest suite, and a full production build on every PR.
- Every PR gets its own Vercel preview deployment, and merging to
main deploys to production.
- Larger decisions are recorded in
Context/decisions.md, and the full design docs live in Specs/.
Team
Disclaimer
TuEats is an independent student project and is not affiliated with or endorsed by Temple University.
License
MIT
