YupCrew

What are we doing tonight? YupCrew helps friends, couples and housemates choose somewhere to eat, takeaway, a recipe to cook, or a movie or series to watch. Invite your people with a link, choose together and swipe to find a shared pick. No download or account needed.

Formerly Dinder. Public address: yupcrew.com. Existing Dinder addresses remain available for current Sessions and Shopping Lists; internal service and storage identifiers are unchanged.

Features

• No account needed — enter a name, get a 5-character session code, share it. The core flow is fully anonymous.
• Real-time presence — participants appear in the lobby as they join, via Socket.IO rooms keyed by session code.
• Swipe selection — like or pass on real nearby restaurants fetched from the Google Places API, with ratings, price level, and cuisine.
• Set-intersection consensus — each participant's likes live in a Redis set; the group's matches are computed with a single SINTER when the last person submits.
• Ephemeral by design — every session key carries a 30-minute TTL, refreshed atomically across all of a session's keys by an inline Lua script on each interaction. No cleanup jobs, no stale data.
• Push expiry — Redis keyspace notifications fire when a session's keys expire, and the backend broadcasts session:expired so clients aren't left polling a dead session.
• Optional Google sign-in — a Supabase-backed friends feature lets returning users sign in and find each other; the swipe flow never requires it.

How it works

sequenceDiagram
    participant H as Host
    participant P as Participant
    participant S as Backend
    participant R as Redis

    H->>S: POST /api/sessions
    S->>R: create session keys (30-min TTL)
    S-->>H: session code
    P->>S: session:join
    S->>R: add participant, refresh TTL (Lua)
    S-->>H: participant:joined
    H->>S: selection:submit (liked place IDs)
    S->>R: SADD likes, refresh TTL (Lua)
    S-->>P: participant:submitted
    P->>S: selection:submit
    S->>R: SINTER across participant sets
    S-->>H: session:results (matches)
    S-->>P: session:results (matches)
    Note over S,R: if 30 min pass, keys expire — keyspace notification → session:expired

The full client/server event contract — session:join, selection:submit, session:restart, session:leave inbound; participant:joined/submitted/left/disconnected, session:results, session:restarted, session:expired outbound — is typed once in shared/types/websocket-events.ts and imported by both sides, so the frontend and backend cannot drift apart silently.

Architecture

npm workspaces monorepo, three packages:

Package	What it is
backend/	Node 22 + TypeScript, Express 4, Socket.IO 4.7, ioredis, Zod validation. One handler file per socket event, services for sessions, friends, and restaurant search.
frontend/	React 18 + Vite, Tailwind, Zustand for state, socket.io-client. Mobile-first.
shared/	@dinder/shared — the typed WebSocket event contract and Zod schemas both sides import.

The Redis data model is the app. A session is a handful of keys (session:<code>, session:<code>:participants, session:<code>:<participantId>:selections, …), all carrying the same 30-minute TTL. Consensus is SINTER over the per-participant selection sets, and TTL refresh happens in one atomic inline Lua script so a session's keys can never expire out of sync — all in sessionStore.ts. sessionExpiryNotifier.ts subscribes to keyspace expired events to tell connected clients the moment a session dies.

REST is deliberately thin — POST /api/sessions, GET /api/sessions/:code — everything live goes over the socket.

Local development

Prerequisites: Node 22, Docker (for Redis), and a Google Places API key.

git clone https://github.com/Zacplischka/dinner_app.git
cd dinner_app
npm install

# Redis
docker run -d -p 6379:6379 redis:7-alpine

# the backend reads backend/.env
echo "GOOGLE_PLACES_API_KEY=your-key-here" > backend/.env

# backend on http://localhost:3001, frontend on http://localhost:3000
npm run dev

Environment variables

Variable	Needed for
GOOGLE_PLACES_API_KEY	Restaurant search for Eat Out and Takeaway Sessions
SPOONACULAR_API_KEY	Sourced Recipes for the Cook Branch
PORT, REDIS_HOST, REDIS_PORT, REDIS_PASSWORD, FRONTEND_URL	All have local defaults
SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY	Optional Google sign-in / friends feature only
VITE_BACKEND_URL	Frontend → backend (REST under /api, and the socket); defaults to the local backend on port 3001
VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY	Frontend sign-in; without them auth is disabled with a console warning

Scripts

Everything runs from the repo root. shared/ builds first — backend and frontend import @dinder/shared as a file dependency — and build and typecheck take care of that.

npm run dev          # backend + frontend together
npm run build        # shared → backend → frontend, in that order
npm test             # backend + frontend vitest suites (the backend's include contract + integration, which need Redis)
npm run typecheck    # builds shared, then tsc --noEmit on both
npm run lint         # eslint both workspaces
npm run format       # prettier both workspaces
npm run gen:types    # regenerate supabase/database.types.ts

Narrower runs go through the workspace: npm run test:unit --workspace=backend, npm run test:contract --workspace=backend (Redis required), npm run test:e2e --workspace=frontend (Playwright; mobile-chrome is the primary project). The WebSocket contract is typed once in shared/types/websocket-events.ts and the contract tests assert the backend against it — they are the source of truth for the realtime protocol.

CI (ci-cd.yml) runs typecheck, lint and both unit suites in one job and the contract suite against a Redis service in another; a green main auto-deploys.

Deployment

Both services deploy to Railway: the backend via Railpack (npm ci && npm run build && npm run start from the repo root), the frontend as a static SPA.

Documentation

CONTEXT.md defines domain language; ADRs record architecture decisions.

License

MIT © Zac Plischka